Last modified: 2014-09-23 22:35:50 UTC
In trunk 1.19alpha (r100522): Special:MassEditRegex (which is not in the list of components for which bugs can be reported) works ok in preview mode, but clicking "execute" only produces a blank page. Our test case was: on a page France replace the word information with data: - France (Pages to edit) - /data/ (Search for) - information (Replace with) Settings: $wgShowSQLErrors = true; $wgShowDebug = true; $wgShowExceptionDetails = true; $wgDebugLogFile = "$IP/debug.log"; error_reporting(E_ALL); ini_set("display_errors", 1); are all on, but no further information is available.
Adding entries in debug.log: POST /testwiki/index.php?title=Special:MassEditRegex&action=submit HTTP HEADERS: HOST: biowikifarm.net CONNECTION: keep-alive CONTENT-LENGTH: 129 CACHE-CONTROL: max-age=0 ORIGIN: http://biowikifarm.net USER-AGENT: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.202 Safari/535.1 CONTENT-TYPE: application/x-www-form-urlencoded ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 REFERER: http://biowikifarm.net/testwiki/index.php?title=Special:MassEditRegex&action=submit ACCEPT-ENCODING: gzip,deflate,sdch ACCEPT-LANGUAGE: en-US,en;q=0.8,de-DE;q=0.6 ACCEPT-CHARSET: UTF-8,*;q=0.5 COOKIE: mediaWiki.user.bucket:ext.articleFeedback-tracking=0%3Aignore; mediaWiki.user.bucket:ext.articleFeedback-options=0%3Ashow; metawiki_session=a954cb88a96172c11afeabd42e712fa7; metawikiLoggedOut=20111022195717; metawikiUserID=1; metawikiUserName=WikiSysop; metawikiToken=a630452887b7b958dc52361820927a45; clicktracking-session=ZMDPYqIjTKfEAGV1VXzti3rH02Ga24ogB; wikiEditor-0-toolbar-section=advanced; vector-nav-p-tb=true CACHES: APCBagOStuff[main] APCBagOStuff[message] APCBagOStuff[parser] session_set_cookie_params: "0", "/", "", "", "1" LocalisationCache: using store LCStore_CDB Unstubbing $wgParser on call of $wgParser::setHook from wfIdentificationToolInit Parser: using preprocessor: Preprocessor_DOM Use of wfLoadExtensionMessages is deprecated. [Called from ExtLoops::registerMagicWords in /usr/share/mediawikistaging/ext-LOCAL-svn/Loops/Loops.php at line 82] Unstubbing $wgLang on call of $wgLang::getCode from MessageCache::get User: got user 1 from cache User: loading options for user 1 from database. Connecting to localhost testwiki... Profiler::instance called without $wgProfiler['class'] set, falling back to ProfilerStub for safety Connected to localhost testwiki. User: logged in from session User: loading options for user 1 from database. MessageCache::load: Loading en... got from local cache Unstubbing $sfgFormPrinter on call of $sfgFormPrinter::setInputTypeHook from SMFormInputs::initFormHook Fully initialised User::getBlockedStatus: checking... Unstubbing $wgAuth on call of $wgAuth::getCanonicalName from User::getCanonicalName Class SkinVector not found; skipped loading LoadBalancer::getConnection: using server db1 for group api ApiMain::setCacheMode: setting cache mode private DifferenceEngine old '0' new '0' rcid '0' User: got user 1 from cache Class PEAR_Error not found; skipped loading User: got user 1 from cache OutputPage::sendCacheControl: private caching; ** Request ended normally accepts gzip Start request POST /testwiki/index.php?title=Special:MassEditRegex&action=submit HTTP HEADERS: HOST: biowikifarm.net CONNECTION: keep-alive CONTENT-LENGTH: 121 CACHE-CONTROL: max-age=0 ORIGIN: http://biowikifarm.net USER-AGENT: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.202 Safari/535.1 CONTENT-TYPE: application/x-www-form-urlencoded ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 REFERER: http://biowikifarm.net/testwiki/index.php?title=Special:MassEditRegex&action=submit ACCEPT-ENCODING: gzip,deflate,sdch ACCEPT-LANGUAGE: en-US,en;q=0.8,de-DE;q=0.6 ACCEPT-CHARSET: UTF-8,*;q=0.5 COOKIE: mediaWiki.user.bucket:ext.articleFeedback-tracking=0%3Aignore; mediaWiki.user.bucket:ext.articleFeedback-options=0%3Ashow; metawiki_session=a954cb88a96172c11afeabd42e712fa7; metawikiLoggedOut=20111022195717; metawikiUserID=1; metawikiUserName=WikiSysop; metawikiToken=a630452887b7b958dc52361820927a45; clicktracking-session=ZMDPYqIjTKfEAGV1VXzti3rH02Ga24ogB; wikiEditor-0-toolbar-section=advanced; vector-nav-p-tb=true CACHES: APCBagOStuff[main] APCBagOStuff[message] APCBagOStuff[parser] session_set_cookie_params: "0", "/", "", "", "1" LocalisationCache: using store LCStore_CDB Unstubbing $wgParser on call of $wgParser::setHook from wfIdentificationToolInit Parser: using preprocessor: Preprocessor_DOM Use of wfLoadExtensionMessages is deprecated. [Called from ExtLoops::registerMagicWords in /usr/share/mediawikistaging/ext-LOCAL-svn/Loops/Loops.php at line 82] Unstubbing $wgLang on call of $wgLang::getCode from MessageCache::get User: got user 1 from cache User: loading options for user 1 from database. Connecting to localhost testwiki... Profiler::instance called without $wgProfiler['class'] set, falling back to ProfilerStub for safety Connected to localhost testwiki. User: logged in from session User: loading options for user 1 from database. MessageCache::load: Loading en... got from local cache Unstubbing $sfgFormPrinter on call of $sfgFormPrinter::setInputTypeHook from SMFormInputs::initFormHook Fully initialised User::getBlockedStatus: checking... Unstubbing $wgAuth on call of $wgAuth::getCanonicalName from User::getCanonicalName Class SkinVector not found; skipped loading LoadBalancer::getConnection: using server db1 for group api ApiMain::setCacheMode: setting cache mode private DifferenceEngine old '0' new '0' rcid '0' User::matchEditToken: broken session data Request ended normally accepts gzip Start request
PS: $wgEnableWriteAPI is true
Is a.nielsen the right maintainer of this extension?
CC'ing Bugmeister Mark Hershberger to see if he can help direct this bug report to the right person.
Yes I'm the maintainer of the extension, I just don't have a new enough installation of MW handy to try to reproduce the problem yet.
Adam, thanks for the reply. We just released MediaWiki 1.180rc1 http://lists.wikimedia.org/pipermail/mediawiki-announce/2011-November/000103.html in case that's handy for you to install.
Thanks for the info. I've managed to reproduce the error now, so I'm just trying to figure out what's causing it. At this stage it looks like something to do with the requests to the edit API interfering with the user's request to the MassEditRegex page.
I think I've fixed this error. It was due to some changes in the MediaWiki API. The latest SVN version of the extension works for me on the MediaWiki SVN trunk.
Yes, looks good from the first tests. Thanks a lot for your help. A very useful extension.
Unfortunately, we now discover that with MediaWiki 1.18.0 (r104607) and using the latest version of MassEditRegex (updated on 29.11.2011) the following error message results when hitting the Execute button: Fatal error: Class 'DerivativeRequest' not found in /usr/share/mediawiki/ext-trunk/MassEditRegex/MassEditRegex.class.php on line 447 although the same version works well under MediaWiki 1.19alpha (r104607). With MediaWiki 1.18.0 an older version of MassEditRegex (updated in Aug. 2011) gives again the blank page.
Hmm, there's probably not much I can do there. The edit API was changed after 1.17 and I can't figure out how to obtain the correct edit token any longer. Using the DerivativeRequest class fixes this, but apparently that only comes about in 1.19. You could try changing DerivativeRequest back to FauxRequest (and removing the $wgRequest parameter in the constructor) to see if that helps. Or, you could remove the $wgOut->disable() call which may allow you to see some error messages instead of the blank page. I do have plans to do away with the edit API call entirely and replace it with direct function calls, in the hope that this speeds up the process as it is extremely slow at present. Maybe once that happens it will work with 1.18.
(In reply to comment #11) > Hmm, there's probably not much I can do there. The edit API was changed after > 1.17 and I can't figure out how to obtain the correct edit token any longer. > Using the DerivativeRequest class fixes this, but apparently that only comes > about in 1.19. Eh? It's still the same http://en.wikipedia.org/w/api.php?action=query&prop=info%7Crevisions&intoken=edit&titles=Main%20Page&rvprop=timestamp%7Cuser%7Ccomment%7Ccontent
Something to do with edit tokens was changed, and how they are passed through the FauxRequest PHP class. 1.17 works, 1.18+ returns "bad edit token" errors.
