We probably want to put errors on top in the web installer
and warnings on top in the CLI installer due to differences
in scrolling.
This reverts commit 1c1e321af7.
Change-Id: I247030f0a3da6dff44884f4a282e52e92657fd91
Folds functionality from child classes back into a
concrete implementation in the parent class, reducing code duplication.
Change-Id: I697fe697dbd59d5db6fc77aba20af322e6011782
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I3595e9aac69ac42fbb74b0783fae0ad9bcc831aa
Currently, if we do not pass a wgServer value (via --server),
the CLI installer sets the value to the default value
specified in DefaultSettings.php - which is to 'guess' by
calling into WebRequest::detectServer. This yields terrible
results, since WebRequest::detectServer expects to be working
in the context of a Web Request - and hence with HTTP Host
header information. Since calling from the CLI does not give
it host header information, it falls back to 'localhost',
which is not the value you usually want.
If we just do not set wgServer when it is not specified,
it is automatically calculated on every request by
WebRequest::detectServer, which does a splendid job.
Bug: 55376
Change-Id: I5436dd8c340604cbb59406a507188e11c8f86e86
* Follows-up b2e2b2e016.
* Minor clean up of surrounding documentation comments.
* Fixed missing keys for messages in WebInstallerPage
Change-Id: Iaa692064262f3c0e10cfa5e4b1ec8c86e5d02362
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
The CliInstaller used the '0' exit code whenever the status was not OK.
That makes third party script assuming the install actually ran fine
since a 0 exit code is mostly considered as a success. By sending an
error code > 0 (here 1), our automatic installers will be able to catch
the failure and stop proceeding.
I had that issue with a Jenkins job which ran the CLI installer and kept
continuing although there was an error about LocalSettings.php already
existing.
Change-Id: I4f4727df85c09c0a04e4630df91c6213dfce6e9a
...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
* Add --upgrade option to CLI installer so we can throw an error when LocalSettings.php is present and provide an upgrade route to the user.
* Fixup CLI's showStatusMessage so allow CLI to throw an error and quit
