(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
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
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
Since Id364306d883e0d494b948854e05f3f79ba7dd6d2 the text boxes on the
gui installer were not preloaded with the default values from
DefaultSettings.php.
Changed this by return all needed globals (defined by getGlobalNames)
from DatabaseInstaller::getGlobalDefaults(). This injects the as default
value in function getVar and than gets used, when no value is set.
Bug: T71281
Change-Id: I8217b25e903e40ec82be3d700381ff7aea3b481f
Was added in r69542 for interwiki-transclusion, but not populated.
Also make link for 'mw' consistent with 'mediawikiwiki' by using HTTPS.
Bug: 46992
Change-Id: Ieb6c4121ae4cd4e1aefbc372bbe82bdb0ce53b5d
The American Chemical Society suggested a new major MIME type for files
containing chemical data in 1998: http://dx.doi.org/10.1021/ci9803233
This suggestion got widely adopted and is now a de-facto-standard despite
not registered with IANA.
Applying this patch will allow us to continue with extension MolHandler
and PDBHandler.
http://fab.wmflabs.org/T352
- Fixes bug 66412 by creating a logic that will prevent running unneeded
updates.
Bug: 66412
Change-Id: Ic45dc1bce796a0406ed8a84e6274df1c4bda4967
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
While installing MediaWiki with a sqlite backend and missing the sqlite
extension, I have received the very helpful message:
DatabaseInstaller::setupSchemaVars: unexpected DB connection error
Which to me is as helpful as:
error
Since the database connection returns a Status object and that it got a
message attached, we might as well pass the error message when raising
the exception. We would end up with an error like:
DB connection error: could not find driver.
Check the data directory and database name below and try again.
That let me instantly facepalm and install the sqlite PHP extension
instead of wasting time figuring out what is happening.
Change-Id: Ife8e97242e1cfbdfbb572ad50cf8e4a7ad5b9dfc
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
wfDl() is a wrapper around dl(), which is an evil function and
basically only works from the command line of Zend. Luckily
no extension has ever used this thing, so let's just remove it
outright.
For comparison, here's a list of places it does not work:
- hhvm
- php as apache module
- php compiled with zts support
- safe_mode
- Basically any shared host that cares about security
Most callers are using it to check for extension support and are
actually failing gracefully when wfDl() returns false. In these
places we're just going to use extension_loaded().
While we're at it, clean up some of the test skip logic in the
media tests so we can bail as early as possible if we know we
can't complete the test.
This also immediately removes $wgLoadFileinfoExtension. It's been
enabled by default since 5.3 and falls back gracefully when the
support isn't available.
Change-Id: Ieb430dfc74483731dde51d6e20fa700d641ba1f4
* Follows-up b2e2b2e016.
* Minor clean up of surrounding documentation comments.
* Fixed missing keys for messages in WebInstallerPage
Change-Id: Iaa692064262f3c0e10cfa5e4b1ec8c86e5d02362
* Removed spaces around array index
* Removed double spaces or added spaces to begin or end of function
calls, method signature, conditions or foreachs
* Added braces to one-line ifs
* Changed multi line conditions to one line conditions
* Realigned some arrays
Change-Id: Ia04d2a99d663b07101013c2d53b3b2e872fd9cc3
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
It makes a whole lot more sense to run this at the end of the
update process after post update maintenance rather than just
at the end of schema updates.
Run update.php more than once so all the updatelog entries
are populated and you'll see why it makes sense.
Change-Id: Ice42a31dee1e6b41da4aa0a47e8786579382aff1
Doing this in steps of roughly 100 changes per commit, so that it remains
reviewable. This should be the one but last change set with the "easy"
ones for core.
Change-Id: If894a92dd65b2f5f4f096b9133685eb3b067a1d8
Follow-up to r15791.
You can lie to me, but not to your installer.
Make DatabasePostgres::tableExists to check for real table names, not
faked ones.
DatabasePostgres is currently lying to the rest of the MediaWiki that
"mwuser" table is actually called "user" and that "pagecontents" is
called "text". While MediaWiki does not care, the installer (and updater
do).
This allows us to overcome first hurdle in getting MediaWiki 1.7.3 to
update to trunk on PostgreSQL and uncover further bugs.
For this commit to actually do something, we rename those tables when
upgrading to match what we have in maintenance/postgres/tables.sql
And by the way, tell installer not to check for "user" table, since most
PostgreSQL users will have "mwuser" instead. Picking "archive" instead.
Patchset2: wrapped commit message at 72 chars
Change-Id: Ic874e92bb1adda3430d3292423d4f3617c25456c
You can lie to me, but not to your installer.
Make DatabasePostgres::tableExists to check
for real table names, not faked ones.
DatabasePostgres is currently lying to the rest
of the MediaWiki that "mwuser" table is actually
called "user" and that "pagecontents" is called
"text". While MediaWiki does not care, the
installer (and updater do).
This allows us to overcome first hurdle
in getting MediaWiki 1.7.3 to update to trunk
on PostgreSQL and uncover further bugs.
For this commit to actually do something,
we rename those tables when upgrading to match
what we have in maintenance/postgres/tables.sql
And by the way, tell installer not to check
for "user" table, since most PostgreSQL users
will have "mwuser" instead. Picking "archive"
instead.
* Made PG throw a DBQueryError when it gets a query error, instead of DBUnexpectedError. Apparently this mistake goes back to r14625, when exceptions were first introduced. Did it by removing reportQueryError(), the DatabaseBase version works fine.
* Fixed several places where there was an attempt to check for a query error by checking if the result of query() was false. This never worked. Used try/catch instead.
* Made the DBConnectionError messages go on one line so that they don't mess up the formatting in the installer.
* In DatabasePostgres::selectDB(), only disconnect and reconnect if the DB name is actually changing.
* Made DatabasePostgres::schemaExists() less weird and scary.
* Added DatabasePostgres::roleExists() for use by the installer.
* Removed the PostgreSQL-specific hack to make _InstallUser have a default other than "root". Made _InstallUser into a proper DBMS-specific internal variable instead, since every DBMS we support so far needs a different default.
* Removed the $dbName parameters from openConnection/getConnection, and got rid of $this->useAdmin. Implemented a more sophisticated caching scheme instead. Partial revert of r89389 and r81440.
* When connecting as the install user before DB creation, and when testing the web user's credentials, try a few different database names and use whichever one works.
* Instead of connecting as the web user to create tables, I used SET ROLE. It seems cleaner and more like what the other DBMSes do during installation. "SET ROLE wikiuser" requires the same privileges as "CREATE SCHEMA ... AUTHORIZATION wikiuser", so it's unlikely to break anything.
* In the area of web account creation, fixed various minor logic errors and introduced more informative error messages at the submit stage, pre-install. Show a helpful error message if the web user exists already and the install user can't do the relevant SET ROLE.
* Split schema creation out to a separate install step.
* When creating an account as a non-superuser, add the administrative account to the new account's group. This is necessary to avoid a fatal error during installation (bug 28845).
* Removed code which alters an existing web user to have appropriate search paths and permissions. This may break other apps and is not necessary. As in other DBMSes, If the web user exists, it is the responsibility of the sysadmin to ensure that it has appropriate permissions.
* Rewrote setupPLpgSQL() to use the query builder functions.
The sections whose visibility was being controlled by the checkbox had an initial visibility hardcoded in the page output, which had been manually set to match the expected initial default state. I've switched these to instead check what the variable is set to and base the initial style visibility on that.
Could be better to encapsulate these settings together in some way, but this'll do for now.
Note that the way these are all done now means that the sections can never be used when JS is off; if a fully-functional installer is desired in a JS-free environment, it may be necessary to change these further to default to shown, and do the initial hiding in JavaScript (could have 'flashing' issues though: the bits showing up, then quickly hiding. laaame but oh well)
