These global functions were deprecated in 1.34 and services made
available to replace them. See services below;
* wfFindFile() - MediaWikiServices::getInstance()->getRepoGroup()->findFile()
* wfLocalFind() - MediaWikiServices::getInstance()->getRepoGroup()->getLocalRepo()->newFile()
NOTES:
* wfFindFile() and wfLocalFind() usages in tests have been ignored
in this change per @Timo's comments about state of objects.
* includes/upload/UploadBase.php also maintained for now as it causes
some failures I don't fully understand, will investigate and handle
it in a follow up patch.
* Also, includes/MovePage.php
Change-Id: I9437494de003f40fbe591321da7b42d16bb732d6
Seems this was a typo and I think 1.32 which is a double/float will be
implicitly converted to true (bool) because it will resolve 1.32 to 1 as
integer and then 1 which maps to true (bool).
To avoid this, use '1.32' instead of the integer form of the version.
Change-Id: Ifaf6ab0d36bc02bd1707f8caf375f65a30eb1af5
Seems this was a typo and I think 1.32 which is a double/float will be
implicitly converted to true (bool) because it will resolve 1.32 to 1 as
integer and then 1 which maps to true (bool).
To avoid this, use '1.32' instead of the integer form of the version.
Change-Id: I2420396e110284f582cd79820ffc6064e247b4b9
I've checked around with code search tool and realized that SMW has
its own implementation of `transformSearchTerm()` which overwrites the
implementation of this method from core as it extends SearchEngine.
So removing this won't break SMW, see usage below;
Usage
=====
https://codesearch.wmflabs.org/search/?q=%5CbtransformSearchTerm%5Cb&i=nope&files=&repos=
Bug: T220656
Change-Id: I3dbe04ecba07700167c894673e23c1eead95460f
Field rev_text_id is being retired as part of MCR Schema Migration.
Remove references to this field from the Postgres search queries.
Bug: T198341
Change-Id: Id3cbf853aacc06709f441a93248b55943097cd11
The most notable improvements I was able to fit into this patch can be
seen in the User class, as well as in AbstractRestriction.
Our documentation generator ignores the @const tag. It's not needed. Just
have a comment above a constant and it will show up in the generated
documentation.
Using @var is misleading because a constant is not a "variable". The type
of a constant is strictly derived from it's value. Documenting the type
typically does not provide useful information. Doxygen does not understand
the type, but ignores any @… tag and renders everything else as plain text.
I can split this patch if you prefer. Please tell me.
Change-Id: I8019ae45c049822cdc1768d895ea3e3216c6db5f
This was originally a global search and replace. I manually checked all
replacements and reverted them if (due to the lack of type hints) either
null (that would be 0 when counted) or a Countable object can end in the
variable or property in question.
Now this patch only touches places where I'm sure nothing can break.
For the sanity of the honorable reviewers this patch is exclusively touching
negated counts. You should not find a single `!== []` in this patch, that
would be a mistake.
Change-Id: I5eafd4d8fccdb53a668be8e6f25a566f9c3a0a95
Non-breaking change. Remaining uses are public interfaces (a constant, two
globals, a config sub-parameter, SQL queries, storage function names), one i18n
message key, and a whole lot of maintenance scripts with calls to the deprecated
function wfWaitForSlaves().
Change-Id: I6ee5ca92ccf6a80c08f53d9efe38ebb4b05064d7
When submiting using the 'go' feature of Special:Search (standard
usecase for autocomplete) a nearby title can be selected.
Unfortunately a fragment only title is considered valid, which
sends the user to Main_Page#searchterm.
Instead don't allow a search starting with # to trigger the go
feature.
Bug: T182452
Change-Id: I8ce3ce8633e23db41ae6eafb9996ca7294f8445a
In some functions MediaWikiServices::getInstance() was called twices or
in loops. Extract the variable to reduce calls.
Change-Id: I2705db11d7a9ea73efb9b5a5c40747ab0b3ea36f
Search engines support the sort parameter, it would be nice if we
could pass it to be rendered in the web ui. This avoids implementing
any ui, which can be done at a later time.
Bug: T195071
Change-Id: Id7bd35bd4259bb1f1f856933d279dbd6eddfa2e2
For ease of understanding, use the same technique for both
sides of the comparison. Follows-up c2a308075f.
Change-Id: I66475fd4baaa6ab7cd24ad884e9fe01a1cd30d9f
This should be handled internally by SearchEngine implementations.
Bug: T198860
Change-Id: Ifbfd0fcb81fcacf5228bd2ffcac7b80fca872b2a
Depends-On: I7d4ff9498fa1f4ea66835c634b8931f4c29993fb
These methods are very similar there should be no need to have
two differents way to extract the namespace prefix.
Bug: T198860
Change-Id: I22802278452559d35a3d8f6068549c1fef1a5e86
This method was introduced in 4115586000
to support the prefix URI param introduced by the InputBox extension.
There are no reasons that this logic is exposed to SearchEngine users
and should be handled internally by SearchEngine implementations
that supports it.
Previously the search query was updated, now the prefix param will passed
along using SpecialSearch::$extraParams.
Bug: T198318
Change-Id: I33518d3f3ddee741ff4f3b47eb4928009bea66d1
Depends-On: I67c7f1886dd6a2d07c12015e2711c138e9f140e9
The Language::truncate() function was split into
Language::truncateForVisual() (which measures characters) and
Language::truncateForDatabase() (which measures bytes) in 1.31, but
the patch which soft-deprecated Language::truncate() didn't actually
remove all the uses in the codebase. Replace most of those old uses
now, which should actually improve the situation for
non-latin-alphabet users who were getting unfairly squeezed in a
number of places.
Bug: T197492
Change-Id: I2291c69d9df17c1a9e4ab1b7d4cbc73bc51d3ebb
