Last modified: 2014-03-10 23:21:47 UTC
+++ This bug was initially created as a clone of Bug #62486 +++ The Compatibility ( http://www.mediawiki.org/wiki/Compatibility ) page states that MediaWiki 1.19.x branch is compatible with PHP 5.2.3+ The core extension Renameuser uses the __DIR__ magic constant that is available in PHP 5.3.0+ only. Had to use the following command as a temporary fix: find . -type f -exec sed -i 's/__DIR__/dirname(__FILE__)/g' {} \;
Are you sure you are using the REL1_19 branch? https://github.com/wikimedia/mediawiki-extensions-Renameuser/tree/REL1_19 reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/extensions/Renameuser$ git checkout 9fea8b4ab306a786bef073c1b4802e4f155f581d Note: checking out '9fea8b4ab306a786bef073c1b4802e4f155f581d'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at 9fea8b4... Localisation updates for core and extension messages from translatewiki.net reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/extensions/Renameuser$ grep __DIR__ * reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/extensions/Renameuser$
I went to https://www.mediawiki.org/wiki/Download and downloaded the 1.19.12 tarball: $:andre\> pwd /home/andre/mediawiki-1.19.12/extensions/Renameuser $:andre\> grep __DIR__ * cleanupArchiveUserText.php: $IP = __DIR__ . '/../..'; renameUserCleanup.php: $IP = __DIR__ . '/../..'; Renameuser.php:$wgExtensionMessagesFiles['Renameuser'] = __DIR__ . '/Renameuser.i18n.php'; Renameuser.php:$wgExtensionMessagesFiles['RenameuserAliases'] = __DIR__ . '/Renameuser.alias.php'; Renameuser.php:$wgAutoloadClasses['RenameuserHooks'] = __DIR__ . '/Renameuser.hooks.php'; Renameuser.php:$wgAutoloadClasses['RenameUserJob'] = __DIR__ . '/RenameUserJob.php'; Renameuser.php:$wgAutoloadClasses['RenameuserLogFormatter'] = __DIR__ . '/RenameuserLogFormatter.php'; Renameuser.php:$wgAutoloadClasses['RenameuserSQL'] = __DIR__ . '/RenameuserSQL.php'; Renameuser.php:$wgAutoloadClasses['SpecialRenameuser'] = __DIR__ . '/specials/SpecialRenameuser.php'; SpecialRenameuser.php:require_once( __DIR__ . '/Renameuser.php' ); grep: specials: Is a directory
In that case I suspect it's time we double check that the release script doesn't boldly fetch master. Even with a .0 release (e.g. 1.20.0) bundling master is a problem because when the bundle is made, it will have been X amount of time since the core branch and extension branches were created and more often than not, breaking changes are held back and land as soon as we branch, and then extensions are updated to work with it. We ran into other bugs in the past when a 1.x.0 release was bundled with the then-latest-master versions of extensions (Cite, Vector, WikiEditor etc., released by Mark H. that time). This was a hurdle to deal with, and lead to all kinds of awkward bug reports on bugzilla and the support desk for many months to come that we couldn't really do much with. Especially for later point releases it is very important not to fetch master since it will have been a long time since that release was originally branched from master. Assuming that this was not fixed and we've been bundling master all this time for all releases, perhaps it's time to roll out a minor release back to 1.19.x fixing the extension versions back to where they should be? Or at least for those extensions in those releases where we know things broke (e.g. 1.19 and Renameuser). And of course to fix the script (assuming it isn't done by hand, are these instructions documented somewhere) to do it right from now on.
I think it does fetch master, there's a bug about 1.22.3 release being broken in the way it's described here. Other releases are probably affected as well.
(In reply to Bartosz Dziewoński from comment #4) > I think it does fetch master, there's a bug about 1.22.3 release being > broken in the way it's described here. Other releases are probably affected > as well. Sigh. So this is a bug in the tarball but not in the code repository of the extension... Workaround is to manually get the extension code from Git, I guess. Closing as INVALID here for the code repository; tracking the problem with the tarballs in bug 62101. Maxim: Thanks for catching this. :-/
