Bug #33709
"New page" broken (cannot insert "pages" record on ordinary page), TYPO3 4.6.4
| Status: | Accepted | Start date: | 2012-02-06 | |
|---|---|---|---|---|
| Priority: | Must have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | Editing Form | |||
| Target version: | - |
Description
This bug has been confirmed on two separate TYPO3 4.6.4 installs and does not seem related to any setup etc.
Whenever I attempt to create a new page through FE this happens:
1) when using "save and close" I am redirected to the front page (link generated to page id zero, it seems)
2) when using "save", the AJAX reloads the form but discards all the values
The message reads (in sys_log):
"Attempt to insert record on page 'Debat' (2370) where this table, pages, is not allowed (msg#1.1.11)"
BE-user is admin. Access permissions on the page in question is set to allow everything for everybody (to debug; standard permissions set to group-allow everything). Tried with and without "simulate_beuser", no difference. Naturally, BE-user in question is allowed creation of pages etc. through the BE with no "access denied" warnings.
There is no page TS config apart from the "enable FE edit" and "set panel initially hidden" switches. No user TS exists for the BE-user in question.
Will of course supply any additional information you may need to fix this one!
Related issues
History
#1 Updated by Claus Due over 3 years ago
Update: problem is caused in TCEmain processDataMap.
Checking "isTableAllowedForThisPage" always returns FALSE because "pages" is never allowed. TYPO3 looks for a $GLOBALS['PAGES_TYPES'][$doktype] where $doktype is "1" but this does not exist and the fallback ($GLOBALS['PAGES_TYPES']['default']) does NOT contain "pages" under any circumstances I've encountered (root page, not root, hidden, visible etc).
Trying to zero in on what causes "pages" to never be allowed in the default "allowedTables" list for my BE user...
Possible causes:
"pages" is expected in allowedTables default list
Or more likely, for some reason a "doktype" of "1" is never set in the $GLOBALS['PAGES_TYPES'] array - but I have clue why this would happen. Feedback would be appreciated, I see others have the same problem (and some include being denied insertion of tt_content records as well, traceable to the same place in TCEmain).
#2 Updated by Lorenz Ulrich about 3 years ago
- Status changed from New to Accepted
#3 Updated by Lorenz Ulrich about 3 years ago
"pages" is defined as allowed table in tables.php, $PAGES_TYPES array (under default, not as dokType 1). In backend-only mode, it is correctly initialized and therefore the list of allowed tables is:
pages,pages_language_overlay,tt_content,sys_template,sys_domain,backend_layout,sys_note,tx_rtehtmlarea_acronym,tt_news_cat,tt_news,tt_address,tt_address_group
(of course depending on extensions)
In frontend editing mode (a mix of BE and FE obviously), $PAGES_TYPES is unset somehow so the list of allowed tables is:
,pages_language_overlay,tt_content,sys_template,sys_domain,backend_layout,tx_rtehtmlarea_acronym,tt_news_cat,tt_news,tt_address,tt_address_group
I have absolutely know idea how this happens. $PAGES_TYPES is unset in config_default.php but I didn't find out when and how it is written to $GLOBALS['PAGES_TYPES']. It must be that part of the show that is working differently in Frontend editing mode.
#4 Updated by Oliver Rowlands almost 3 years ago
The problem comes from a core change to tslib_fe::includeTCA where the global declaration for $PAGES_TYPES has been removed. Replacing "global $TCA;" by "global $TCA, $PAGES_TYPES;" shoud do the trick. This will need to be pushed upstream to the core developers, in the mean time you can temporarily resolve the issue by XClass'ing tslib_fe and overriding the includeTCA function.