Bug #17318

TYPO3 back-end is blocked on new installations because of a bug in RFCs #15084/#15084

Added by Franz Holzinger over 14 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
-
Target version:
-
Start date:
2007-05-19
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.2
PHP Version:
5.1
Tags:
Complexity:
Is Regression:
Sprint Focus:

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)


Files

0005655_v2.diff (1.22 KB) 0005655_v2.diff Administrator Admin, 2007-05-23 11:56

Related issues

Related to TYPO3 Core - Feature #16920: Refresh left menu frame if extension with backend module was installed or removedClosedIngo Renner2007-01-30

Actions
#1

Updated by Ingo Renner over 14 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 over 14 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 over 14 years ago

Franz, as long as the ptch is not attached here, it officially doesn't exist.

#4

Updated by Steffen Müller over 14 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 over 14 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 over 14 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 Koch: 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 over 14 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 over 14 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 over 14 years ago

Committed to SVN Trunk (rev. 2349)

Also available in: Atom PDF