The non-strict conditions in if/while are true/false without the check.
In some situation the true/false is removed, because it is known to be a
bool (by is_bool check or type hint)
Change-Id: I5ca4c4771af25d2e785e82732df204a73653886e
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
Passing around strings that are expected to be safe html and are
known to be based on user input is a fairly unsafe operation. Make
it harder to do the wrong thing by requiring HtmlArmor to be returned
from the ResultSet snippets. This does not address the snippets on
individual result objects as the api surface is larger and requires
more bc handling.
Change-Id: I76231d6fc53c4982eb4cd174d2e6a75eb2740497
The use case is code that uses search internally, but wants to allow
a development setup where search is proxied via some public API and
the actual querying is performed on a production server, instead of
having to set up all the search services + staging content locally.
Also fix a small logic error in SearchResultSet::shrink.
Change-Id: I83931c1a19c1cb747380e17a4aff3b1fadd5fcf3
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
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
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
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
For ease of understanding, use the same technique for both
sides of the comparison. Follows-up c2a308075f.
Change-Id: I66475fd4baaa6ab7cd24ad884e9fe01a1cd30d9f
Various code using the search engine shouldn't need to implement it's
own methods, such as over-fetching, to determine if there are more
results available. This should be knowledge internal to search that is
exposed by a boolean.
Change-Id: Ica094428700637dfdedb723b03f6aeadfe12b9f4
The funky iteration here was at best annoying. Switch
it over to an iterator based approach with appropriate
BC code to simulate the old iteration style.
Depends-On: I19a8d6621a130811871dec9335038797627d9448
Change-Id: I9fccda15dd58a0dc35771d3b5cd7a6e8b02514a0
The plan is to convert these methods into final, considering
it a removal under the deprecation policy. By making entry
points into the search engine final we provide a guaranteed
point where generic handling can be applied to all search engines.
The first use case for this generic handling is pushing pagination
via overfetch into the SearchEngine class instead of re-implementing
an overfetch in individual parts of the code that perform searches.
Change-Id: I3426d6a2f32d8b368b044b154e1cb70dac007c62
Work to support interleaved AB testing of search will display
interleaved results of two search configurations on the first page of
results, but standard results on all pages other than the first page.
This means that while 20 results may be requested, the next 'new' result
of the primary query may be at position 10. Allow the SearchResultSet
to declare what the new offset is.
Bug: T150032
Change-Id: I14c0c33249fcdb66f72f5966e2aa72781a34daee
This function was incorrectly annotated. We can clearly see from the
code that uses it, such as in SpecialSearch, that this is an array of
SearchResultSet objects.
Bug: T132625
Change-Id: I4af07d3c9a9b08fd1fa438ddb6b781f78472b26c
This is implemented in CirrusSearch so the result set can be looped
through multiple times. In general having a rewind function on any
iterator is probably a good idea, so pushing it into the upstream
interface.
Change-Id: Iaac9c11d8742288610011a2a0f6282944d35d5f3
Uses fully translated string like search-interwiki-results-abwiki
which should be present in WikimediaMessages.
Requires Ic4bdd9462f844febea2e402e4b89d9dcc4c836b6
Supports I0d0efacf3066b3b5fe0bfcb058dd0b0f9988ccae
Bug: T112349
Change-Id: Ib6524bc79e1648ccf6adc5745f0dbc4c26dcb0d2
Special:Search recently gained query rewriting behavior when the
original query returned no results. We want to expose this query
rewriting behavior to both api and web requests. Additionally we
want to be able to test different configurations of the query
suggestions. This patch allows for both by moving the rewriting
from core into the search backend.
This defaults to enabled for Special:Search, and disabled for
ApiQuerySearch. Internal code that talks to the search backend
needs to specifically enable this feature.
Bug: T106888
Change-Id: I0a8f75759f9148f53358707369b8a7128215de86
The SearchResultSet is returned where no query is performed because it
is known ahead of time that no result exists. In cases where that is
known due to the syntax of the query (e.g. the syntax requires
searching a category that does not exist) this searchContainedSyntax
method returns the wrong value. This patch makes it possible for the
instantiating code to properly set the return value of this method.
Change-Id: I7b7be24f5630a48d2a561e4fda9cec696a8cacf9
- Remove old pre-1.17 constructor format. No core or extension callers
- Remove only usage of newFromRow(), needless abstraction
Change-Id: Ifad161aa36837bb4c8b5c9aecac1c46e2e6cc84c
If $wgCountTotalSearchHits was set to true, then the total
number of hits returned was zero, which caused Special:Search
to display no results.
I'm opting to remove the feature (although I don't have any
strong opinions about removal vs changing Special:Search), since
if someone both cares about performance and has a wiki where its
big enough to matter, they are going to need to use Cirrus anyways.
Change-Id: I1c3b908ae5423ce3dfbdc22b1a68dd81a85698aa
SolrStore, MWSearch and CirrusSearch all implement this and are
now free to drop their implementations.
Change-Id: Ia04bd3fc8526c35c3c9590c7fe4e2db2bc120283
SqlSearchResultSet basically handles all of the work in a DB-agnostic
manner. Remove specific implementations for MySQL, Mssql and Sqlite
Change-Id: Iae3fd5cc40dfbc50917be73d7ace668681e4148a
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.
Change-Id: Ifbb1da2a6278b0bde2a6f6ce2e7bd383ee3fb28a
Embedding random strings in Special:Search's comments doesn't
help debugging and just increases page size.
Bug: 62768
Change-Id: I51270aa3f2cba921841e2d8ebbd4fa665542f8a9
