It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
When scrolling results on prefix search api the exact Title
match is always at pos 0 even if we want to scroll the results
by setting offset to > 0.
Change-Id: Ib02c9d3e479d739e6fe79014d962db50b6fd9de8
I thought there was just an issue with capitalization, but in fact the
code explicitly only searched one namespace anyway. Fixed that while
taking capitalization differences in namespaces into account.
This by extend also brings support for multiple namespaces to the
opensearch API.
Follows-up I3487bb69.
Bug: T67752
Bug: T32323
Change-Id: I4bec7b5548fc27ac51a1b4d4961c3bbc31eb7337
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
By default it still uses PrefixSearch and supports PrefixSearchBackend
but it can be deprecated and phased out and SearchEngine extensions used
instead.
New APIs:
- SearchEngine
public function defaultPrefixSearch( $search );
public function completionSearch( $search );
public function completionSearchWithVariants( $search );
Search engines should override:
protected function completionSearchBackend( $search );
Bug: T121430
Change-Id: Ie78649591dff94d21b72fad8e4e5eab010a461df
* Linker: Follows-up 9ce5ca9886. null is already handled.
* PrefixSearch: Follows-up 337b1e2e. null is already handled.
If other types are bassed, we want to find these.
* UploadBase: Follows-up 11f5ebec28. null is already handled.
WebRequest::getVal($name) can only return string or null.
Change-Id: I3dc3b700cde735f5cd9d497f0867a2b4e3b61f46
WikiPage::getRedirectTarget() can very easily return null. Don't
blow up when that happens.
Properly document PrefixSearch::getRedirectTarget() while we're
here.
Bug: T116029
Change-Id: Ib509e8e3e6ec04a787de3857a4b5ee9b01560559
We already handle the invalid title gracefully here anyway, so
just rely on that behavior and just skip the Title construction
bit :)
Bug: T109975
Change-Id: I0dc3d91b6b4cfb97664aa6ca39c5c8f086d70db5
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
- Added/removed spaces around parenthesis
- Added newline in empty blocks
- Added space after switch/foreach/function
- Use tabs at begin of line
- Add newline at end of file
Change-Id: I244cdb2c333489e1020931bf4ac5266a87439f0d
Prefix search attempts to find exact matches to the user's query that aren't
returned by plugins. In some cases, like when the exact match is a redirect
and the target of the redirect is also in the search results, it would result
in multiple results in prefix search going the same place. This looks really
silly when the top hit is "Barack obama" (a redirect) and the next one is
"Barack Obama" (the target of the redirect).
This handles a bunch of cases to do with redirects in the matches and when
the exact match is a redirect.
Bug: 736731
Change-Id: I49fe1ccec84bd5d1f44c6b91b260abf50f2cc3a1
This will allow extensions (namely CirrusSearch) to match namespaces using
their own rules if core can't find the namespace on its own.
Bug: 62322
Change-Id: I17337cd8ce90190bd335c9159e9d3bbb39ba89cd
In prefix search if the search text is actually a title we make sure it is at
the top of the results. But if it isn't a valid title we shouldn't blow up
because blowing up is bad.
Bug: 72260
Change-Id: I5bd795df447a33bb003a38ec2068dc184379a813
The default search backend implements proper prefix search and
does this naturally. But extensions providing search backends
like Lucene and CirrusSearch actually fail to implement proper
prefix searching and instead use their search engine ranking for
prefix search as well. Thus often the exact match is not on top
or is not even in the first 10 results at all.
On en.wikipedia.org:
> Example
1. "Example (musician)"
2. "Example"
3. "Example.com"
> John ive
1. "John Ives"
2. "John Ivey"
3. "John Ive"
> Foo
1. "Football (soccer)"
2. "Football League Cup"
3. "Foot (length)"
"Foo" exists but is NOT among the returned results.
Bug: 70958
Change-Id: I78d419424baf43d38beeb6dabfc347f430fa45f6
- Added newline at end of file
- Removed double spaces/newlines
- Added space after if/function and parentheses/brackets
- Removed space before comma/cast
- Fixed indent of some lines
Change-Id: I29867ffdffdfb7d2b56997e9393497c7dc12f7d3
This enables factory functions to be registered for special
pages, as an alterative to giving a class name. This follows the
same rationale as Ieb85493a7765, which introduced factory functions
for API modules.
Change-Id: Ia2107dc5af7869187ba5dc02a1bef46d6801e138
Caused regression in opensearch results for the main search field on every
page. Special pages are no longer included when they should.
This reverts commit 0e054bbf1a.
Change-Id: Ib39c6d7816cd3c21ec714f5d6272bebd049ac430
I thought there was just an issue with capitalization, but in fact the code
explicitly only searched one namespace anyway. Fixed that while taking
capitalization differences in namespaces into account.
Bug: 65752
Bug: 30323
Change-Id: I3487bb69eae1867832e0ec9ece497538eca32a2a
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.
Also added some missing @param.
Change-Id: I0056b4a8df243cfc0c5f25378de48f7a35170aca
Reusing variables means you end up turning a string to an object
and then confuse yourself by trying to pass it as a string again.
Change-Id: I82b5ca65864099c180d915055c43e6839bd4f4a2
It was added in 4492854f (r68563), where the code this was suppressing
warnings for was something rather different. It doesn't seem necessary now.
Change-Id: Ia501afd1244b94563fe52294945798963f8db1a9
It's pretty much like action=opensearch but can be used as a generator
which can be handy when you need to retrieve both the list of pages and
some information about them.
Change-Id: Iaffe30a0f7402e1316c4885a805692a34bbe1a6a
* Ran spell-checker over code comments in /includes/
* A few spellchecking fixes for wfDebug() calls
Found one very strange (NOOP?) line in Linker.php - see "TODO: BUG?"
Change-Id: Ibb86b51073b980eda9ecce2cf0b8dd33f058adbf
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Also make a few changes to the functions available. SpecialPageFactory::resolveAlias() now takes an optional subpage and returns array(<name>,<subpage>). Similarly merge getPage() and getPageByAlias(). There were many examples of (extensions particularly) making dubious assumptions about the presence or absence of subpages or canonical-ness.
I didn't deprecate SpecialPage::getTitleFor() as it's got over six hundred calls. I'm rather undecided on the best position of getPage()/executePath(). Although the latter needs cleanup anyway.
Patch by Umherirrender on https://bugzilla.wikimedia.org/show_bug.cgi?id=25675 - normalizes spaces to underscores for our direct alias list comparison.
The current English names mostly use CamelCase, but this is visible with eg German localization, where ExpandTemplates extension has [[Spezial:Vorlagen expandieren]].
