Use the ExtensionRegistry instead of checking for the main class
name of the Cite extension. - I'm not entirely sure if this is much
better. A hook would still be the better option. But at least Cite
could be refactored and the class name changed.
Bug: T89151
Change-Id: I35e5aa9955141b575de68a5be2c0d5b87585eb77
It was just a wrapper to Content::getTextForSearchIndex(), simply use
this method rather than depending on (and sometimes constructing) a
SearchEngine.
Change-Id: I8541248ffdca303f0af3b959cf2f051dcb497925
was only returning two constants and forced a cyclic dep bewteen
SearchEngine and its SearchResult instance.
Simple make these values a constant in SearchHighlighter and use
them as default values for the highlight methods.
Change-Id: Ia78408d5266d0a305006027fe6265a2a1d68b0b9
The function calling this abstract function allows to return null,
so it should be okay to return null here
The null for empty result in SearchOracle
Change-Id: I66a8fb3a4190bf5506f358a47f6f4833b1715c7f
trait meant to hold methods that rarely overridden or that are
non trivial to implement.
Bug: T228626
Change-Id: I4fba27b22860109d648e830a435d4a036d26ad06
Was only called by SpecialSearch, according to IResultWrapper::free()
this method is rarely worth being called. Therefor it does not seem wise
to expose it in the upcoming interface defining a search result set.
Bug: T228626
Change-Id: I12d41a488025eb2d6dd543c9fbdc1c803c840316
This is the preferred method as it enforces read-only mode for DB_REPLICA
and handles LoadBalancer::reuseConnection() calls automatically.
Change-Id: Iab9439ba8e0810fa14c302661ed7a3534f6bfc0d
And start indicating that hooks relying on this data might become
unreliable as this data is only populated by SearchDatabase search
engines.
This information was only populated by SearchDatabase implementations
and due to bad initial design of SearchResult[Set] (now fixed) it forced
users of these classes to carry this information for the sole purpose of
highlighting.
Because SearchEngine can now own their SearchResult[Set] implementations
nothing that is engine specific should be exposed outside of these
specific implementations.
If there are some logic that still requires access to such list of terms
they should be made engine specific by guarding their code against
instanceof SqlSearchResult.
Change-Id: I38b82c5e4c35309ee447edc3ded60ca6a18b247a
Depends-On: I53fe37c65c7940f696c1e184125e01e592a976e4
Also make the update() methods of the subclasses use DB_MASTER as they
should. This avoids read-only errors.
In addition, avoid passing a dummy argument of null in some cases
within SearchEngineFactory::create(). Fix some dynamic calls to
static methods too.
Change-Id: Id94f34994b0f9c18e23ef30cb2fe895e6dedd09c
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
