With a separate service for each of the NameTableStore tables, it
wasn't possible to instantiate a NameTableStore for a foreign wiki,
leading to the inelegant situation of having RevisionStoreFactory
construct a new NameTableStoreFactory every time a RevisionStore for a
foreign wiki was requested. These NameTableStore objects were not
tracked in any structured way, so there was no way to reset them for
tests.
So, introduce NameTableStoreFactory, which tracks object instances for
both local and remote table access.
This also avoids having schema details in ServiceWiring.php.
Depends-On: I5c78cfb8bf90eca935a3264592366f63517c4fad
Bug: T202641
Change-Id: Ic0f2d1d94bad9dcc047ff19a1f92db89b7e014ce
RevisionRenderer is the MCR replacement for Content::getParserOutput,
as outlined in <https://www.mediawiki.org/wiki/User:Daniel_Kinzler_(WMDE)/MCR-PageUpdater>.
Note: This change also introduces quite a bit of code for
merging ParserOutput objects.
Bug: T194048
Change-Id: I871978bf79f67c9e7954fb3fc8528d6e365f2cc1
BlobStoreFactory::newBlobStore() takes a wiki ID as a parameter, so it
needs an LBFactory to fetch the correct LoadBalancer from.
Bug: T202483
Change-Id: I834cd95251d76cb862600362525faf60d4e170b9
MediaWiki::emitBufferedStatsdData() is never called for the PerDbName factory,
so stats were being dropped. Instead of having two factories, turn the
PerDbName one into a proxy/wrapper around the main factory that just adds a
prefix in front of all of the keys.
Bug: T202144
Change-Id: I31e376446abb58e41353b4ca3814120d2e914104
Calling SpecialPageFactory methods statically is now soft-deprecated.
SpecialPageFactory::resetList() is a no-op, and I changed tests
in core to use overrideMwServices() instead.
Methods that fell back to $wgUser now require a User object being passed.
Depends-On: Ie1f80315871085b9fd4763a265b588849d94414d
Change-Id: Id8a92d57743f790b7d8c377c033cef38d1bb24de
I wasn't sure how to convert the rest of the occurrences in core (there
are a significant number).
Bug: T200881
Change-Id: I114bba946cd3ea8a293121e275588c3c4d174f94
Adding everything at the end makes the list arbitrarily ordered, and
also invites lots of merge conflicts as new things are added.
Change-Id: I58bcca4fa79140f5d5f2f6ef447e67035cc37aae
Instead of having basically every caller do:
$pf = new PasswordFactory();
$pf->init( RequestContext::getMain()->getConfig() );
Just create a single PasswordFactory via MediaWikiServices and pass that
around. Things that want to use their own config can still pass settings
via the new constructor.
This will eventually let us remove the init() function, removing the
only hard dependency upon MediaWiki, to make it easier to librarize
(T89742).
Change-Id: I0fc7520dc023b11a7fa66083eff7b88ebfe49c7b
prefix = 'MediaWiki.' will result in 'MediaWiki..dbname'
Preventing that is the only purpose of the rtrim(), we don't support
whitespace there
Change-Id: I72383aae908dbc89688cd3bebba36d389cde3f29
Static members of MagicWord have been removed.
Static methods are soft-deprecated and forward to the factory. They
will be hard-deprecated when all callers are removed from core.
MagicWord::clearCache() has been removed. Instead, call
resetServiceForTesting( 'MagicWordFactory' ) on your MediaWikiServices
object.
Change-Id: Ie061fe90f9b9eca0cbf7e8199d9ca325c464867a
Bug: T200247
This was reporting Mediawikiwikidatawiki for example as the '.'
was added inside the rtrim call
Bug: T196609
Bug: T200424
Change-Id: Ia8e51371b9a27ed14ec55bb34a52ec9e65ad55cf
This, for now, has the focus for holding metadata of each
configuration option inside of MediaWiki (both extensions and core).
It's very close to the Config interface and friends, and uses these
implementations to retrieve the actual value of the
configuration option.
The goal with this change is to implement a basic architecture to
allow to display the values of the curent configuration of the MediaWiki
installation on-wiki (e.g. on a special page). It also provides a
central point, where the currently known options can be fetched
from.
The long-term goal, of course, would be to get a web interface to really
configure the MediaWiki installation. But, this is more like a dream,
then a plan (from the point of view of this commit).
Next steps would be:
* Enable ExtensionRegistry to "register" the configuration options of
extensions, so they're available in the repo (done).
* Find a good way to get mediawiki/core configurations into this repo
* Work out an overall architecture to display the different possible
values. (I think about something like different formatters for types).
Change-Id: I9419508eaa85ffc55520db7f33b3e9530fc99f00
Enable inserts to the new MCR db schema in single slot mode only.
TODO:
- RELEASE NOTES
Notes:
- When in MIGRATION_WRITE_NEW or greater, deleting and then
restoring a page will result in different data in the revision table.
For example, if you delete a page that has text_ids present in the
revision table and restore it, the text_ids will be blank after.
- When in MIGRATION_WRITE_BOTH or greater the archive table will
start to ar_content_model entries where previously it would have been
given NULL. This is due to the old content schema having NULL in the db
when the default content model is used, but the new schema will always
have a value, taken from the content_models table
Note: If259b1e1c49ce was squashed into this change.
Bug: T183488
Bug: T174024
Change-Id: Ic2221da30c8f6ac2ba42720fcd568f2d0ed70534
Replace it all with random_bytes(), leave
only MWCryptRand::generateHex() as a convenience helper.
Change-Id: Ic30376a90e66d8f00dab86e7e6466fb3a750b87d
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Once getMain() was called in setSchemaAliases(), the ChronologyProtector
was initialized and the setRequestInfo() call in Setup.php had no effect.
Only the request values read in LBFactory::__construct() were used, which
reflect $_GET but not cookie values.
Use the $wgDBtype variable to avoid this and add an exception when that
sort of thing happens.
Further defer instantiation of ChronologyProtector so that methods like
ILBFactory::getMainLB() do not trigger construction.
Bug: T192611
Change-Id: I735d3ade5cd12a5d609f4dae19ac88fec4b18b51
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
This is to be used within the FileImporter extension to allow
adding custom loggers to this import process.
Change-Id: Ib094d4829764ccc8e5bd2619fb827d701ae06d43
This is to be used within the FileImporter extension to allow
adding custom loggers to this import process.
Change-Id: I4a6c573fc0a69b06d696cd2afca9226fb492a9bc
It was never super popular anyway, APC was always the best option.
The project has no plans to move to PHP7, so it's quickly reaching
its end of life. Oh, and Fedora dropped it from their repos 2 years
ago.
Change-Id: Ia3257e86a6323d8943f04a5c05c72c0bd4c4b0a9
