Bug #17318
TYPO3 back-end is blocked on new installations because of a bug in RFCs #15084/#15084
| Status: | Closed | Start date: | 2007-05-19 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | Oliver Hader | % Done: | 0% |
|
| Category: | - | Spent time: | - | |
| Target version: | - | |||
| TYPO3 Version: | 4.2 | Is Regression: | ||
| PHP Version: | 5.1 | Sprint Focus: | ||
| Complexity: |
Description
The patches from
" 0004886: Refresh left menu frame if extension with backend module was installed or removed"
make the TYPO3 backend totally unusable. No backend module will be called any more in default mode.
See English and Core mailinglists for more details, how to reproduce it and a patch proposal.
(issue imported from #M5655)
0005655_v2.diff
(1.2 kB)
Related issues
History
#1 Updated by Ingo Renner about 8 years ago
so where's your patch you were talking about, Franz? BTW: did you notice that nobody else has this problem?
#2 Updated by Franz Holzinger about 8 years ago
Hello Ingo, the patch to be discussed is on the English Mailinglist. You refused to having it added on the 4886 site.
I do not know who has tried out my reproduction steps so far. There has not been any response yet to these reproductions steps on a completely new install without any database and with no extensions installed.
#3 Updated by Ingo Renner about 8 years ago
Franz, as long as the ptch is not attached here, it officially doesn't exist.
#4 Updated by Steffen Müller about 8 years ago
I can reproduce this bug since revision 2330 from svn. If I downgrade to rev. 2321, everything works fine.
(Firefox 2.0.0.3 on Ubuntu Feisty)
#5 Updated by Patrick Rodacker about 8 years ago
I can reproduce the problem:
grabbed a fresh svn checkout an hour ago and none of the backend modules worked. After applying the attached patch, everything works as expected.
#6 Updated by Oliver Hader about 8 years ago
Please test the attached patch 0005655.diff
The reason is $GLOBALS['BE_USER']->uc['noMenuMode']:
If this information was never changed is has the value "0".
The evaluation was done the following way because of the missing type check:
$GLOBALS['BE_USER']->uc['noMenuMode'] == 'icons' // 0 == 0 -> thus, the statement was true and used topmenuFrame instead of menu
@Franz: I could now reproduce the behaviour on a brand new installation with no data ever stored/changed to the backend user. Your patch bug4886.diff was just a workaround and used the icon menu-mode for default-menu mode what also changed CSS ids and created redundancy.
#7 Updated by Oliver Hader about 8 years ago
The file 0005655_v2.diff fixes another problem on the initial login to the TYPO3 backend. In alt_main.php there is a call to e.g.
window.setTimeout("top.goToModule('help_aboutmodules',false,'');",1000);This call is forwared to the menu/topmenuFrame frame. But if this frame isn't loaded it will cause a JS error.
#8 Updated by Franz Holzinger about 8 years ago
Hello Oliver, yes it would work also with your patch.
$GLOBALS['BE_USER']->uc['noMenuMode'] = 0
if ($GLOBALS['BE_USER']->uc['noMenuMode'] 'icons') {
has resulted in TRUE in this case, which it shouldn't.
The string 'icons' seem to have been converted into an integer before the comparison. Therefore it has been '0 0).
#9 Updated by Oliver Hader about 8 years ago
Committed to SVN Trunk (rev. 2349)