Because otherwise extensions can cause the installer to explode when
they can't find their own classes at entry point.
I feel dirty.
Bug: 67440
Change-Id: I235fe58125fd49319963d949faffe024684755bd
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
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I41a84e8e1dec39170aa655250325ffc485eaeaef
This "feature" of PHP has been disabled by default for quite some
time, deprecated in 5.3 and removed entirely in 5.4.
See <http://www.php.net/manual/en/security.magicquotes.php> for
information on why this practice is bad and how to disable it.
For MediaWiki, the removed todo comment says it all. Doing this
messes with all of the super globals and makes embedding MediaWiki
inside another application problematic. It also increases our
memory footprint for every single request even when the data might
not be used.
Finally, it makes it possible to instantiate new WebRequest objects
pretty much whenever you want, so there's no reason for $wgRequest
to exist anymore.
Bug: 11558
Change-Id: I4bc0392276f454ceb966547c7fbd7c8190ebbc7c
The iconv fallback is, for the most part, a remnant of PHP 4 support.
Though iconv was not enabled by default in PHP 4, it is in PHP 5. This
is the case even for Windows builds, which use GNU libiconv.
As for the major Linux distributions:
* Debian, CentOS, Ubuntu -> always enabled
* Fedora, Slackware -> .so in the same package, enabled by default
* Arch -> .so in the same package, disabled by default
* openSUSE -> separate package
Change-Id: Ie1112a5742646a0e1f951e188480c23851859320
Let the user choose the skins to install (like extensions)
and decide which one will be the default for the new wiki.
Right now core skins are always enabled regardless of user
choices there, but I'm working on that.
Bug: 66440
Change-Id: I2e10720a6ac327e66c415bb91dc897885f952738
Folds functionality from child classes back into a
concrete implementation in the parent class, reducing code duplication.
Change-Id: I697fe697dbd59d5db6fc77aba20af322e6011782
These aren't checks but preparations, they should always run
even when the user is further in the installer process or when
the server is generating the WebInstaller stylesheet (which needs
wgScriptPath to be set in order to remap image paths correctly).
Bug: 67810
Change-Id: I98eb15096ff4ef3e464b9d00c58b036a608deb41
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
register_globals has been deprecated since PHP 5.3, which was released
5 years ago. There's absolutely no reason anyone should have this turned
on, and if they do, well, they probably have bigger issues than this.
Due to changes in WebStart.php, the web installer will now fail to
start, just showing an error message stating that register_globals
must be disabled beforehand.
The command-line installer will display the
"config-register-globals-error" message before exiting.
Change-Id: If951d15293c5f6aa8a92e91fefcb00f04e6c13b3
Web installer was not checking for unsupported PHP versions.
In those cases the script should terminate or the
installation will break (e.g. syntax errors for PHP4).
Installer::doEnvironmentChecks() no longer checks for PHP
version since it has already been done by the entry scripts
(both in cli and web modes)
Installer::MINIMUM_PHP_VERSION has been removed since it is
no longer used.
Message config-env-php-toolow is no longer used and it has
been removed
Change-Id: I9227868bd2bd4e13bad6b95ad581be3ada71c94e
We're currently not hitting any code that calls wfGetCache(), but
this seems like a good thing to do and would allow us to re-use
more code instead of duplicating a large method just because it
has a call to wfGetCache() somewhere.
This is already done for DB access and LocalisationCache in
general by the installer, but via SqlBagOStuff it can still
cause an exception from LBFactoryFake.
Change-Id: I69c1e34365c1d7503aea8ef47942d20c34318e85
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
Setup.php uses the value of $wgScriptPath in $wgLogo before the
installer determines the former, so it is necessary to override
the latter even before the WebInstaller_Options page is shown
(because it might never be shown).
Bug: 48084
Change-Id: Icc577c1bb1f78adc7a7cfb0581ae8ea2facba4cf
This has been deprecated and mostly unused for quite some time.
Remove the few remaining uses that exist.
Change-Id: I522ef138d291cf7567250fef1de34bb41673bc6c
* envCheckPHP531: Message is outdated ("downgrade to 5.3.0"; the
current minimum PHP version is 5.3.2), and PHP Bug #50394 has
not reappeared in any later version.
* envCheckZE1: zend.ze1_compatibility_mode was removed in 5.3.0.
Also updated the error message for envCheckBrokenXML to remove
the "Upgrade to PHP 5.2.9 or later" wording.
Change-Id: Ifc8754151dd23a0314c6739cb78c7ac61a306bc4
RE_IPV6_ADD uses (?(-n)) ("relative reference condition"), and CSSMin uses
\K ("reset start of match"), which only work in PCRE 7.2 and later -- newer
versions than the PCRE 6.6 included with Red Hat Enterprise Linux 5 and its
derivatives (e.g. CentOS 5).
Because the WMF developers, in general, do not seem to support maintaining
compatibility with such old software versions, I have opted to add a check
to the MediaWiki installer for these versions of PCRE. Affected users are
directed to a MediaWiki.org page advising the use of a different PHP package
that uses the bundled PCRE version instead of the older system version.
For now, the minimum PCRE version is set to 7.2, the oldest version not
known to break MediaWiki core. Once PHP 5.3 support is dropped, we may be
able to require PCRE 8.12 (bundled with PHP 5.4.0) or later.
The existing check for mere existence of the PCRE functions is removed;
since PHP 5.3, it is impossible to compile PHP without PCRE support.
Bug: 58213
Change-Id: Icf3732b6f84eeb25990178ae8fe3bd0fe4cc833f
Includes the following improvements:
* Use the ResourceLoader module definitions (with a hardcoded list of
module names) instead of a hardcoded list of filenames.
* Make the errors more discoverable like we do in load.php, prepending
them instead of burying them in the middle somewhere.
Bug: 55589
Change-Id: Iab78a60209ab46a10d4c492c75527e717f36f803
One class of errors left unaddressed: Class name "WebInstaller_Language"
is not in camel caps format. I think this can be changed, too, but I
wasn't able to quickly find out where class names are being created.
Change-Id: I920b0231db1b70b68c6c8907257c288a0e112668
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
* Remove one of the two uses of Xml::encodeJsVar(): to encode an
unused JS variable dbTypes. The remaining use is only after
installation is complete.
* Add an environmental check to ensure the JSON functions are
available before attempting installation.
Bug: 54774
Change-Id: Ifb8859026b853ef3f328b796945a973c4add7eeb
* Follows-up b2e2b2e016.
* Minor clean up of surrounding documentation comments.
* Fixed missing keys for messages in WebInstallerPage
Change-Id: Iaa692064262f3c0e10cfa5e4b1ec8c86e5d02362
This can change from one web server to another. Hardcoding it
in LocalSettings is unnececary (and could even cause problems
when a MediaWiki install is moved to a server with a lower
limit than the original server, as ResourceLoader would still
be acting on the old limit).
Similar to how wgUsePathInfo is currently dynamically set.
The less cruft in LocalSettings by default the better imho.
Except for stuff that makes sense to be sticky, explicit and
cached. Or stuff that is every commonly enabled and is therefor
convinient (such as wgEnableUploads/wgUseInstantCommons).
Change-Id: I58cb185f8dc1650a76c60c7fd04767fb74b32be2
There's no need to cache _CompiledDBs's value from the first installer load.
Instead, the list should be regenerated on every page load, as it's merely being
used for displaying the user list of DBs to choose from.
This solves a common setup confusion, where user starts with no DB support, gets
a friendly error message, installs php5-mysql as requested, but refreshing the
page won't make the error go away.
Bug: 31533
Change-Id: I2e7e5b4f72e7c11706d491a205e202008e2511da
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
Venema's taint feature was apparently never publicised beyond the
php-dev mailing list, and now there is a PECL taint extension which is
incompatible with the interface assumed here.
Grep confirms that wfArrayMap() is not used in any extensions.
Change-Id: I17d8d302947443262474c608829c7c7504bef589
