Last modified: 2013-04-22 16:15:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T44729, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 42729 - UW master not compatible with MW 1.20.x
UW master not compatible with MW 1.20.x
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
UploadWizard (Other open bugs)
master
All All
: Unprioritized major (vote)
: ---
Assigned To: Lupo
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-05 16:19 UTC by Lupo
Modified: 2013-04-22 16:15 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Lupo 2012-12-05 16:19:26 UTC
See

https://bugzilla.wikimedia.org/show_bug.cgi?id=42640#c16

MW 1.20.x doesn't have the ApiQueryORM class.

Users can only download the git master version of UW at

http://www.mediawiki.org/wiki/Extension:UploadWizard

and the extension distributor at

http://www.mediawiki.org/wiki/Special:ExtensionDistributor?extdist_extension=UploadWizard

just offers 1.19x as default choice, but then fails saying "Invalid response from Extension Distributor remote client."

The UploadWizard git repo has no tag for MW 1.20.x.

Hence users can only download the git master UW. That, however, requires the ApiQueryORM class to be present. Therefore it doesn't work with a vanilla MW 1.20.x install.

MW 1.20.x is, at the time of this writing, the latest stable version.

So please, either

* fix this such that people can download somewhere a version of UploadWizard that is compatible with MW 1.20, or

* make sure that git master remains compatible with the latest stable release, or

* find some other simple solution such that people can use UW with MW 1.20.x.
Comment 1 Jeroen De Dauw 2012-12-05 16:35:12 UTC
I created a tag "mw1.20" on the commit before the one making use of ApiQueryORM.

We could conditionally load the new API module depending on MW version. Can you first specify the exact nature of the problem though? Running master with MW 1.20 should not cause any problems due to ApiQueryORM unless you actually hit the API module.
Comment 2 Lupo 2012-12-05 16:50:42 UTC
See bug 42640. I can't tell you more than that; I personally don't have an MW 1.20 install.

I don't know why the user's MW 1.20 install even tried constructing that class. Maybe it's some peculiarity of EasyPHP-12.1?
Comment 3 Lupo 2012-12-05 20:32:26 UTC
Nope, it's definitely not related to EasyPHP-12.1. Verified this with a local install of MW 1.20 (on Mac OS X 10.7.5).

The reason for the non-compatibility is that in MW 1.20 (up to and including 1.20.2), ApiQuery instantiates all generator modules in its constructor, and ApiQueryUploadCampaigns is a generator module.

So you really mustn't register ApiQueryUploadCampaigns with the autoloader unless
$wgAutoloadClasses['ApiQueryORM'] is set. Also, you may set

$wgAPIListModules['uploadcampaigns'] = 'ApiQueryUploadCampaigns';

if $wgAutoloadClasses['ApiQueryORM'] is set.
Comment 5 Lupo 2012-12-05 22:01:52 UTC
(In reply to comment #3)
> The reason for the non-compatibility is that in MW 1.20 (up to and including
> 1.20.2), ApiQuery instantiates all generator modules in its constructor, and
> ApiQueryUploadCampaigns is a generator module.

More precisely: ApiQuery::__construct() calls ApiQuery->makeGeneratorList(), going through all registered prop and list and modules and testing each one whether it is_subclass_of() ApiQueryGeneratorBase. is_subclass_of() instantiates the class, which in the case of ApiQueryUploadCampaigns needs ApiQueryORM.

That was removed in https://gerrit.wikimedia.org/r/#/c/22936/ because it loads all modules' classes. Alas, that was after MW 1.20.
Comment 6 Jeroen De Dauw 2012-12-05 22:18:03 UTC
> More precisely: ApiQuery::__construct() calls ApiQuery->makeGeneratorList(),

Ah, did not know this :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links