457996 - If no page ID is specified tiki-editpage.php defaults to modifying the start page

Status: VERIFIED FIXED

(support.mozilla.org :: Knowledge Base Software, task)

Description

[[:Cww]]

I'm not sure exactly how to reproduce but editing or approving articles can sometimes cause the front page to turn into the target article even if the editor or approver doesn't have edit permissions on the target article.  See bug 457992 for a case in point.

Comment 1

[Underpass]

I experienced this issue yesterday: to reproduce this oddity, paste this link in the urlbar

http://support.mozilla.com/tiki-editpage.php?locale=it

The problem is that this URL comes out in the AwesomeBar every now and then when searching the previous articles so it's easy to mess with it.

Comment 2

[Nelson Ko [:nkoth]]

This is actually a feature of TikiWiki. I am not sure if it can be turned off easily. It should be optionalized in my opinion. Amette? comments?

Comment 3

[Alexander Mette [amette]]

Yes, it is a feature. Nothing I would totally resist to removing/chaging, but I think that nevertheless it would make sense to make another behaviour optional.

How about having a config-option to select, if the WikiHome will be edited (current behaviour) or to present something like the mod_quick_edit.

Another possibility would be to redirect to the Sandbox - but this is problematic as sandbox is also a feature/permission to turn on and it can't be assumed that all the Tiki sites will have it.

Comment 4

[Chris Ilias [:cilias]]

I think the real issue is: How are people ending up making an edit without a page id?

Comment 5

[David Tenser [:djst]]

I agree with Chris: we should focus on finding the cause of this. Any steps to reproduce the bug of actually ending up at that URL?

Comment 6

[Underpass]

As I tried to say before, the URL is stored in the history, but it has the "normal" page title. For example, yesterday I made a small edit on this page

http://support.mozilla.com/it/kb/Richiedere%20supporto

The title is "Richiedere supporto"

If I use the awesome bar to find the page again, perhaps to make another edit, that's what happens:

http://img56.imageshack.us/my.php?image=457996ba0.png

Which gives me a fair opportunity to tamper with the Spanish version of the start page ;-)

Comment 7

[David Tenser [:djst]]

Is that a problem with the awesome bar..?

Comment 8

[Majken Connor [:Kensie]]

That's the url you get when you preview an article. However, when I did so it left tiki-editpage.php as the page title. Simon - can you try editing a new page, every time you click on something (preview, minor, etc) check to see if that new page is stored in the awesome bar with the editpage url. See if you can find out which step exactly is doing it.

Comment 9

[Underpass]

Hi Lucy, 

From what I understand, it's the "Preview" button who actually makes that URL appear.

I made three test on this page

http://support.mozilla.com/it/kb/Problemi+comuni+risolti+in+Firefox+3

1) edit + preview + minor save

2) edit + preview + save

3) edit + plain save


After the first two tests the autocomplete list gave me this URL

http://support.mozilla.com/tiki-editpage.php?locale=it

with the title of the page.

The third is the good one.

http://img265.imageshack.us/my.php?image=screenshot2uy3.png

Hope it helps. Bye!

Simon

Comment 10

[[:Cww]]

This is doubly annoying because when the performance lags on SUMO, I sometimes (ok, often) get impatient and refresh the page when I'm trying to preview... and then it tries to load http://support.mozilla.com/tiki-editpage.php and if I weren't paying attention, I'd be able to mess about on the Home page.  I don't have to use the awesomebar at all, I just have to edit an article, preview, shift-reload the page.  (Usually at this point I realize something is wrong and stop but I can imagine easily continuing forward from this point and running over the home page.)

Comment 11

[E. Cooper [:ecooper]]

Attachment: Adds page parameter to form action to retain page being edited after using the preview feature

So it seems the problem folks are having is that when they use Preview the data posts to tiki-editpage.php with locale as a param if it's set. Coming back to this later, will send them to edit the main page since no page is defined. 

Adding the page param and name to the action="tiki-editpage.php" of the edit form takes care of this.

Comment 12

[Nelson Ko [:nkoth]]

Comment on attachment 351995 [details] [diff] [review]
Adds page parameter to form action to retain page being edited after using the preview feature

in r20603/r20604

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED;

When editing and then previewing a page on staging, I get: http://support-stage.mozilla.org/tiki-editpage.php?locale=en-US&page=*Clearing+Location+bar+history

Production, however, still--as everyone here has already confirmed--retains the base URL--http://support.mozilla.com/tiki-editpage.php?locale=en-US.

Comment 14

[Marc Laporte]

Let's test on http://tiki-trunk.mozilla.com/ and if it's not solved, let's upstream.