TYPO3 Core

I can confirm this bug. to me this is a very serious one. I'll dig into it.

I attached Beat's solution as patch-file

since this problem was introduced by some patch to add better support for DBAL I am in contact with Karsten D. to find a solution.

Reverting to old behaviour (see attached patch) might cause problems again for DBAL.

Our clients noticed the same problem.

seems to be related to 4101

with the fix that's described here - we get another problem: ext: sr_feuser_register_2.5.2.t3x (frontend user register) does not work anymore. I get a internal server error.
does anybody has a fix that works for both ?

Confirmed in our TYPO3 4.0.2 Installation. I'll test the patch now.

I changed the line in my installation to
(($GLOBALS['TSFE']->sys_page instanceof t3lib_pageSelect) ? $GLOBALS['TSFE']->sys_page->enableFields($table,'',$ignore) : t3lib_pageSelect::enableFields($table,'',$ignore)),

I don't know if it works for both mentioned issues, but it should as it either uses the instantiated object, or the "raw" function.
Best of both worlds, so to speak.

applying that patch i get the next:
Fatal error: Call to undefined function: getmultiplegroupswhereclause() in ...\home\t3lib\class.t3lib_page.php on line 975
(TYPO3 4.1beta2)

Hi,

$GLOBALS['TSFE']->sys_page
is empty at that point, there is no function enableFields in $GLOBALS['TSFE']->sys_page at that moment

this error is NOT new in Version 4.1
i got it in 4.0.5 too!

this bug unfortunatly still persists. I digged into it again and also asked Karsten for some help since it is a DBAL concern that these lines were changed. I now added a check if the methods exist and a fallback to the static call.

I attached patchfiles for 4.0:
http://bugs.typo3.org/file_download.php?file_id=2355&type=bug (for 4.0)
and 4.1:
http://bugs.typo3.org/file_download.php?file_id=2356&type=bug (for 4.1)

both should cleanly apply to their appropriate typo3-version with a 'patch -p0 < /path/to/patchfile'

Peter

I attached a patch file (bug_4160.diff) that changes the sequence in index_ts.php.

I try to describe it in pseudo-code:
before:

// ...
init (FE user)
init (BE user))
if( admPanel enabled ) {
do_tsfebe_userauth_things()
}
TSFE->determineId() // TSFE->sys_page is initialized here!
if ( ! BE_USER->extPageReadAccess() ) {
// insufficient access rights of BE user
unset(BE_USER)
TSFE->determineId() // recheck current page (without being loged in as BE user
// start parsing TS setup
// ... (generate output etc.)

after:

// ...
init (FE user)
init (BE user))
TSFE->determineId() // TSFE->sys_page is initialized here!
if ( ! BE_USER->extPageReadAccess() ) {
// insufficient access rights of BE user
unset(BE_USER)
TSFE->determineId() // re-check current page (without being loged in as BE user
}
if( BE_USER && admPanel enabled ) {
do_tsfebe_userauth_things()
}
// start parsing TS setup
// ... (generate output etc.)

So the BE_USER is initialized like previous but the "things to do" are done AFTER the TSFE object is completely initialized. IMO this is more correct but it may as well cause errors. The patch has to be checked very thoroughly!

Version 4.1.1 got this problem also.
How about the current status of the last patch? „The patch has to be checked very thoroughly!“ - are there any issues?

I can confirm this bug in 4.1.2, too. I'm wondering that nobody fixes this bug in the TYPO3 Source? I think it is an important feature?!
I manually applied the patch from Peter (http://bugs.typo3.org/file_download.php?file_id=2356&type=bug) - some line numbers changed - and it seems to work with 4.1.2.

The bug is now fixed in SVN (branches TYPO3_4-0, TYPO3_4-1 and trunk).