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
Since MediaWiki 1.18, $wgServer has been automatically set by the web installer
when it generates LocalSettings.php, so this shouldn't be an issue for most
wikis. The CLI installer now supports a --server optional parameter to
specify $wgServer, otherwise it'll be set to 'http://localhost' by default.
Users will see a fatal error pointing them to the on-wiki $wgServer
documentation that I've updated as well.
Originally this functionality was slated for removal in 1.20, but now is
just a good time as any. It also calls into other parts of MediaWiki before
most things are initialized, making it difficult to librarize some code.
Bug: T30798
Bug: T232931
Change-Id: Ia5d616e7fafbab01655067c24c5a3a073b254f21
The following function are set to public in the parent class and cannot
have another visibility in subclasses
Maintenance::__construct
Maintenance::execute
Maintenance::getDbType
Maintenance::validateParamsAndArgs
Maintenance::setDB
Change-Id: I0cd6514642d479aca20f1221bf673b0713c21631
This reverts commit cc7ec36a57.
It makes the following changes from the original patch:
* findExtensions() will not consider config-extension-not-found as an
error.
* Fixed a bug where extension info wouldn't actually be returned by
findExtensions().
* When an extension's dependency doesn't exist, wrap the
config-extension-not-found error in config-extension-dependency.
This makes it more clear, and prevents the error from being ignored
per the first bullet.
* maintenance/install.php will use ->text() rather than ->parse()
when printing thrown errors.
* Change the stuff done to make phan happy.
Bug: T225512
Change-Id: I7d29700e8b7e91841556847d669b350cbd306fe6
Previously, if there was an error during CLI installation,
CliInstaller::showStatusMessage() exited the script directly. The exit
timing of the script should be given to the caller, not the callee.
So, I coding:
[1] Remove `exit()` from CliInstaller::showStatusMessage()
[2] Make the callee to return Status, the caller determine how to handle these Status
[3] Strictly check the key database type instead of just outputting message
Bug: T46511
Change-Id: I72ffd33fe5c592b9ea78f37bae5a9c081295c624
In the web installer this isn't the last step and there is a different
success message. Replace the existing config-install-success with a
much more generic config-install-db-success message.
Previously we were telling people to go to their wiki prior to
them downloading LocalSettings.php which would obviously not work.
Change-Id: I56e28157a1a4d55e4eeda5fdd536289960511938
Allow the extensions and skins installed by maintenance/install.php to
be customised using --skins= and --extensions=. If the argument is
am empty string then no extensions/skins are installed. For backwards
compatibility, the default is to install all skins, but to install all
extensions only if --with-extensions is given.
The new CLI options may be specified multiple times, but for
convenience, comma-separated lists can also be used.
Also:
* Rename $option to $options
* If an extension has a dependency error, propagate the very readable
error message generated by ExtensionRegistry back to the user.
* Split getExtensionInfo() from the loop body of findExtensionsByType(),
so that CliInstaller can use it to validate its parameters and get
error messages.
* I didn't like the idea of removing the "s" from the directory name in
order to construct the JSON file name, so I split
findExtensionsByType() from findExtensions(), with the former not
having this hack. In findExtensions(), make the previous assumption
that the directory name is always "extensions" or "skins" explicit,
throwing an exception if it is otherwise.
Change-Id: Id0fb63cd4e61a047ef3396ee1c38d6073dfc7fd1
For CI, I went with a dirty trick to find extensions and either
wfLoadExtension() or include them. That has since been ported to
Installer::findExtensions() and LocalSettingsGenerator::getText().
The WebInstaller() relies on that to detect extensions and let the user
tick the ones to be installed.
Add --with-extensions to install.php so one can include all extensions
from the command line.
Note: The CliInstaller always wfLoad() any skin it can find.
The original patch 53926d9d was broken and got reverted. This is the
proper one.
Bug: T189567
Change-Id: I41820fce12e01224d64ab711e016835ef4d4febc
It is blatantly broken using non existing variables:
$installer and $options
This reverts commit 53926d9d69.
Bug: T189567
Change-Id: Idd1f002bbd5d474f9fe386cd0e326e1fbfdec097
For CI, I went with a dirty trick to find extensions and either
wfLoadExtension() or include them. That has since been ported to
Installer::findExtensions() and LocalSettingsGenerator::getText().
The WebInstaller() relies on that to detect extensions and let the user
tick the ones to be installed.
Add --with-extensions to install.php so one can include all extensions
from the command line.
Note: The CliInstaller always wfLoad() any skin it can find.
Bug: T189567
Change-Id: Ic8aa6bea4e7294e54fd5b71df267c9e934f78fce
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
dirname( __FILE__ ) was used because it worked in PHP 5.2, allowing
the version check to function correctly. However, Maintenance.php
now uses the short array syntax, which is a parse error before 5.4:
> Parse error: syntax error, unexpected '[' in maintenance/Maintenance.php
> on line 66
Also, do the same in install.php where it includes Maintenance.php.
Change-Id: I3373a02c684bb6cbde83d7bedc204818f3394602
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
Due to changes made to support Microsoft SQL Server, $wgDBmwschema changed its default from
"mediawiki" to null in DefaultSettings.php, as anything else horribly broke every DBMS that did
not use schemas (such as MySQL and SQLite). This change makes it so that the default value can
be properly overridden again by PostgreSQL and Microsoft SQL Server, and also enables the
--dbschema flag to the CLI installer.
Bug: 64043
Change-Id: Id364306d883e0d494b948854e05f3f79ba7dd6d2
- Fix description of the "admin" option, which says there's a default,
"WikiSysop", when this isn't the case.
- Use "MediaWiki" instead of "Don't care" as the default value
for the "name" argument
- make the "name" argument optional, so that its default value
can actually work as such
- test for getOption's default parameter value (null)
rather than providing one (false) and testing for it
- fix indication of default value for --dbpath
and document where it comes from
- format the default for --confpath
the same way as other defaults are displayed
- add description
- use trim() for --passfile, as is done for --dbpassfile
- use single quotes where possible
- mention in the documentation where the default values come from
- various minor text adjustments
- bonus: typo fix in a comment in Maintenance.php
Change-Id: Icbc0b02cfbf09b3f97ed86f4a68c3b35a9c839c8
Shouldn't be needed and aren't for any core operations. If any
extension relies on these $wgTitles being set in maintenance
environments those extensions are broken and should be fixed.
Change-Id: Ie02a5042ab96e155d783d56d5340dd0da8e3d55c
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
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
update.php and install.php now use wfPHPVersionError()
Moved to wfPHPVersionError( cli ) the suggestion of another binary name.
Old PHP versions won't have $_SERVER superglobal, hardcode HTTP/1.0 in that case.
Store in a variable the minimum version of PHP supported by MediaWiki.
Changed PHP_VERSION to phpversion(), although it doesn't matter for the version
ranges this works.
phpversion() has been present since PHP-2.0
PHP_VERSION was added in PHP 3.0RC5
On its current form in PHP 4 it was moved from Zend/zend_constants.c
to main/main.c by Zeev in commits 71dddd7db7e768ae8145e085fcbb6b6db4a1c40a and
fb1c77bd4f8a636ba47d720f8ca65fc6baae836d (1999-12-17)
It had been commented there since the beginning of svn history (1999-04-07)
The earliest version we can target seems to be PHP 4.1.0
PHP 4.0.0 produces a parse error on a require_once not followed by a literal
path (although you can use require with an expression), plus its dirname()
is quite dumb, and wouldn't provide the right path (would require you to call
"php ./update.php" from maintenance folder, not "php update.php" or
"php maintenance/update.php" from the main dir)
Replacing pathinfo( $_SERVER['SCRIPT_NAME'], PATHINFO_DIRNAME ); into a pathinfo()
to another variable since pathinfo( "", PATHINFO_DIRNAME ); core dumps in PHP 4.1.0
(works if $path is not empty)
The value of the pragma directive is 'no-cache', not 'nocache'. See section 14.32
of rfc2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32
Change-Id: I6294e86a5f3e11b9ea0f62762815e7c71b9037ce
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
...after a discussion with Debian packagers. They can now override installer
classes and change LocalSettings.php the installer generates. The file
intended for such overrides, mw-config/overrides.php, has intentionally been
placed outside of includes to underline the "don't change includes" paradigm.
Change-Id: Id82b90f6740307609bc6c6f4fb8765bc3484dbe7
the command line, so that it isn't exposed in the process list.
Sadly, use of /dev/stdin or <(process) doesn't work in Linux,
since they are shown as symlinks to pipe:[12345678] and php
dereferences all of them. It has to be a real file.
However, such constructs work in Solaris, where they are
presented as character devices.
