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
Remove many references to database fields rev_text_id and ar_text_id,
which are being retired as part of MCR Schema Migration.
Some references remain, and will be removed under other patchsets
or other tasks.
Bug: T198341
Change-Id: Id044b8dcd7c9d09d5d6037eb732f6a105933f516
This is, in theory, a loophole that can not only cause such code to
consume suprising amounts of memory and runtime. It can also create
suprising results. For example, an input like
-param="might contain a = char"
might result in a cut-off value.
Not so much of a problem in a maintenance script. But still good
practice, I find.
Change-Id: I14fb278e6fdb61d0c486ca7e23229851ea479408
So the conditional check should by default return $this->mDb if it's not
null, so, the else seems not to be needed(?). If we have a database handle
to process the current batch, $this->getDB() will return IMaintainableDatabase
but if it's not available (null), a call to $this->getDB() will return an
instance of \Wikimedia\Rdbms\Database is returned instead.
In accordance with the documentation (phpdoc), update the method getUserDB()
to be compliant with callers return type.
Change-Id: I95f3407dd2ffe8e4a1ad7a70be86b6cf3b65ff50
* Remove obsolete handling for 'load.php', which no longer
uses this check. This hasn't been used for several releases.
* Remove the 'entryPoint' parameter in favour of 'format',
which it was already a proxy for.
* Move the double dirname() logic to mw-config/index.php.
Bug: T189966
Change-Id: I343216442475d36e61213900f196ab6ec5f6b747
Added spaces around .
Removed empty return statement which are not required
Removed return after phpunit markTestIncomplete,
which is throwing to exit the test, no need for a return
Change-Id: I2c80b965ee52ba09949e70ea9e7adfc58a1d89ce
For maintenance scripts it is usually harmful to throw an exception.
For jobs the exception was already caught and handled appropriately,
so this can continue as before. For DeferredUpdates it was extremely
harmful to throw an exception. So in the web case, reduce the timeout to
1s and continue as normal if the 1s timeout is reached. This allows the
DeferredUpdate to be throttled without being killed.
In the updater, increase the replication wait timeout to 5 minutes.
ALTER TABLE could indeed cause replication lag, but exiting the update
script with an exception will probably ruin your day. Update actions are
not necessarily efficiently restartable.
Do not call JobQueue::waitForBackups() when jobs are popped. Maybe it
makes sense to call a queue-specific replication wait function for
bulk inserts, like copyJobQueue.php, but doing it when jobs are popped
just makes no sense. Surely the worst that could happen is that the
queue would become locally empty? Removing this waitForBackups() call
avoids waiting for replication twice when JobQueueDB is used.
Bug: T201482
Change-Id: Ia820196caccf9c95007aea12175faf809800f084
Passing parameters not registered via standard mechanisms
(addOption/$optionsWithArgs/$optionsWihtoutArgs) will now
cause an error, unless, the script opts out via the new
setAllowUnregisteredOptions/$allowUnregisteredOptions.
Bug: T110209
Change-Id: I21957837f10852169ca3e1eeca9bf1f4052f8c0b
Idead2c11c4 deprecated and made nonfunctional the
$wgShowSQLErrors variable, but failed to remove its
usage from Maintenance.php.
This commit removes that usage and replaces it with the
new perferred method of enabling detailed output.
Bug: T165768
Change-Id: I98620ddd493703863755f426dd54f7a4e5ae05f1
This seems to work anyway (as no connections are needed at
this time), but I guess it's more robust to explicitly
destroy any existing instances.
Bug: T147169
Change-Id: Id56a62d1830fc1464a80dd4420ffddd797bf8b51
