Re-assigning to f.trott.

*bump*

Hoping that this can get some attention soonish. I looked at the code myself but it's a bit mysterious. This breaks all #autoedit functionality in Semantic Forms.

Digging a little further (this bug is causing me troubles, want to try and fix) and I don't see this error message anywhere in Semantic Forms. It is however in the core codebase in AbstractContent.php at

https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes/content/AbstractContent.php;hb=41bd1fee921eeb802ed2cea9431be479eb51a0ba#l140

and ContentHandler.php at

https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes/content/ContentHandler.php;hb=41bd1fee921eeb802ed2cea9431be479eb51a0ba#l550

Not sure if that helps, but that is where the stack trace is going to end.

It does seem that one issue is in setupEditPage in SF_AutoeditAPI.php on line 324. The call to $wgUser->editToken() is deprecated and appears like it should be $wgUser->getEditToken() instead.

• 'wpEditToken' => $wgUser->isLoggedIn() ? $wgUser->editToken() : EDIT_TOKEN_SUFFIX,

+ 'wpEditToken' => $wgUser->isLoggedIn() ? $wgUser->getEditToken() : EDIT_TOKEN_SUFFIX,

However, I'm still getting errors but they are different now.

(In reply to comment #4)

It does seem that one issue is in setupEditPage in SF_AutoeditAPI.php on line

324. The call to $wgUser->editToken() is deprecated and appears like it

should
be $wgUser->getEditToken() instead.

• 'wpEditToken' => $wgUser->isLoggedIn() ? $wgUser->editToken() :

EDIT_TOKEN_SUFFIX,
+ 'wpEditToken' => $wgUser->isLoggedIn() ? $wgUser->getEditToken() :
EDIT_TOKEN_SUFFIX,

However, I'm still getting errors but they are different now.

Just to clarify, I determined that from this stack trace captured in the JSON encoded error from MW.

<div class=\"mw-debug-backtrace\">
Backtrace:
<ul>

<li>Debug.php line 221 calls wfBacktrace()</li>
<li>GlobalFunctions.php line 1091 calls MWDebug::deprecated()</li>
<li>User.php line 3473 calls wfDeprecated()</li>
<li>SF_AutoeditAPI.php line 324 calls User->editToken()</li>
<li>SF_AutoeditAPI.php line 879 calls SFAutoeditAPI->setupEditPage()</li>
<li>SF_AutoeditAPI.php line 116 calls SFAutoeditAPI->doAction()</li>
<li>ApiMain.php line 840 calls SFAutoeditAPI->execute()</li>
<li>ApiMain.php line 380 calls ApiMain->executeAction()</li>
<li>ApiMain.php line 351 calls ApiMain->executeActionWithErrorHandling()</li>
<li>api.php line 77 calls ApiMain->execute()</li>

</ul>
</div>

type":"deprecated","caller":"SFAutoeditAPI::setupEditPage",

After making the above change I'm no longer getting a stack trace in the error output, however, the error remains the same message:

"message": "Format json is not supported for content model wikitext"

with a 400 error. Some further debugging here. The error message sf_autoedit_fail that is thrown is only referenced in two places in SF_AutoeditAPI.php. The one that is triggered is the one on line 557.

Also worth noting that there is another editToken reference that needs changing in SF_Utils.php on line 226.

Okay, after adding a lot of wfDebug calls in SF_AutoeditAPI.php I've tracked down that an exception is being thrown in doStore() on the call

$status = $editor->internalAttemptSave( $resultDetails, $bot );

Once this line is hit an exception is thrown. Now I need to sleep. :-)

FWIW, this is the actual stack trace once it hit me that I should just remove the try/catch that was hiding it.

#0 /srv/www/mediawiki/public_html/w/includes/content/WikitextContentHandler.php(38): ContentHandler->checkFormat('json')
#1 /srv/www/mediawiki/public_html/w/includes/content/ContentHandler.php(159): WikitextContentHandler->unserializeContent('{{Bookmark?|Tit...', 'json')
#2 /srv/www/mediawiki/public_html/w/includes/EditPage.php(2071): ContentHandler::makeContent('{{Bookmark?|Tit...', Object(Title), 'wikitext', 'json')
#3 /srv/www/mediawiki/public_html/w/includes/EditPage.php(1360): EditPage->toEditContent('{{Bookmark?|Tit...')
#4 /srv/www/mediawiki/public_html/w/extensions/SemanticForms/includes/SF_AutoeditAPI.php(432): EditPage->internalAttemptSave(false, false)
#5 /srv/www/mediawiki/public_html/w/extensions/SemanticForms/includes/SF_AutoeditAPI.php(908): SFAutoeditAPI->doStore(Object(EditPage))
#6 /srv/www/mediawiki/public_html/w/extensions/SemanticForms/includes/SF_AutoeditAPI.php(118): SFAutoeditAPI->doAction()
#7 /srv/www/mediawiki/public_html/w/includes/api/ApiMain.php(840): SFAutoeditAPI->execute()
#8 /srv/www/mediawiki/public_html/w/includes/api/ApiMain.php(380): ApiMain->executeAction()
#9 /srv/www/mediawiki/public_html/w/includes/api/ApiMain.php(351): ApiMain->executeActionWithErrorHandling()
#10 /srv/www/mediawiki/public_html/w/api.php(77): ApiMain->execute()
#11 {main}

Also worth noting Bug 41497, which is the only other instance Google can find of this issue.

Just noting here this line from the Content Handler manual page [1]:

"For editing however, non-text content is not supported per default. EditPage and the respective handlers in the web API are changed to fail for non-textual content."

Seems like a hint to the issue since the exception that is thrown follows a path through EditPage.

[1] http://www.mediawiki.org/wiki/Manual:ContentHandler

*bump* this is still outstanding and causes issues for anyone using Semantic Forms on the newest release.

Related URL: https://gerrit.wikimedia.org/r/68287 (Gerrit Change Ia0b5dcb1e0a7c75fca1479b719ddf59fb9a79358)

https://gerrit.wikimedia.org/r/68287 (Gerrit Change Ia0b5dcb1e0a7c75fca1479b719ddf59fb9a79358) | change APPROVED and MERGED [by Foxtrott]

Should be fixed. Please re-open if not.

Applied diff and confirmed fixed! And there was mass cheering! :-)