I again propose my algorithm as in bugzilla 883.

Basically it goes like that:

When no exact matching page title is found, all approximate matching page titles
shall be listed to the user to select the page title from - he probably wanted
(see AGREP option -By on http://www.tgries.de/agrep) and on that screen with the

• matching titles show him [[MediaWiki:Newarticletext]].

As soon as I have finished Enotif, I commit myself to the task of programming my
proposal !

The summary and initial comment of this bug are very unclear. Please
reopen and explain in more detail what you mean, including steps to
reproduce and a description of how the actual behavior differs from
the expected behavior.

Removing seemingly unrelated dependency.

xmlizer wrote:

ok sorry
i put an example in URL
http://test.wikipedia.org/w/wiki.phtml?title=SUPERBLADOESNTEXIST231239041&action=submit

when you access directly to such a page by a constructed URL
http://test.wikipedia.org/w/wiki.phtml?title=SUPIDNAME&action=submit

you become in edit mode, but the content of the page, which have to be empty, is
the content of [[MediaWiki:Newarticletext]].

river wrote:

You can't make up random URLs and expect them to work in some particular way.
action=submit URLs should only occur on form submission (save/preview).

Okay, now I see what you mean.

Doing a GET request with action=submit seems to trigger an edit preview with the
current page text. On a non-existing page it behaves a little more oddly, like an
edit page with the old no-text text stuck in.

This is incorrect behavior, as doing an action=submit with a GET request is
undefined. If not a POST, this should probably be rejected with an error message.
Related to bug 335.

There is another way it can occur, this catched me sometime ago, slave was
lagging, I needed to revert some vandalism, going to history click on revision
alt-E alt-S but I didn't noticed the edit text was filled with the error message
about database unable to retrieve the data, this was an action=edit

There is another way it can occur, this catched me sometime ago, slave was
lagging, I needed to revert some vandalism, going to history click on revision
alt-E alt-S but I didn't noticed the edit text was filled with the error message
about database unable to retrieve the data, this was an action=edit

Currently does edit, not preview, but is still pulling in the new-page message text.

robchur wrote:

Seems to have been fixed; something like
http://en.wikipedia.org/w/index.php?title=BugZilla_fun_for_all&action=submit now
spits out an "article doesn't exist" error, as one would expect.

[God help us if that ever turns into a bluelink.]

robchur wrote:

Nope, on re-checking, it's still there; it's back to doing a preview and not
providing an edit form, etc.

Works for me with trunk r20107

And for me as of r44540. Closing, as it seems to have been fixed at some point.