Why:
* Maintenance scripts in core have bolierplate code that is
added before and after the class to allow directly running
the maintenance script.
* Running the maintenance script directly has been deprecated
since 1.40, so this boilerplate code is only to support a now
deprecated method of running maintenance scripts.
* This code cannot also be marked as covered, due to PHPUnit
not recognising code coverage for files.
* Therefore, it is best to ignore this boilerplate code in code
coverage reports as it cannot be marked as covered and also
is for deprecated code.
What:
* Wrap the boilerplate code (requiring Maintenance.php and then
later defining the maintenance script class and running if the
maintenance script was called directly) with @codeCoverageIgnore
comments.
* Some files use a different boilerplate code, however, these
should also be marked as ignored for coverage for the same
reason that coverage is not properly reported for files.
Bug: T371167
Change-Id: I32f5c6362dfb354149a48ce9c28da9a7fc494f7c
And start using them instead of wfGetDB(), LB/LBF connection methods or
worse, $this->getDB().
$this->getDB() reuses the database object regardless of whether you're
calling a replica or primary, leading to returning a replica on a
primary and other way around.
Bug: T330641
Change-Id: I9e2cf85ca277022284fc26b9f37db57bd12aaa81
That trigger an update of config and in the next call, it shouldn't show
up anymore. The whole thing needs to be revamped but oh well.
Bug: T348428
Bug: T348419
Change-Id: I4a8631d821bed97aa36d0371de3504fe5b3b3d5e
Shown on php8.1:
Deprecated: Implicit conversion from float 0.05353713035583496 to int
loses precision in maintenance\updateSpecialPages.php on line 169
Change-Id: I0b70e1f5db182ef17018eeac099252694c83eea4
Maintenance class provides a method for getting a fresh reference
of the MW services container instance. Let's make use of these in
maintenance scripts now that we have it.
NOTE: There are still some static methods like in refreshLinks.php
that makes use of services that we can't use this method for now.
Change-Id: Idba744057577896fc97c9ecf4724db27542bf01c
Fix MediaStatistics if $wgQueryCacheLimit is very small to still show
all entries as documented in the class.
Found by phan strict checks
Change-Id: Ic1a8a66063f6604db4a7e92c46df94a3f6d97711
Returning void from execute() is success.
Returning true is success, false is failure with exit(1)
Using fatalError also using exit(1)
Change-Id: I1d40430ad6226e4aab8f0810b03ee1213282d123
If a special page is no longer expensive (by code or by config like
DisableQueryPages) the data should not longer stored in the database,
because always fresh data are shown and never the cached data
This does not delete on disabled query pages, because the data still
visible on the page.
This only affectes query pages and not very special pages like
ActiveUsers
Bug: T174513
Change-Id: Ia9015cb7bc0ab7b1a3d96d1b481c31b3e6c39657
The run mode is used to show a different message on the special page,
instead of the current one "Updates for this page are currently
disabled. Data here will not presently be refreshed." even the data gets
updated with a different cron job.
Bug: T78711
Change-Id: Ib63d16bfea477dec43323b39671cc068530e2f0b
The most notable removal is done in the orphans script. This code was
really never used. Brion introduced it in 2005, already disabled.
I have all the respect for what Brion did. I just think it does not make
much sense to keep code around for so long if it does not work anyway,
and must be rewritten from scratch anyway now that we have multi-content
revisions and such.
Change-Id: I4e8050929f90e44a6e6051bf938993a8b0cdf649
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
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Deprecate the second argument to Maintenance::error() in favor of a new
Maintenance::fatalError() method. This is intended to make it easier to
review flow control in maintenance scripts.
Change-Id: I75699008638f7e99b11210c7bb9e2e131fca7c9e
Special page updates on commons have been broken recently due
to Mysql "going away" after doing the ActiveUsers special page
cache update. Presumably this is because we were only repinging
the server after QueryPage updates, and not the callback updates
(Combined with a spike in wikidata recentchanges entries making
the ActiveUsers callback now take about an hour to complete)
Bug: T176055
Change-Id: Ic344940460c353544d7c08bbe2d8c900f6cc73da
It has a first parameter to directly get the value as float, so use it
instead of doing string manipulation.
Change-Id: Id2dff4486ea4f308ce03fc3d5546660c4e3c26b6
... now that f508561f7b ("Moved $wgQueryPages stuff out of the global
scope and into a function") has been merged, which eliminated hardcoding
of the pathname except in the AutoLoader.
WantedQueryPage is moved to a separate file.
Bug: 60445
Change-Id: If2019492722083819b82afa6302670b94b181098
The COMMIT in updateSpecialPages.php was unmatched and just logged an
error. We would like the stale results to still be presented to the user
during the hours of query execution time, so doing a DELETE in
autocommit mode before the main query starts does not seem appropriate.
And holding a master transaction open for hours, with a lock on
querycache, is certainly not the right way to do it.
So, move the DELETE to after the completion of the main query, and wrap
a transaction around the updates to querycache and querycache_info so
that the user always sees a consistent populated UI. Remove the
unmatched COMMIT from updateSpecialPages.php.
Change-Id: I27c22b96f43a1064eb17a0c6a1c56d1f4a2dff9a
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
Squiz.WhiteSpace.LanguageConstructSpacing:
Language constructs must be followed by a single space;
expected "require_once expression" but found
"require_once(expression)"
It is a keyword (e.g. like `new`, `return` and `print`). As
such the parentheses don't make sense.
Per our code conventions, we use a space after keywords like
these. We appeared to have an unwritten exception for `require`
that doesn't make sense. About 60% of require/include usage
was missing the space and/or had superfluous parentheses.
It is as silly as print("foo") or return("foo"), it works
because keywords have no significance for whitespace between
it and the expression that follows, and since experessions can
be wrapped in parentheses for clarity (e.g. when doing string
concatenation or mathematical operations) the parenthesis
before and after basiclaly just ignored.
Change-Id: I2df2f80b8123714bea7e0771bf94b51ad5bb4b87
Related to bug 42210, we don't have a blank line, not knowing what it's actually running
QueryPage updates do this already!
Change-Id: I18eb0fb4c316744d92a81f5e64e201508b27eb27
We can now do this since we finally switched to PHP 5.3 for MW 1.20 and get rid of the silly dirname(__FILE__) stuff :)
Change-Id: Id9b2c9cd2e678197aa81c78adced5d1d31ff57b1
Also make a few changes to the functions available. SpecialPageFactory::resolveAlias() now takes an optional subpage and returns array(<name>,<subpage>). Similarly merge getPage() and getPageByAlias(). There were many examples of (extensions particularly) making dubious assumptions about the presence or absence of subpages or canonical-ness.
I didn't deprecate SpecialPage::getTitleFor() as it's got over six hundred calls. I'm rather undecided on the best position of getPage()/executePath(). Although the latter needs cleanup anyway.
