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]].
This is a global search and replace of NS_IMAGE and NS_IMAGE_TALK with NS_FILE and NS_FILE_TALK respectively in all core files, excluding those already updated in step 1 (r44004).
*In SearchEngine's case, it gets caught every time further up the page (it never even reaches the upper/lower casing of only first character part)
*PrefixSearch eventually sends it through ApiQueryBase::titleToKey()
*AjaxFunctions immediately sends it to Title::newFromText()
* check in a new ajax suggestion engine (mwsuggest.js) which uses
OpenSearch to fetch results (by default via API), this should
deprecated the old ajaxsearch thingy
* extend PrefixSearchBackend hook to accept multiple namespaces for
future lucene use (default implementation however can still
process only one)
* Added to preferences, also a feature to turn it on/off for every
input (disabled atm until I work out browser issues completely)
* WMF wikis probably won't be using API to fetch results, but a
custom php wrapper that just forwards the request to appropriate
lucene daemon, added support for that
SpecialSearch:
* moved stuff out of SpecialSearch to SearchEngine, like snippet
highlighting and such
* support for additional interwiki results, e.g. title matches
from other projects shown in a separate box on the right
* todo: interwiki box doesn't have standard prev/next links to
avoid clutter and unintuitive interface
* support for related articles
Both now accept namespace prefixes, handle 'Media:' and 'Special:' pages,
and reject interwiki prefixes. PrefixSearch class centralizes this code,
and the backend part can be overridden by the PrefixSearchBackend hook.
