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
As mention in comments of I71f77c3001a12d75b901807c20115cead9c64e93 the
added prefix suggestion can get called recursive.
Avoid this by disable prefix suggestion for media and special namespace,
because a special page cannot be used on that special pages.
Follows I71f77c3001a12d75b901807c20115cead9c64e93
Change-Id: I8978e3bd0783f62bc25b32a0fdaa90361abefcf3
The autocomplete search allows special pages to define the list of
subpages to be excepted. Fill up the function to show auto suggestion
for subpages of the following special pages:
Special:AllPages
Special:ChangeContentModel
Special:FileDuplicateSearch
Special:Movepage
Special:PageLanguage
Special:Prefixindex
Special:Recentchangeslinked
Special:Undelete
This makes it easier to navigate to this special pages with a prefilled
title/target field.
Change-Id: I71f77c3001a12d75b901807c20115cead9c64e93
* Links can now be customised on-wiki via system message:
e928d5bdd0
* Most help pages chosen here are good for any MediaWiki install
and have been imported on MediaWiki.org. Their license has been
noted in the appropriate template, only future contributions
will be in public domain (CC-0) unless we reach old authors.
An update/discussion was opened at the project talk:
https://www.mediawiki.org/wiki/Project_talk:PD_help
* The 6 pages on MediaWiki.org have been marked for translation;
import of previous translations is ongoing. 2 pages are left on Meta
because importing translatable pages with all translation units may
be overkill.
Bug: T45591
Change-Id: I5dd91a0b7233556f2da06b65205fee72ea65a55f
The implementation in ChangesListSpecialPage::doMainQuery() is
dead code. It's never executed because the relevant subclasses
override the method completely without ever calling
parent::doMainQuery().
This means that the deprecation of the hooks in the subclasses
leaves us with no alternative. Which is a real problem in
Wikibase, see I27716275e966147ee26d81d8ce3f14951937e718.
The same deprecation in ChangesListSpecialPage::getCustomFilters()
works because all suclasses I'm aware of call the parent method.
But please note that extensions may still break if they do this
different. I can not checked them all.
If you want to be sure you should just revert patch
I9cceda5d2dcfc53c852c5682c466b48ad8f31202 that introduced this
non-functional hook. I'm sorry to say that but I wonder how this
passed review.
Change-Id: I7ba3ea64cb145c06011a856e5b56399da4f42339
Old hooks (called by SpecialWatchlist, SpecialRecentChanges and
SpecialRecentChangesLinked) have been deprecated, but I'm not planning
to remove them anytime soon. (They have lots of usages in extensions
as of this writing.)
The new hooks (and their deprecated friends) are:
* ChangesListSpecialPageFilters:
* Replaces: SpecialRecentChangesFilters and SpecialWatchlistFilters
* The signature for this one is exactly the same as signatures for
the other two. We might want to pass something else than $this
here…
* ChangesListSpecialPageQuery
* Replaces: SpecialRecentChangesQuery and SpecialWatchlistQuery
* These hooks have wildly different signatures. The new one is a
superset of the old ones, in a more reasonable order, with the
addition of the name of the special page we're doing right now.
Change-Id: I9cceda5d2dcfc53c852c5682c466b48ad8f31202
I should have done it at the beginning instead of trying to
extract it from recent changes.
Same for SpecialRecentChanges and SpecialRecentChangesLinked
(subclasses).
Created a new API module for it: ApiFeedRecentChanges.
It's somewhat un-API-like and hackish, but all feed modules are.
Old URLs redirect to new ones, so this should be fully
backwards-compatible assuming sane feed reader clients.
Change-Id: I06ee0f01d896bc66545a1800b24693ce7524e433
No functional nor cleanup changes, just reordering. This should
make further refactoring (and reviewing it) easier.
In ChangesListSpecialPage placed them in "call-graph" order
instead of somewhat randomly.
In subclasses placed ChangesListSpecialPage functions first in the
same order, feed-related things later, and internal functions last.
Change-Id: I0cccfdb7c5ecd99a92d09d835211153279d71846
Callers should use SpecialPage::getPageTitle, which is
exactly identical.
This is so that in the future we can turn SpecialPage
into a ContextSource, which requires getTitle to return
getContext()->getTitle.
Change-Id: Icdcf5d5295ef5e7f08b1d403e0c123f78738fd40
The special page setup was previously handled separately for feed output
to restrict the request arguments to a small subset of possible filter
options. This behavior was removed in 52b59f0685.
This makes the main difference between the normal and the feed setup that
custom filter options were not loaded for feed output. Support for custom
filter options was introduced with fcbdd58326 but did not touch the feed
setup, preventing filters from being initialized when requesting a feed
(see bug 57201).
After adding support for custom filters to the feed setup, the only
remaining difference is a different default limit, and the support for
subpage syntax for non-feed output.
This commit merges the feed setup with the standard setup.
Furthermore, in `SpecialRecentchangeslinked`, the extra argument parsing
was made also redundant with 52b59f0685.
Bug: 57201
Change-Id: Ia8ba28efb96da9df5d7252278d46ff88a143368c
For consistency with SpecialRecentChanges.
This introduces no incompatibilities as PHP classes are case-insensitive.
Change-Id: I5855074deed52fd7492f033c8a8fced8af647602
OutputPage::wrapWikiText results in a Parser::parse call, which should
not be done recursively. Using workaround from the warning under
https://www.mediawiki.org?oldid=807703#OutputPage-.3EaddWikiText.28.29
This only was happen, when the special page has no result or for
RecentChangesLinked a bad title was given.
Bug: 56167
Change-Id: I334bc6c36800af80e311301d46c7d48be1b6a055
Use consistent message in RecentChanges, RecentChangesLinked, and
Watchlist when there are no items to be shown.
Previously RecentChanges just showed empty space and
RecentChangesLinked and Watchlist used two different messages.
Harmonized both the text and the code.
Message added: 'recentchanges-noresult'
Messages removed: 'recentchangeslinked-noresult', 'watchnochange'
Change-Id: Idf9f7a8422d9ad13dc46c69ee284b04cbbe211b7
These are needed for OAuth grants.
Note that, even if 'editmywatchlist' is not granted, various actions
will still allow for adding but not removing of pages.
Change-Id: Ie33446a228dd6ed0114730935c1bf65667f5ce01
Just call parent::getExtraOptions() first and then simply add the one
additional field. The 'SpecialRecentChangesPanel' hook wasn't called
from SpecialRecentchangeslinked previously, I've wrapped the call in
an if to keep the behavior the same.
Changes this causes:
* If $wgAllowCategorizedRecentChanges is true, Recentchangeslinked
will include the category filter form as well.
* The target filter on Recentchangeslinked will be displayed at the
end of the form, below the tag filter.
Change-Id: I4436a63356adb1e0b0daa1aa52c179974a036fa1
* Removed spaces around array index
* Removed double spaces or added spaces to begin or end of function
calls, method signature, conditions or foreachs
* Added braces to one-line ifs
* Changed multi line conditions to one line conditions
* Realigned some arrays
Change-Id: Ia04d2a99d663b07101013c2d53b3b2e872fd9cc3
* 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
RecentChanges and RecentChangesLinked should link to atom/rss feeds using the same options as specified for the pages themselves. E.g. if somebody is looking at Special:RecentChanges&hideliu=1&namespace=1 the feed(s) should link to Special:RecentChanges&feed=atom&hideliu=1&namespace=1. All options available on RC and RCL are already supported by their feeds, except the maximum number of changes in feeds is bound by $wgFeedLimit.
Change-Id: I8fb00ccd7efdd962a8a42f0bce3eac5177e2cfbd
Inside SpecialRecentChanges::getDefaultOptions() the 'tagfilter' option
is already set, so there is no need to do it a second time.
Change-Id: If89cf65a19676a4c6efa82883544b74e08961c62
This reverts bug 23293, because with tagfilter, I see no UNIQ things.
By the way, the fix for bug 23293 was not the best, because it modify
for two pages the query and for the third only the display part.
This also realign the ChangeTags::modifyDisplayQuery calls and fix the
way, SpecialNewImages gets 'ts_tags' into the select
Change-Id: I09cfa5697561970399622920214a569e9a712080
* Make OutputPage::setSubtitle(), OutputPage::addSubtitle() and OutputPage::appendSubtitle() accept a Message object in addition to a string
* Added new method OutputPage::addSubtitle() to replace appendSubtitle() and marked it as deprecated
* Clear the subtitles when showing an error page
* Always show the subtitle from Article::viewRedirect() when showing a page; left the parameter for use in EditPage
* Make Article::setOldSubtitle() add two subtitles and has to set "display:inline;" for the three possible divs to avoid too many spacing
* Removed the six different backlink subtitles and added one new message 'backlinksubtitle' to replace them and added OutputPage::addBacklinkSubtitle() to factorise common code
* Changed EditPage's view source to show "View source for <Page>" with the same backlink in subtitle for consistency with other back links and page titles
* Removed OutputPage::setPageTitleMsg() and OutputPage::setHTMLTitleMsg() and make OutputPage::setPageTitle() and OutputPage::setHTMLTitle() accept a Message object
* Updated core calls (including some that I missed last time because of non-matching case)
* Added Message::setContext() and use it in RequestContext so that I don't need to duplicate the call in OutputPage
* Yes, I'm calling $this->msg() on places and then setting the context one more time in OutputPage::setPageTitle() or OutputPage::setHTMLTitle(), but at least I won't be confused about which objects $
* Added context to ChangesList
* Added new factory for ChangesList and subclasses in ChangesList::newFromContext() and modified ChangesList::newFromUser() to call it with the main context since anyway User::getSkin() return the Skin from the main context, so this won't change anything but the User::getOption() call
* Updates Special:RecentChanges and Special:Watchlist to use that new function
* Call Linker methods statically
* Use Linker::linkKnown() instead of Linker::link() where possible
* In Special:Watchlist: Use wfMessage() instead of OutputPage::addWikiMsgArray() with the third parameter
