Why:
* Maintenance scripts in core are mostly untested and testing them
will help to avoid regressions.
What:
* Create CommandLineInstallerTest.
Bug: T371167
Change-Id: Ia9ef03326d7c25b7eb310c191034932fffcbff8c
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
Start with the basic required arguments.
Leaves room for expansion.
Decided to have:
- 0 arguments = interactive
- 1+ argument results in regular validation messages
- --help outputs help as normal
- interactive mode mentions you might want --help
Bug: T48076
Change-Id: I972bf55f96c9cdf1a5eaf55c0e0117b190420d30
Allow Maintenance::error() and Maintenance::fatalError() to take
StatusValue objects. They now print each error message from the
status on a separate line, in English, ignoring on-wiki message
overrides, as wikitext but after parser function expansion.
Thoughts on the previously commonly used methods:
- $status->getMessage( false, false, 'en' )->text()
Almost the same as the new output, but it allows on-wiki message
overrides, and if there is more than one error, it prefixes each
line with a '*' (like a wikitext list).
- $status->getMessage( false, false, 'en' )->plain()
- $status->getWikiText( false, false, 'en' )
As above, but these forms do not expand parser functions
such as {{GENDER:}}.
- print_r( $status->getErrorsArray(), true )
- print_r( $status->getErrors(), true )
These forms output the message keys instead of the message text,
which is not very human-readable.
The error messages are now always printed using error() rather
than output(), which means they go to STDERR rather than STDOUT
and they're printed even with the --quiet flag.
Change-Id: I5b8e7c7ed2a896a1029f58857a478d3f1b4b0589
Maintenance::finalSetup should have access to a SettingsBuilder so it
can manipulates config settings without resorting to global variables.
MaintenanceRunner will always provide a SettingsBuilder when calling
this method, so implementations should be able to rely on always getting
one.
The $settings parameter was introduced as optional in order to maintain
backwards compatibility with implementations that did not declare the
parameter. But these should all have been fixed since.
Depends-On: I8a3699b13bfb4dc15f3bed562731ed9d525651cc
Change-Id: I334a103e02fd905faafc43c7c5b95996bc91fd18
Why:
- We want developers to have DevelopmentSettings loaded by default
What:
- Define a new `--with-developmentsettings` argument for install.php,
Set it to true in the `composer mw-install:sqlite` invocation
For now, this option is not supported in the web installer.
Bug: T347347
Change-Id: Icba2d614fd1349463fb745ef31f53a3b3834e5ad
These commented-out options have been pending for many years, and
there doesn't seem to be a plan to make them work. They can easily
be re-added if required.
Change-Id: I6aa9bfe4509062b0f204800fcee70ba767fbc517
If the parameters to installer.php aren't specified,
it uses the default values as defined in DefaultSettings.php.
In the case of scriptpath, this doesn't work out of the box,
unless the server has previously been configured
to route /wiki (the default $wgScriptPath).
This change makes installer.php use mediawiki's core directory
as scriptpath, which at least would work without any special
configurations on the server.
This is similar to what the web installer does already
(see envCheckPath() at includes/installer/WebInstaller.php#L1153),
so this change also improves consistency between the installers.
Change-Id: Ie50be570a29eca9a734beee0337d667a8b29f65a
Only MySQL/MariaDB and PostgreSQL will show this option,
as SQLite connects to a file.
Bug: T335828
Change-Id: If29429bcf32807620755dd0b8797d12a13668266
If possible, load the script file before running Setup.php. This way,
script files can control the setup process by defining constants. This
is needed by scome scripts, namely:
- instal.php, to override config loading by defining MW_CONFIG_CALLBACK
- generateConfigSchema.php, for setting MW_USE_CONFIG_SCHEMA_CLASS
- mergeMessageFileList.php, for setting MW_NO_EXTENSION_MESSAGES
- shell.php, for setting MW_NO_SESSION
Note that this will not work for scripts defined in extensions.
In order to allow script files to be loaded based on class name,
AutoLoader.php is included before Setup.php is run.
This is a modified version of I638f99c3cc6f8ab8216bd65ada959a6a11ff454b.
Co-authored-by: PleaseStand <pleasestand@live.com>
Change-Id: I2bf3b91c0a7162413cd1392252cb4f29a0d3d594
Subclasses of Maintenance that can function without database access can
now override canExecuteWithoutLocalSettings to return true.
This is useful for scripts that need to be able to run before or without
installing MediaWiki.
When no config file is present, the storage backend will be disabled.
Any attempt to access the database will result in an error.
NOTE: This makes MediaWikiServices::disableBackendServices() more
comprehensive, to avoid premature failures during service
construction. This change makes it necessary to adjust how the
installer manages service overrides.
The CLI installer is covered by CI, I tested the web installer
manually.
Change-Id: Ie84010c80f32cbdfd34aff9dde1bfde1ed531793
Add suppor for documenting multi-value positional args.
Also fixes an issue with errors about missing args being shown even when
--help is given.
Change-Id: I6e07115aaa0f557614979adcd3f0423dd37fe8bc
Maintenance scripts can now be run like this:
maintenance/run.php <class>
NOTE: This introduces a new callback into Setup.php,
MW_FINAL_SETUP_CALLBACK. In contrast to MW_SETUP_CALLBACK, it is
called after extensions have been initialized.
Bug: T99268
Change-Id: Ia221f72d6b7d23df74623d60ade7fe3e5d913074
Avoid showing the error messages twice
Make the installer responsible to show the detail error text
Bug: T253341
Change-Id: I8f146cb1affca3711c102284534783cc50b514f8
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
