[TYPO3-core] Announcing TYPO3 4.5.18, 4.6.11 and 4.7.3

[Jigal van Hemert]

On 9-8-2012 14:20, Michael Stucki wrote:
>> Selecting 'pages.uid', but referring to it as only 'uid' is in my eyes the mistake.
> Indeed, that's true.

If you do a SELECT pages.uid FROM .... the field will usually be 
available as the key 'uid' from PHP.

The real problem is of course that the core adds some fields and uses 
some very common aliases (tt_content.uid as uid, tt_content.pid as pid, 
etc.).
Combined with the somewhat odd query this results in a combination of 
pages.uid and tt_content.uid as uid. Now the tt_content.uid is used in 
the end result.

It is not completely a user error, because if he selected pages.uid as 
uid then the query would have failed completely because of conflicting 
aliases.

It would be nice if the core could use aliases with a very low risk of 
conflicts (some unique name), but this wouldn't work with the workspaces 
overlay technique.

> I'm still not happy about more fields being added on top of
> selectFields, but I see the need for it due to workspaces.
>
> This behaviour was also not new but actually exists since almost a year:
> http://forge.typo3.org/projects/typo3v4-core/repository/revisions/e13d917ec8531d572fba295c7cbc06f44ea16750
>
> So therefore, I agree & will close the issue that Stefan reported.

Maybe it needs to be documented in a better way? A big warning which 
fields are automatically added to the selectFields.

-- 
Jigal van Hemert
TYPO3 Core Team member

TYPO3 .... inspiring people to share!
Get involved: typo3.org