[TYPO3-core] Weird behaviour after a recent change in all supported versions

Loek Hilgersom loek at netcoop.nl
Sun Oct 7 23:42:08 CEST 2012


Hi core devs and others,

While many of you enjoyed a hopefully very inspiring T3CON12, I spent my time 
debugging some weird behaviour in one of our sites after upgrading from 4.5.17 
to 4.5.19. It concerns this change by Ernesto:
https://review.typo3.org/12999
which was included in 4.5.18, 4.6.11, 4.7.3 and 6.0alpha3.

After this change, I've noticed that some Typoscript queries (CONTENT or 
RECORDS) are no longer processed correctly. I still have no idea why exactly 
this happens, so I hope someone can shed some light on this.

I've pinned it down to the following test case:

If I query the same record twice on the same page, but the first query contains 
a sub-query to get some additional information from another table, then the 
second query fails.

In Typoscript:

lib.nestedQuery = CONTENT
lib.nestedQuery {
	wrap = <div>First query for user: |</div>
	table = fe_users
	select {
		pidInList = 5
		selectFields = last_name,usergroup
		where = uid=2
	}
	renderObj = COA
	renderObj {
		10 = TEXT
		10.field = last_name

		20 = COA
		20.10 = CONTENT
		20.10 {
			wrap = <div>Usergroups first user:|</div>
			table = fe_groups
			select {
				pidInList = 5
				andWhere.dataWrap = uid={field:usergroup}
			}
			renderObj = TEXT
			renderObj.field = title
		}
	}
}

lib.failingQuery = CONTENT
lib.failingQuery {

	wrap = <div>Second query for the same user: |</div>
	table = fe_users
	select {
		pidInList = 5
		where = uid=2
	}
	renderObj = TEXT
	renderObj.field = last_name
}

page = PAGE
page {
	typeNum = 0
	10 < lib.nestedQuery
	20 < lib.failingQuery
}

- If I try this, the second query returns no result.
- If I change the order of the 2 queries inside the PAGE object, then everything 
works fine.
- Also, the superfluous 20 = COA before the sub-query is there for a reason: if 
I change COA to COA_INT, then all works fine.

The commit causing trouble only makes a small change to function 
sanitizeSelectPart in sysext cms/tslib/class.tslib_content.php, ending up with 
slightly different select parts for the queries (with or without adding 
'fe_users.uid AS uid, fe_users.pid AS pid'). I just don't see how this could 
have the effect described above, but it does (reverting that single commit 
solves the problem).

Maybe someone has an idea how this is related?

Cheers,
Loek


More information about the TYPO3-team-core mailing list