* Inappropriate @inheritDoc usage. Arguably all @inheritDoc is
inappropriate but these are the ones PHPStorm flags as misleading
due to the method not being inherited.
* Doc comment type does not match actual argument/return type.
* I replaced "@return void|never" with "@return void" since never means
never, it doesn't make sense for it to be conditional. If a method
can return (even if that is unlikely) then @return contains the type
that it returns. "@return never" means that there is no such type
because the method never returns.
* Incomplete/partial/broken doc tags
Change-Id: Ide86bd6d2b44387f37d234c2b059d6fbc42ec962
* Move the PHP_SAPI check to the earliest convenient point in
Maintenance.php, well before we attempt to access $argv.
* Remove the register_argc_argv check altogether; we don't allow "cgi"
SAPI to be used for running scripts from the command line any more.
Any value from php.ini is overridden by "cli" and "phpdbg" SAPIs:
https://www.php.net/manual/en/features.commandline.differences.phphttps://github.com/php/php-src/blob/php-8.2.1/sapi/phpdbg/phpdbg.c#L991
And using "-d register_argc_argv=0" or similar seems unlikely.
* Don't check if $IP is null (reverts b0647c30bc). This specific
check is not useful any more, as $IP is now initialized before the
Maintenance object is constructed, and addOption() and similar methods
happen to generate PHP errors in the described situation. If desired,
a check serving the same purpose could be added in a separate commit.
Change-Id: I8032ab18cb26d92ee01ab9851ea1d45b3f9eadbf
This allows a file other than LocalSettings.php to be used as the primary
settings file by setting the MW_CONFIG_FILE environment variable.
This also allows the primary settings file to use YAML or JSON format.
Using static configuration files should be the default in the future.
However, YAML files in the document root could easily be exposed to the
public. Better not to encourage that, and require them to be enabled
explicitly and loaded from a different place.
Bug: T294750
Change-Id: I7747f83481cb05a6d05f819be652259951183819
This moves the definition of the RUN_MAINTENANCE_IF_MAIN constant
in Maintenance.php before the check on MEDIAWIKI, so the constant will
be defined even if MEDIAWIKI is also defined. This allows maintenance
scripts to be successfully loaded in a context in which MEDIAWIKI is
already defined, but RUN_MAINTENANCE_IF_MAIN is not. Without this
change, such an attempt would fail with a warning that the constant is
undefined at the bottom of the maintenance script.
A notable use case for loading a maintenance script inline is calling
RunJobs in a test case. This would work fine if the test is called via
MediaWiki's phpunit wrapper, since that wrapper is itself written as a
maintenance script, and thus declared RUN_MAINTENANCE_IF_MAIN.
However, integration tests may also be invoked without the wrapper,
using the phpunit.xml.dist config file instead. This is the standard way
to invoke PHPUnit from within an IDE like PhpStorm, allowing for debugging
of unit tests.
So, without this patch, integration tests that call RunJobs fail due to
an undeclared constant when run via IDE integration. With this patch,
they work properly.
Change-Id: I52889e092cc9f20bf892c297635b87a972dafa41
Many files were in the autoloader despite having potentially harmful
file-scope code.
* Exclude all CommandLineInc maintenance scripts from the autoloader.
* Introduce "NO_AUTOLOAD" tag which excludes the file containing it
from the autoloader. Use it on CommandLineInc.php and a few
suspicious-looking files without classes in case they are refactored
to add classes in the future.
* Add a test which parses all non-PSR4 class files and confirms that
they do not contain dangerous file-scope code. It's slow (15s) but
its results were enlightening.
* Several maintenance scripts define constants in the file scope,
intending to modify the behaviour of MediaWiki. Either move the
define() to a later setup function, or protect with NO_AUTOLOAD.
* Use require_once consistently with Maintenance.php and
doMaintenance.php, per the original convention which is supposed to
allow one maintenance script to use the class of another maintenance
script. Using require breaks autoloading of these maintenance class
files.
* When Maintenance.php is included, check if MediaWiki has already
started, and if so, return early. Revert the fix for T250003 which
is incompatible with this safety measure. Hopefully it was superseded
by splitting out the class file.
* In runScript.php add a redundant PHP_SAPI check since it does some
things in file-scope code before any other check will be run.
* Change the if(false) class_alias(...) to something more hackish and
more compatible with the new test.
* Some site-related scripts found Maintenance.php in a non-standard way.
Use the standard way.
* fileOpPerfTest.php called error_reporting(). Probably debugging code
left in; removed.
* Moved mediawiki.compress.7z registration from the class file to the
caller.
Change-Id: I1b1be90343a5ab678df6f1b1bdd03319dcf6537f
Originally submitted as commit 2cdeb26d0c.
This patch is fully backwards compatible. The Maintenance.php entry
point is now a true entry point (i.e. no classes defined), and it requires
all the *Maintenance classes.
Bug: T246780
Change-Id: I75b22f54b19fe560ab71349189598245af1c5693
In a generic context, $argv would be considered tainted by taint-check,
which makes sense for certain applications. In the context of MW
maintenance scripts, however, we can assume that arguments are trusted,
because maintenance scripts can only be executed by sysadmins, who are
generally trusted (and even if they aren't, they have other ways to
compromise a wiki).
Bug: T216348
Change-Id: I8e171f5dcd5b9232d45e85d775cd794f2ebb2dfc
Per 4eb1e679d5, these are now documented as the bare minimum
entry point responsibilities. For WebStart these are already
consolidated, but for the CLI use case they were a bit scattered.
Consolidate these in the CLI entry point (doMaintenance.php)
for clarity.
* $IP was previously assigned in Maintenance::__construct,
which is called from doMaintenance.php.
It still executes at the same logical time, one line above
'new $maintClass()'.
* MEDIAWIKI was (for CLI) previously defined in Maintenance::setup()
which is called from doMaintenance.php.
This is now done a few lines earlier, and in the entry point file
instead.
For both of these, they are still available and set in all the same
scenarios as before.
Bug: T246076
Bug: T250003
Change-Id: I2a6f5e997a36502535eb383a95deac0ce74d83fb
Maintenance.php may be included after other entry points in certain
configurations (like IDE bootstrapping). So if MW_ENTRY_POINT is already
set, don't try and define() it as another value.
Bug: T250003
Change-Id: Ide011ad11d8dd29fe786a745c6e67259e46b9bfb
I added this in fdb7d36903 when DevelopmentSettings.php was fairly
basic and might have even been harmless to include in production
(unverified at this point).
The use case was easy injection by WMF CI and Travis CI,
but we never ended up using that. Both for CI and for local
development we have converged on the debuggable/non-magical way
of injecting it, which is explicitly placing it in LocalSettings.php
at the point where the developer is in control of it.
It also means it consistently applies no matter which script you
run, including on the web, which makes sense as the site settings
shouldn't change unexpectedly.
An alternative might be to make this configurable and only
available in a special development mode, and not in prod. However
that creates a bit of a paradox. If we require admins to place
something in LocalSettings to make this available, might as well
make that line of code be "require DevelopmentSettings.php",
equally easy to copy/paste and comment out.
Change-Id: Iffc58599581bf20b5880b7c57259e8b37ddf9dcb
Split Maintenance::showHelp() from Maintenance::maybeHelp(), and
override it in phpunit.php. Expose PHPUnit's protected method
Command::showHelp() in our subclass and call it, so that running
"phpunit.php --help" causes the MediaWiki options to be shown, followed
by the PHPUnit options.
Change-Id: I4687d484e322a465af0492789645819cd8a7b67c
Resolve error with showJobs.php --mwdebug option. Previously, it displayed an error if not followed by "=1".
This was resolved by changing
$this->addOption( 'mwdebug', 'Enable built-in MediaWiki development settings', false, true );
to
$this->addOption( 'mwdebug', 'Enable built-in MediaWiki development settings', false, false );
Bug: T233257
Change-Id: I322fa539a302c2726fffd2420f7f56aec476b32b
This allows us to remove many suppressions for phan false positives.
Bug: T231636
Depends-On: I82a279e1f7b0fdefd3bb712e46c7d0665429d065
Change-Id: I5c251e9584a1ae9fb1577afcafb5001e0dcd41c7
Define the global constant MW_REST_API in rest.php, by analogy with
MW_API. Also generalize this by adding MW_ENTRY_POINT, which contains
the entry script name, "cli" or "unknown". This allows tests such as
if ( MW_ENTRY_POINT !== 'index' )
which is probably what is really intended by defined('MW_API') in many
cases.
Change-Id: I24099f4cdd170de17afd6e1bbad67c9b204071fc
Make it Profiler.php's responsibility to enforce this, based on the
existing signal from ProfilerOutput::logsToOutput().
The ProfilerOutputText class should not have to double-check this
a second time.
Long-term, I'd like even this check in Profiler::logDataPageOutputOnly
to be removed, because really the external caller of that should
know whether it is safe to output stuff or not rather than stashing
its own state inside Profiler::$allowOutput and then implicitly
reading it back out again later on. But, that's for another time.
Also:
* Remove use of deprecated Profiler::setTemplated while at it.
* Make 'visible' parameter explicit, as for other parameters.
Change-Id: Iaa3fc4ea25a059b90235d769db60c04b8f152f05
Subclasses of LoggedUpdateMaintenance tell the user that "Update
'{$key}' already logged as completed". This adds "Use --force to
run it again."
Bug: T200653
Change-Id: I8cf3c5383c0fecdc92b58048138332855b5602a6
Document callback as callable type and the results part as
IResultWrapper to match the implementation, which is passing return of
Database::query to this function
Change-Id: I63ee8d4907590a21ef34d0b761b8fabfe0ff2569
Otherwise, if running update.php, there are require_once failures from
extensions (at least Echo and Flow) if they aren't inside extensions/ --
e.g., if they're just symlinked from there.
Change-Id: Iaf4231abae1621627f01171f955b5bb7a0fa77d8
Benefit of keeping the parameter optional:
- In maintenance scripts that really only have one parameter, it's a
little more convenient to be able to ask for *the* parameter via an
empty getArg().
Disadvantages:
- It's unclear what getArg() means when there is no indication *which*
argument the code asks for. This might as well return the last
argument, or an array of all arguments.
- In scripts with two or more arguments, it's confusing to see
getArg( 1 ) next to an empty getArg().
- The methods are more complex and a bit more complicated to use with
the extra feature of this parameter being optional. Users need to
look up what the default is to be able to use it safely.
Change-Id: I22a43bfdfc0f0c9ffdb468c13aba73b888d1f15e
T110209 caused maintenance scripts to fail on unknown parameters,
which is normally desirable. However, some extensions (notably
SemanticMediaWiki) need to support additional params and had no
way to add them to the list of expected parameters. It will
now be possible them to update.php via a new hook:
MaintenanceUpdateAddParams.
Bug: T213893
Change-Id: Ia40949ccb2f32090f21e0f3f7e5b9c4aef322330
This gets rid of a few if(), count() and such that make the code appear
quite complicated, even if it isn't.
Change-Id: Iade6589eba2a9496b28042bfc777b92258b3332a
