[TYPO3-core] RFC: Bug 5655: TYPO3 back-end was blocked on new installations because of a bug in RFC #4886

[Oliver Hader]

This is a SVN patch request.

Problem:
In RFC #4886 (Refresh left menu frame if BE module installed/removed)
the following line was introduced:
<< if ($GLOBALS['BE_USER']->uc['noMenuMode'] == 'icons') { >>
On new installations the variable BE_USER->uc['noMenuMode'] is "0". This
also occurs if the menu mode was never changed by the user on existing
TYPO3 installations.
Since this zero-value is seen as integer the string 'icons' is also
converted to an integer and gets also the value zero. Thus, the
comparison of the expression mentioned above is (0 == 0) and returns a
boolean TRUE - this breaks the expected back-end behaviour.
Clicking on links to e.g. Web>List in the menu frame wouldn't work
anymore because the link tries to call a JavaScript method in the
"topmenuFrame" which doesn't exist.

Solution:
Extend the comparison mentioned above to additionally check the type,
like "($GLOBALS['BE_USER']->uc['noMenuMode'] === 'icons')".

Comments:
There is an additonal fix in the attached patch which solves another
bug, that occured when someone just logged into the TYPO3 back-end. In
alt_main.php there is a JavaScript call that shows the intro screen,
e.g. like "top.goToModule('help_aboutmodules',false,'')". This call gets
forwareded to the menu/topmenu frame. It is possible that this frame
isn't completely loaded at this time and a JavaScript error appears.

Bugtracker reference:
http://bugs.typo3.org/view.php?id=5655

Branch: Trunk only


olly
-- 
Oliver Hader
http://inpublica.de/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0005655_v2.diff
Url: http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20070524/541a22d2/attachment.diff