ConfirmEdit prompting for CAPTCHA breaks saving of new page from Semantic Forms
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	thingles
	Mar 20 2013, 1:29 AM

Description

(I'm not sure if this is a Confirm Edit bug or a bug in Semantic Forms. However, if I turn off the Confirm Edit captcha things work fine, so I'll start here.)

The scenario is as follows:

A uses Special:FormEdit to create a new page using the 1-step method where the field names in the form will determine the name of the page that is saved.

The form contains URL fields.

Upon pressing save, the URL detected prompts ConfirmEdit to require a captcha to be provided. The page is previewed properly, with the data provided from the form present.

Captcha is answered properly.

Page is saved with the incorrect page name, and the form contents are lost. The page will be saved with a "blank" template for the form that was used.

You can see this history on these two pages:

http://wikiapiary.com/w/index.php?title=1&curid=23615&action=history

http://wikiapiary.com/w/index.php?title=Bulbapedia&curid=23617&action=history

Note the first page was originally saved as page name "1" and the other as "2". The moves are in the history.

Also, here is the discussion around this issue on the wiki where we saw this:

http://wikiapiary.com/wiki/WikiApiary_talk:Operations/2013/March#Problems_with_Form:Website

I've worked around this by disabling the captcha for users with email confirmation, but there is some bad voodoo happening here.

Version: master
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=71408

Details

Reference: bz46342

	Subject	Repo	Branch	Lines +/-
	Don't assume, that IContextSource::getWikiPage() always returns a WikiPage object	mediawiki/extensions/ConfirmEdit	master	+15 -0

Customize query in gerrit

Related Objects

Mentioned In: rECOEc878fb875e0f: Don't assume, that IContextSource::getWikiPage() always returns a WikiPage…
rMEXT7e930efed0f0: Updated mediawiki/extensions Project: mediawiki/extensions/ConfirmEdit…
T63794: "The specified target page _ is invalid" after completing captcha with SemanticForms
Mentioned Here: T63794: "The specified target page _ is invalid" after completing captcha with SemanticForms

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:31 AM

• bzimport added a project: ConfirmEdit (CAPTCHA extension).

• bzimport set Reference to bz46342.

• bzimport added a subscriber: Unknown Object (MLST).

thingles created this task.Mar 20 2013, 1:29 AM

Can you test it again with the latest master of ConfirmEdit?

Florian moved this task from Backlog to In discussion on the ConfirmEdit (CAPTCHA extension) board.Jan 15 2015, 12:17 PM

Umherirrender added a project: MediaWiki-extensions-Page_Forms.Jan 17 2015, 6:12 PM

Umherirrender subscribed.

Umherirrender unsubscribed.Jan 18 2015, 7:43 PM

I have almost exact same problem on my Referata wiki except that after captcha the page doesn't get saved at all and just returns The specified target page ' is invalid. error.

Florian added a comment.Jan 21 2015, 9:49 PM

This comment was removed by Florian.

Florian mentioned this in T63794: "The specified target page _ is invalid" after completing captcha with SemanticForms.Jan 21 2015, 9:51 PM

It appears ConfirmEdit tries to initiate a WikiPage object with the NS_SPECIAL namespace.

[18e04d6f] /Special:FormEdit/Deal/Testing Exception from line 118 of includes/WikiPage.php: Invalid or virtual namespace -1 given.

Backtrace:

#0 includes/context/RequestContext.php(202): WikiPage::factory(Title)
#1 extensions/ConfirmEdit/Captcha.php(601): RequestContext->getWikiPage()
#2 extensions/ConfirmEdit/ConfirmEditHooks.php(24): SimpleCaptcha->confirmEditMerged(RequestContext, WikitextContent, Status, string, User, boolean)
#3 [internal function]: ConfirmEditHooks::confirmEditMerged(RequestContext, WikitextContent, Status, string, User, boolean)
#4 includes/Hooks.php(206): call_user_func_array(string, array)
#5 includes/GlobalFunctions.php(4013): Hooks::run(string, array, NULL)
#6 includes/EditPage.php(1380): wfRunHooks(string, array)
#7 includes/EditPage.php(1621): EditPage->runPostMergeFilters(WikitextContent, Status, User)
#8 extensions/SemanticForms/includes/SF_AutoeditAPI.php(465): EditPage->internalAttemptSave(boolean, boolean)
#9 extensions/SemanticForms/includes/SF_AutoeditAPI.php(927): SFAutoeditAPI->doStore(EditPage)
#10 extensions/SemanticForms/includes/SF_AutoeditAPI.php(116): SFAutoeditAPI->doAction()
#11 extensions/SemanticForms/specials/SF_FormEdit.php(96): SFAutoeditAPI->execute()
#12 extensions/SemanticForms/specials/SF_FormEdit.php(46): SFFormEdit::printForm(string, string, NULL)
#13 includes/specialpage/SpecialPage.php(379): SFFormEdit->execute(string)
#14 includes/specialpage/SpecialPageFactory.php(506): SpecialPage->run(string)
#15 includes/Wiki.php(285): SpecialPageFactory::executePath(Title, RequestContext)
#16 includes/Wiki.php(588): MediaWiki->performRequest()
#17 includes/Wiki.php(447): MediaWiki->main()
#18 index.php(46): MediaWiki->run()
#19 {main}

Florian claimed this task.May 7 2015, 9:15 PM

Change 209637 had a related patch set uploaded (by Florianschmidtwelzow):
Don't assume, that IContextSource::getWikiPage() always returns a WikiPage object

https://gerrit.wikimedia.org/r/209637

gerritbot added a project: Patch-For-Review.May 7 2015, 9:25 PM

This appears to fix the issue on my end.

Florian closed this task as Resolved.May 8 2015, 8:39 PM

Change 209637 merged by jenkins-bot:
Don't assume, that IContextSource::getWikiPage() always returns a WikiPage object

https://gerrit.wikimedia.org/r/209637

Florian mentioned this in rMEXT7e930efed0f0: Updated mediawiki/extensions Project: mediawiki/extensions/ConfirmEdit….May 8 2015, 8:40 PM

Florian mentioned this in rECOEc878fb875e0f: Don't assume, that IContextSource::getWikiPage() always returns a WikiPage….May 8 2015, 8:43 PM