The maintenance directory is supposed to be a PSR-4 root, but most of the file names are not correct for that, which makes using them with run.php annoying (short syntax like run.php CentralAuth:FixStuckGlobalRename doesn't work).
Description
Description
Event Timeline
Comment Actions
Maybe I'm missing something, but even for core, some of the maintenance scripts are not properly namespaced or made to follow PSR-4 at all. Take update.php for example, running php maintenance/run.php Update --wiki=metawiki works for me.
root@12c7b9adee94:/var/www/html/w# php maintenance/run.php Update --wiki=metawiki MediaWiki 1.46.0-alpha Updater Your composer.lock file is up to date with current dependencies! Going to run database updates for metawiki Depending on the size of your database this may take a while! Abort with control-c in the next five seconds (skip this countdown with --quick) ...0 ...skipping update to shared table objectcache. ...skipping update to table globaluser in shared virtual domain. ... ...site_stats is populated...done. Skipped 69 updates that were already applied. Purging caches... Done in 0.3 s.
To add, I tried to run the CA command you used above, and it seems to work:
root@12c7b9adee94:/var/www/html/w# php maintenance/run.php CentralAuth:FixStuckGlobalRename --wiki=metawiki
ERROR: Option --logwiki is required!
ERROR: Argument <oldname> is required!
ERROR: Argument <newname> is required!
Unstuck global rename on a single wiki
Usage: php maintenance/run.php CentralAuth:FixStuckGlobalRename [OPTION]... --logwiki <LOGWIKI> <oldname> <newname>
Script runner options:
--conf <CONF>: Location of LocalSettings.php, if not default
--globals: Output globals at the end of processing for debugging
--help (-h): Display this help message
--memory-limit <MEMORY-LIMIT>: Set a specific memory limit for the
script, "max" for no limit or "default" to avoid changing it
--profiler <PROFILER>: Profiler output format (usually "text")
--quiet (-q): Whether to suppress non-error output
--server <SERVER>: The protocol and server name to use in URLs, e.g.
https://en.wikipedia.org. This is sometimes necessary because server
name detection may fail in command line scripts.
--wiki <WIKI>: For specifying the wiki ID
Common options:
--dbgroupdefault <DBGROUPDEFAULT>: The default DB group to use.
--dbpass <DBPASS>: The password to use for this script
--dbuser <DBUSER>: The DB user to use for this script
Script specific options:
--ignorestatus: Ignore rename status. Don't do this when the rename
jobs might still be running.
--logwiki <LOGWIKI>: Wiki where the log entry exists
Arguments:
<oldname>: Old name
<newname>: New nameroot@12c7b9adee94:/var/www/html/w# php maintenance/run.php CentralAuth:FixStuckGlobalRename --logwiki=metawiki Admin Admin --wiki=metawiki Admin does not have a rename in progress on this wiki. root@12c7b9adee94:/var/www/html/w#
The maintenance runner performs some "magic" under the hood to extract the script class name from the filename using the $maintClass variable, so I'm not sure why it's not working. But I agree that making our maintenance scripts PSR-4 compliant would be really nice.
Comment Actions
Interesting, I get
Script 'CentralAuth:FixStuckGlobalRename' not found (tried path '/vagrant/mediawiki/extensions/CentralAuth/maintenance/FixStuckGlobalRename.php' and class 'MediaWiki\Extension\CentralAuth\Maintenance\FixStuckGlobalRename').
Comment Actions
Yes @Zabe. I'm using a Mac. Does your question suggest this is file system related? IIUC, macOS and Linux use two different file systems.