Bug #20909
closed
"Create new page"-wizard broken by core
0%
Description
The "Create new page"-wizard broke sometime in the last 3 weeks (August 09). It happens the following way:
- TV shows you a page-template to use
- it uses "$dataArr['pages']['NEW']" and "process_datamap()" to create that page (pre-filling some fields)
- it redirects to "altdoc.php?&edit[pages][' . $newID . ']=edit&columnsOnly=hidden,title,alias
It does not assign a default-title, entering altdoc is fine, the title get the not-filled warning. The breadcrump in the doc-header is also correct (showing no title thus '//', and the newID).
On using either "savedok" or "savedokandclose"-buttons in the docheader leads to:
Error!
The requested page was not accessible!
There has been made no changes to the page-wizard in two years or so - I don't expect this to be a TV issue. Basically there is no extension-code or custom-code involved/fiddling.
Reentering that page's form (which then has all form-fields) and save works all right. I assume both action should be identical. Maybe there got a hidden field lost in the columnsOnly-version?
The "Create new page" of the list-module is different in that t does not create a new page in between, but opens the form with "Page - [NEW]". I don't know another location where I can cross-check for same-procedure = same-bug-behaviour.
(issue imported from #M11760)
Updated by Niels Fröhling over 15 years ago
A note: the form contents get saved, then it throws "not accessible". it happens in any way through the page-module (even with the complete form).
Updated by Niels Fröhling over 15 years ago
Some log from TV:
GET 200 OK
columnsOnly hidden,title,alias
edit[pages]3019 edit
returnUrl mod.php?M=web_txtemplavoilaM1&id=3019&updatePageTree=1
the response is the form, when saving:
POST 503 Service Temporarily Unavailable
columnsOnly hidden,title,alias
edit[pages]3019 edit
returnUrl mod.php?M=web_txtemplavoilaM1&id=3019&updatePageTree=1
the response is the error "not accessible"
---------------------------------------------------------------------------
Some log from "list"-module:
GET 200 OK
edit[pages]3019 edit
returnUrl db_list.php?id=157&table=
the response is the form, when saving:
POST 200 OK
edit[pages]3019 edit
returnUrl db_list.php?id=157&table=
the response is the form
---------------------------------------------------------------------------
The post-data looks pretty much the same.
It appears really to be identical, but it shows the error.
It saves the form-content (in both cases), then it throws the error (in "page").
If you just close the new page and re-enter the pages-form getting the complete form, you still get "not accessible".
It is possible to get rid of the error the following way:
- wait for the error to come
- get "back" with the browser's button
- save again (from now on it's behaving well)
These test have been conducted with a "admin"-user who is also userid/groupid of the pages in question. Permitions in the tree are 31/27/0 (xxxxx/xxx-x/-----).
Looks much like something's (a default field for example?) missing in the "$dataArr['pages']['NEW']" process now (was good before).
Updated by Niels Fröhling about 15 years ago
I found the error in a "process_datamap" after-database-update hook. Unrelated to the core. Please close.
Updated by Christian Kuhn about 15 years ago
Resolved, no change required. Thanks Niels!
Updated by