Gently discourage building HTML by raw string concatenation.
Fixes for Special{Contributions/Recentchanges*/Undelete/Upload}.
Change-Id: I4a128e902dcce93372b2f188a1f37223c58ebe9a
* always hide the big red .errorbox when rcfilters
is enabled
* always identify the changes-list section with
.mw-changeslist or .mw-changeslist-empty
* conditionally add .mw-changeslist-empty-<reason>
to the changeslist section when the reason for it
being empty is known
* handle RCL being empty because the specified title
is invalid or inter-wiki
Bug: T184952
Change-Id: I5dd974f5f769503e89301dd22bdfd3d49b0dd11f
When the 'title' hidden field contains the subpage, the 'target'
input field is never taken into account since the subpage always
takes precedence in ChangesListSpecialPage->setup()
I75cfb2b56a4da6357e6117b3f34f3178bfb2c90c introduced
SpecialRecentChangesLinked->getPageTitle which overrides
SpecialPage->getPageTitle to include the subpage by default.
This helped with redirecting to the right page when parsing
a saved query on the server but changed the behavior everywhere
that function was used in the context of RCL. That includes
SpecialRecentChanges.php:545 where the option form is built.
Bug: T183437
Change-Id: Id39d1887719ecb6900b25fefbb133dff9c4d0456
Follow-up to I96af7ba583d03e6ff9833ac3b5f4b80cfd0ee626
* Reword 'Recentchangeslinked-summary'
* Bold ToOrFrom selector label
* Bold 'FROM' in 'rcfilters-filter-showlinkedfrom-option-label'
* Bold 'TO' in 'rcfilters-filter-showlinkedto-option-label'
* Reword target page selector placeholder
* Prevent title suggestions from showing duplicate entries
* Show a specific message when there is no results
because no target page is specified.
Bug: T172161
Change-Id: I1b1ee793b3eff4183039acc27fe6cca042ee57d0
Make sure that when we redirect a URL when there's a saved query,
we retain the information about a subpage.
Then, normalize the URL to always use &target=xxx so that the
system knows to correct the value if the user uses the form that
is, for the moment, outside the regular RCFilters interface.
Bug: T181100
Change-Id: I75cfb2b56a4da6357e6117b3f34f3178bfb2c90c
This will help us consolidate the various uses into one single
method which will help us drive standardisation of these defacto
widgets.
Hopefully, by being a method of the Html class, which has a very
low barrier for use will drive down the inconsistent display of
warning/error boxes across MediaWiki's products
Various usages of warningbox and errorbox have been ported over.
I've retained some more complicated usages which make use of the
parser (wrapWikiMsg) and any where id and class are medled with
- we'll probably want to consider whether we want to encourage
those going forward as they encourage adjusting the styling.
Bug: T166915
Change-Id: I2757e1f4ff2599e93a7257fc644cab69063896d2
Several classes have a "selectFields()" static method to tell callers
which fields to select from the database. With the recent comment table
change and the upcoming actor table change, this pattern has become too
simplistic as a SELECT will need to join several tables to be able to
retrieve all the needed fields.
Thus, we deprecate the selectFields() methods in favor of getQueryInfo()
methods that return tables and join conditions in addition to the
fields.
Change-Id: Idcfd15568489d9f03a7ba4460e96610d33bc4089
As we do on SpecialRecentchanges and SpecialWatchlist already,
because the last revision filter needs it.
Bug: T176228
Change-Id: I65f0f971df24853999ca445f968dd49fb0640066
When filtering for multiple tags, add DISTINCT to the query.
To make this not result in terrible query performance, we also
have to add the rc_id to the end of the ORDER BY, and add
a GROUP BY equal to the ORDER BY.
Make ChangeTags::modifyDisplayQuery() take an array of tags
instead of a pipe-separated string. This allows each caller
to explicitly opt into supporting multi-tag filters and the
conditional GROUP BY mess that that entails.
Only support multi-tag filters in SpecialRecentChanges and
SpecialRecentchangesLinked. This means we don't have to adapt
the queries in HistoryAction, ContribsPager, LogPager and
NewPagesPager to deal with a possible DISTINCT modifier.
Example query with no tag filters:
SELECT rc_id, ... FROM recentchanges ... ORDER BY rc_timestamp DESC
Example query with one tag filter:
SELECT rc_id, ... FROM recentchanges JOIN change_tag ON ...
WHERE ... AND ct_tag='foo' ORDER BY rc_timestamp DESC
Example query with two tag filters:
SELECT DISTINCT rc_id, ... FROM recentchanges JOIN change_tag ON ...
WHERE ... AND ct_tag IN ('foo', 'bar') GROUP BY rc_timestamp, rc_id
ORDER BY rc_timestamp DESC, rc_id DESC
Bug: T168501
Change-Id: I54a270a563d99b143b55ce83c7d6f70ac4861c64
Generate old RC, Related changes (it was already displayed and working
on 'Related changes' before this change), and Watchlist/etc. and data
for new UI from back-end.
This moves everything used for defining the old (unstructured) and new
(structured) filters into unified objects, ChangesListFilter and
ChangesListFilterGroup (and sub-classes).
This includes the query logic (see below) and logic for adding
CSS attribution classes.
This is a breaking change (for subclasses of ChangesListSpecialpage)
due to the signature (and name) change of buildMainQueryConds and
doMainQuery. An alternative that I don't think is a breaking change
would be to put the filter->DB logic in runMainQueryHook, but then it's
doing more than just running a hook.
This is because it used to only build $conds here, but it's clear from
filterOnUserExperienceLevel filters need more than this. I added all
the DB parameters from the hook, but this could be debated.
I have an checked and fixed the WMF-deployed extensions affected by
this.
Other than that, there should be full back-compat (including legacy
filters not using the new system).
* add hidepatrolled/hideunpatrolled to new UI.
* Move userExpLevel from RC to ChangesListSpecialPage. Although for
now the structured UI only displays on RC anyway, when it displays on
watchlist, it seems we'll want userExpLevel there.
Change this to make 'all' exclude unregistered users.
* Don't have front-end convert none-selected to 'all' on string_options.
* Needs the hideanons/hideliu special redirect to be done before this
is merged (T151873)
Bug: T152754
Bug: T152797
Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
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
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
