Don't fail to install, because we don't explicitly need to break
32-bit support. But in this day and age it's becoming increasingly
likely to break things on a 32-bit system. So let's at least let
a system admin know that YMMV.
Change-Id: Ifb3bfa049532d82f67fe4375944af1516400513c
- mostly auto fixes
- some too long lines fixed
- ignore amp space in one case passing by reference
Change-Id: I6472f83bc3cbf4bd629d83050cc3319b19ec465c
Skins can now place *.png files in a "screenshots/" directory and the
installer will link to them. It assumes that the skin directory is in a
web accessible directory.
Bug: T70331
Co-Authored-By: Isarra <zhorishna@gmail.com>
Change-Id: I30a4374619ac2cb6afe6d8c0d9181dd6b14aae79
The mw-parser-output wrapper breaks the visual layout of the installer,
causing the radio button or checkbox to be one line above the text that
describes it.
Change-Id: I0a7ec34d80d6372927fd89b7752bc08ab0395308
The used phpcs has a bug, so the version 0.9.0 could not be enforced at the moment.
Will be fixed in next version, see T167168
Changed:
- Remove duplicate newline at end of file
- Add space between function and ( for closures
- and -> &&, or -> ||
Change-Id: I4172fb08861729bccd55aecbd07e029e2638d311
This reverts commit b67f40e5b0.
There was an issue that the web installer, when inserting initial
values into the db table site_stats, would not insert any value for
ss_active_users. That lead to some places, most notably
Special:CreateAccount, to show off -1 recent contributors.
The commit to revert solved this by setting a default value of 1 for
the ss_active_users field in the database schema. However, while the
default schema has been changed, there hasn't been any schema update
procedure implemented. Also, the default of 1 is inconsistent with
other defaults in that table.
Revert that schema change completely. Instead, make the web installer
insert 0 to the field ss_active_users (just like it does with all other
fields in that table).
Bug: T56888
Change-Id: I4298754c2238f6e5447a5df77a4ada722ba302b2
If Installer::startSession() returns false, then showError() is called
before setParserLanguage(), which causes DB access via
Title::getContentModel(). The code which was meant to handle DB access
from the parser did not do so, since the exception class which is thrown
on attempted DB access has changed.
Change-Id: I1478ec06a441851c5336bdde15734642615d45e9
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
It results in CLI installer returning status code 1, messing various
automation such as our own Vagrant.
Change-Id: I7c14596db4ddd91339b2d2af463d851123a00ae7
Undeclared variables are a very common error type that we want to catch
as often as possible. To avoid needing to refactor a variety of global
level code (mostly in old-style maintenance scripts) this ignores
undeclared variables in global scope. This is still a good improvement
over what was happening previously.
Change-Id: I50b41d571724244552074b9408abbdf6160aca59
Most of these are simply changing annotations to reflect
reality. If a function can return false to indicate failure
the @return should indicate it.
Some are fixing preg_match calls, preg match returns 1, 0 or false,
but the functions all claim to return booleans.
This is far from all the incorrect return types in mediawiki, there
are around 250 detected by phan, but have to start somewhere.
Change-Id: I1bbdfee6190747bde460f8a7084212ccafe169ef
Some people don't consider "public domain" to be a valid license
statement, so for new wikis it's better to avoid it entirely. CC-0 works
around all of those issues, so we should be encouraging that instead.
Also it's confusing to have two "public domain" options right next to
each other.
The asset needs to stay so existing wikis that picked "public domain"
don't break.
Bug: T122916
Change-Id: I3c380f79a4f27d4793b84602002f3db5c399ac32
When $wgPingback is true, MediaWiki will periodically ping
https://www.mediawiki.org/beacon with basic information about the local
MediaWiki installation. This data includes, for example, the type of system,
PHP version, and chosen database backend.
The pingback is sent via a deferred (post-send) update whenever $wgVersion
changes, using the updatelog table to ensure we don't send duplicate pingbacks.
A database lock ensures only one thread attempts to send the pingback, and a
cache key throttles attempts to no more than once per hour.
$wgPingback is false by default. The web installer has a checkbox for
controlling this option, and it is checked by default. This nudges new installs
to turn on pingbacks, but does not sneak this decision past sysops of existing
installs.
Change-Id: Ie43a6b46a07ebd9ccc1b9c3001f2ea02435d826b
The installer is far too late of a place to be checking if
a function does or doesn't exist if we require it for operation.
Functions can very easily (T137509) be called prior to ever
getting to the installer check page.
Also, an old installation could've gotten past the checks if
they ran update.php --skip-compat-checks. What a scary setting!
Instead, fail hard, fast and early along with PHP version checks.
All entry points are required to go through this.
While we're here, also remove the check for mbstring.func_overload
since we already would've failed at WebStart.php
Change-Id: Ib9727979af2a4741f3cd952d13a3bb350fad43e4
Instead of "don't edit this file, edit that file", do it settings.d
style where packagers can drop their stuff in mw-config/overrides.
I propose to backport it to 1.27 because LTS.
Bug: T135695
Change-Id: I2661ba2036b2887d31ab356751d731cc8b499f26
Just because the file exists doesn't mean that we can run.
Use is_executable(), a one-shot check for both existence and executability.
Change-Id: I705010b01cd3a17c3950eebae3066d7b007f706e
This fixes three issues with the installer:
1) Make sure LocalizationCache can find the installer's i18n files.
2) Make sure we don't try to use an SqlBagOStuff for caching before we have
a functioning database.
3) Don't try to output HTML when redirecting (this is unrelated to
MediaWikiServices, but came up during testing)
Bug: T135169
Change-Id: I7caa932024cd771d6fa226a3ac6001c3148ecc9c
(This is part of I6ec374ac9 wich was a re-submit of Ie98bf5af5
which got reverted by Ide7ab563)
This change provides a mechanism to reset global service instances
in an orderly manner. There are three use cases for this:
* the installation process
* integration tests (which most of the existing phpunit tests are)
In contrast to I6ec374ac9, this change does not cause singeltons
of legacy services to be reset. It is assumed that legacy services
use global state to access services and configuration, so any
change in confuguration would affect them immediately.
NOTE: the original I6ec374ac9 would cause session information to
get lost if the user session was creatsed before initialization
was complete. This was apparently triggered by the MobileFrontend
extension under some circumstances. Check with Addshore and Catrope.
Change-Id: Ie06782ffb96e675c0aa55dc26fb8f22037e8517d
Right now, any errors from inserting the main page are silently ignored by
the installer, causing it to report success even in case of failure. Let's
fix that.
Change-Id: I1da3aa076eefa212b5cc0f796a48f944e8c06fd2
This change provides a mechanism to reset global service instances
in an orderly manner. There are three use cases for this:
* the installation process
* forking processes
* integration tests (which must of the existing phpunit tests are)
Depends-On: I5d638ad415fc3840186a0beaa09ac02ea688539b
Change-Id: Ie98bf5af59208f186dba59a9e971c72ea0b63e69
In the age when we require PHP 5.5, pretending that mbstring emulation
is not slow and silly is silly.
Bug: T129435
Change-Id: Ic8235c9da9a926df63ec7388900c44eab454eebe
I searched for /\$(\S+) = (.+?\(.*?\);)\n.*?\$\1\[/, ignored
everything involving isset(), unset() or array assigments, then
skimmed through the remaining results and changed things where they
made sense. These changes were not automated, so please review them.
Change-Id: Ib37b4c66fc57648470f151ad412210b3629c2538
When an entry point specifies MW_NO_SESSION, actually enforce that by
having both SessionManager and PHP's session handling (session_start()
and friends) throw exceptions.
If an entry point needs the old behavior of using PHP's default session
handling (as defined in php.ini), it should define
MW_NO_SESSION_HANDLER instead of or in addition to MW_NO_SESSION.
This also makes PHPSessionHandler be installed in CLI mode, where it
wasn't installed before.
Bug: T127233
Change-Id: I2a3db06ee8e44a044096c57a819b5fd5e51c5c5c
The feature no longer exists starting in PHP 5.4.0, and MediaWiki
now only supports PHP 5.5.9 or newer.
Change-Id: I3f2d1b564c50f0a28ec1ec0abd7d1b242e26953b
SessionManager cannot work in the installer since it depends on
ObjectCache which is just an EmptyBagOStuff and so doesn't store
anything. So, introduce a custom SessionProvider which pretends to
persist sessions but actually doesn't.
Bug: T126177
Change-Id: I13d8aa1453c519df7c19ca2f1fb052c99ade043c
Set the context language early, even before the session is loaded, to
avoid attempting to call User::loadFromSession(). Also update the things
that set $wgLang to also set it in RequestContext.
Passing $wgUser through to the ParserOptions constructor isn't strictly
necessary right now, but it does at least show the intended data flow
and is more robust to future changes in the way the language is passed
through to ParserOptions.
Fixes bug T126177 independently of my other two patches.
Bug: T126177
Change-Id: I15eb9cdce7805382d96b6fc6ffb9b25855876417
This hack to prevent $wgUser being loaded was apparently not updated
when RequestContext was introduced.
Fixes T126177 independently of I13d8aa1453c
Bug: T126177
Change-Id: Iedceec3044352e433710d97d5c7c81fff1a6a3e5
Pre-PHP 5.5 the extension was called "APC", and provided opcode caching
and userland object caching. In 5.5, the opcode caching was built-in to
PHP, and the userland object caching was moved into an extension named
"APCu".
Bug: T61998
Change-Id: Id6f4a87bfdb59b2592a56aea9450611238e313ad
When installing without an explicit `--dbname` argument on the command
line, the database is installed with the default value of $wgDBname
from DefaultSettings.php (which is `my_wiki`), but then the
LocalSettings.php file is written with the line:
$wgDBname = "";
which overrides the default value and makes the wiki unable to
connect to the database created by the installer.
Adding `wgDBname` to the `$defaultVarNames` list fixes this problem.
Change-Id: I3792be9675aabe00b5497ed4203b12b89da8dc3a
Do not use "wgMainCacheType" form variable
name that contains values that cannot be
assigned to $wgMainCacheType
Bug: T116375
Change-Id: I83459c8006cc4c1bcdeaa0d78a1230687c95db46
There is no need to store session variables
(that also include user-supplied arguments)
as $wgXXX global variables.
Bug: T116375
Change-Id: I880d4299566beaf99ed1fc21c690cdda64149b0e
Just because some defined object caches are problematic in the installer, it
doesn't mean, that all others are problematic, too. Disable only the object
caches, which are known problematic ones by preserving the others.
Follow up: I1c1938b3fac395d
Bug: T113843
Change-Id: I951ef22d97b4c66d3b781a9bc4a30e7e2fca1395
It's used to e.g. cache less files in ResourceLoader, which would throw
an exception if the installer is used (while it requests the installer
styles), if the object cache isn't defined.
Follow up: I1ff61153ddb9
Bug: T113843
Change-Id: I1c1938b3fac395dda5b42dd68b675a67bdd30261
