The OpenSearch and prefixsearch APIs are always on for external use.
This internal parameter and feature flag was used as emergency switch
when the feature was still new, as a way to selectively ignore queries
from our own frontend code if we decided to turn the feature off.
At the time, there was also the $wgEnableMWSuggest configuration variable.
The idea being that if the JS is undeployed, it may still be cached in the
HTML and in some browsers. The $wgEnableOpenSearchSuggest variable allowed
the MW servers to identify those requests and return empty array without
any further DB load. Thus returning an empty array, which the frontend
at the time (mwsuggest.js) treated the same way visually as if the suggestion
feature didn't exist.
Since then:
* $wgEnableMWSuggest was removed in MediaWiki 1.20. The search suggestions
in Vector and other skins are now always on.
* The "Disable search suggestions" user preference was removed
in MediaWiki 1.23 (T54812).
Proposing to remove this additional complexity.
Change-Id: Iec572012de171d02871b8dc3207d2b34d17bf9ef
This allows us to use correct names in Names.php without needing to
change the domain codes.
Bug: T174160
Change-Id: I98d2b453022f2de8a32b5d55bac91f3c317e4310
To avoid preference bloat, this preference is hidden unless the new
sysadmin config $wgSearchMatchRedirectPreference is set.
Bug: T235263
Change-Id: Ic16f53a4e6ddb6da071d63cd5da28d937d4692c8
The immediate use case is for testing, where some tests need to use the
PHP implementation even when wikidiff2 is installed.
Bug: T237049
Change-Id: I41dc4c0933429065d7638f518ec31f0a056afc41
Since MediaWiki 1.18, $wgServer has been automatically set by the web installer
when it generates LocalSettings.php, so this shouldn't be an issue for most
wikis. The CLI installer now supports a --server optional parameter to
specify $wgServer, otherwise it'll be set to 'http://localhost' by default.
Users will see a fatal error pointing them to the on-wiki $wgServer
documentation that I've updated as well.
Originally this functionality was slated for removal in 1.20, but now is
just a good time as any. It also calls into other parts of MediaWiki before
most things are initialized, making it difficult to librarize some code.
Bug: T30798
Bug: T232931
Change-Id: Ia5d616e7fafbab01655067c24c5a3a073b254f21
When used in a SiteConfiguration object, the wgEnablePartialBlocks cannot
be used with a suffix or a tag.
Change-Id: I5e8c5087bb4d279051f429a4b99ed7c46e0bc85c
This broke after e0cc49ce39, due to the field 'master'
being removed from the log context. The LegacyLogger logic
forwarding these messages to MWDebug (for the debug toolbar)
however, was dependant on.
Users of debug toolbar experienced a silent failure because the
logic in question is very tolerant of missing fields. This is
because it uses those fields to distinguish the 'sql' messages
from channel=DBQuery from other messages in the same channel.
Making that less fragile is outside the scope of this commit.
This commit:
* Restore the basic functionality by making sure MWDebug::query()
gets called again for DBQuery messages.
* Remove the code relating to the 'master' field as this no longer
exists in RDBMS. It also wasn't used anywhere (to be used,
it would need to be read by mediawiki.debug/debug.js).
* Remove unexpanded "{method}" and "{runtime}" noise in the debug
toolbar text. This was introduced by he conversion to PSR-3
logging.. These fields are already rendered separately by
the toolbar and should not be part of the "SQL" column.
To do this, we need to log the $sql bit as its own key, so
I've made this a context field as well.
* Reduce the condition logic in LegacyLogger to only looking for
'DBQuery' and 'sql'. This way, if it breaks again it will
still call the logic within and emit E_NOTICE instead, which
would help detect the issue (and still fallback to at least
showing the queries). Unlike before this commit where it took
quite some time to figure out why it wasn't working.
* The above fixes still weren't enough to get queries to show
up in the Debug toolbar for me. Turns out, this was because
my local setup (mediawiki-docker-dev) uses a master-replica
set up. The setup doesn't use any custom LBFactory config,
just plain $wgDBservers. The logic for turning these plain
settings into LBFactory (in MWLBFactory.php) does kick in,
and does run (unlike if I had custom wgLBFactoryConf).
But, the DBO_DEBUG flag didn't make it through because of
the += operator preferring any pre-existing value my setup
has, which is just `DBO_DEFAULT`.
Merging 'flags' keys seems unsafe in general, but adding
DBO_DEBUG based on $wgDebugDumpSql seems innocent and doesn't
affect other behaviour (it's a case of DWIM).
Bug: T231742
Change-Id: I122bb1a65620a7ae4e1943136c975b63524a5111
This removes Language::$dataCache without deprecation, because 1) I
don't know of a way to properly simulate it in the new paradigm, and 2)
I found no direct access to the member outside of the Language and
LanguageTest classes.
An earlier version of this patch (e4468a1d6b) had to be reverted
because of a massive slowdown on test runs. Based on some local testing,
this should fix the problem. Running all tests in languages is slowed
down by only around 20% instead of a factor of five, and memory usage is
actually reduced greatly (~350 MB -> ~200 MB). The slowdown is still not
great, but I assume it's par for the course for converting things to
services and is acceptable. If not, I can try to optimize further.
Bug: T231220
Bug: T231198
Bug: T231200
Bug: T201405
Change-Id: Ieadbd820379a006d8ad2d2e4a1e96241e172ec5a
'db' is not a valid value:
> UnexpectedValueException: Cache type "db" is not present in $wgObjectCaches. in /var/www/html/wiki1/includes/ServiceWiring.php on line 318
Instead, one of the cache types set up in $wgObjectCaches must be used.
Change-Id: Id2cdf1f42dc552d21871af73abf8e87d0585706e
The run mode is used to show a different message on the special page,
instead of the current one "Updates for this page are currently
disabled. Data here will not presently be refreshed." even the data gets
updated with a different cron job.
Bug: T78711
Change-Id: Ib63d16bfea477dec43323b39671cc068530e2f0b
This was a "wait for DB schema change" feature flag that stuck around
for far too long.
Also of note is that setting $wgMultiContentRevisionSchemaMigrationStage
above SCHEMA_COMPAT_OLD, which has been the default since MW 1.32, will
already raise an exception if this is false.
Bug: T148137
Change-Id: I9a234fc55336660e9f24cac81db88a945348a1a5
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain in the code, as on Wikimedia wikis the
revision table is too large to alter at this time. A future change will
combine that with the removal of rev_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
Move the default of 2000 to DefaultSettings.php, and promote
the installer warning to a hard value.
Recommend that the setting be disabled, or increased to 5000.
Change-Id: Ifb0aadf8b52fd2d5c2a32f55e38eaa9c2600dfb5
