Directly use the UTF-8 encoding of the 'NO-BREAK SPACE' (U+00A0) instead of
the HTML/XML entities   or   or .
With the UTF-8 character the generated HTML is shorter and better to read.
Also change the special value for the label in HTMLForm from   to
U+00A0 but also support   for backward compability.
Bug: T154300
Change-Id: I882599ac1120789bb4e524c4394870680caca4f4
When collapsed, make sure we are adjusting the 'min-height' on the
'rcfilters-head' div so that it actually takes the space it should.
Make sure the preference of whether the area is collapsed or not is
preserved for the user, per RC or WL pages, and that it is loaded
properly with the correct minimum height dimensions depending on
which state is in the preferences, so to prevent "jump" of the
result list after load.
Bug: T177206
Change-Id: I82c3042cd1bb85dedcd6b5458b157fed94def808
The 'mediawiki.special.changeslist.visitedstatus' module is only
used in SpecialWatchlist.php, which also always loads
'mediawiki.special.watchlist'. Thus, registering them as seperate
deliverables isn't needed.
In terms of size, they're also sufficiently small that even if
they could load under different conditions, it'd fine to load
as one module regardless.
Bug: T192623
Change-Id: I67d78083ce7a3000c05356e3eb0bcb98d0c1e990
These stylesheets are sufficiently tiny that it doesn't make sense to
offer them the ability to be loaded separately from each other (saving
bytes in double-digits) at the cost of 1) exporting a dedicated registry
item with meta data shipped on every page view, 2) reduced cache re-use
from increased fragmentation.
Instead, move these to the 'mediawiki.special' style module.
The entries retain their own files to keep them as easy to find
and edit as before.
Where not already, ensure addModuleStyles() is always placed above
any addModules() call in the same method. The load order isn't
affected by the call order, but given blocking style-modules load
before async JS, it helps to order them in a way that visually
matches the effective load order (from top to bottom).
The following 7 modules were remove without deprecation:
1. "mediawiki.special.apisandbox.styles" (1 rule)
2. "mediawiki.special.edittags.styles" (3 rules)
3. "mediawiki.special.movePage.styles" (1 rule)
4. "mediawiki.special.pagesWithProp" (1 rule)
5. "mediawiki.special.upload.styles" (2 rules)
6. "mediawiki.special.watchlist.styles" (3 rules)
7. "mediawiki.special.comparepages.styles" (4 rules)
These module names were only used on the core classes loading them, and
aren't depended on outside core by module name, rather, extensions and
gadgets depend on the styles styles being loaded in a blocking manner on
these pages, which remains unaffected.
Bug: T192623
Change-Id: I6e663dc3c80c7104c9b9abdde44c654543185373
Unpatrolled, manual and auto.
This moves the old hidepatrolled/hideunpatrolled filters to a legacy
group, and adds a new string options group with three options.
Also adds code mapping the old parameters to the new ones, and handling
for the hidepatrolled preference.
Bug: T190408
Change-Id: Ic1f181d3704c1d998696617a0d10270a87f22a62
isStructuredFilterUiEnabledByDefault() should no longer be overridden,
overrides should be put in the static checkStructuredFilterUiEnabled()
instead. That function was already added, but the duplicated non-static
function wasn't removed.
It looks to me that ?rcfilters=1 shouldn't have been working on
Watchlist for this reason, but it was working, and I can't figure out
why.
Change-Id: Iaf962b4e0428e262b57dc12ee0ba2cb6f854eb7e
* Each has a hidden preference to override the preferences value
* Each value is different between Watchlist and RecentChanges
* rcfilters-limit is updated when rclimit is changed
* Not conditionally hiding the rcdays, watchlistdays and wllimit yet
because hide-if's behavior is annoying
Bonus:
* Add a static method to check whether RCFilters UI is enabled
and enabled by default. Adjust the call for Watchlist which
checks a slightly different configuration setup.
Bug: T174415
Change-Id: Ib933de3a3f9e876924386e80f315506f60f8af54
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
Get rid of isPerGroupRequestParameter and define a consistent
interface that all filter groups can implement.
Change-Id: Ib904bcdc697c65722a0041ac611d1e00c577389f
Convert Watchlist settings to new UX, with following rules:
- If "Hide edits by anonymous users from the watchlist" is checked,
add "Registered" filter to defaults.
- If "Hide edits by logged in users from the watchlist" is checked,
add "Unregistered" filter to defaults.
- Change test for Special:Watchlist page, so new structured filters
are supported.
Bug: T172757
Change-Id: I27bdaa1401323fa3143f79a57dc5b9773e48fd1d
If6280ad6 changed the interpretation of the URL parameter "days=0" (or
any negative value) from meaning "maximum number of days" to actually
meaning "0 days". That's a somewhat annoying breaking change, but easily
worked around by updating bookmarks.
But it didn't update the display on the page, so despite querying 0 days
it would still incorrectly say something like "in the last 720 hours"
rather than "in the last 0 hours".
Bug: T176857
Change-Id: I90c79ef9c4819a34060515b863277fd185828ed9
Moved handling for 'from', 'days' and 'limit'
to base class (ChangesListSpecialPage)
I moved 'days' because its implementation
is related to 'from'.
I moved 'limit' because it was getting lonely
and it's identical in all cases.
Bug: T176348
Change-Id: If6280ad6fbad65909e1d0b2a48344e24d485aca2
Check whether there is a default saved query on the server side, and if there is,
add the mw-rcfilters-ui-loading class.
Also centralize the code related to the saved query preferences.
Bug: T173533
Change-Id: I4138fde22bdd8cc55c65846b91184c3ad3057244
Currently this is disabled by default. On wikis with the BetaFeatures and
WikimediaMessages extensions installed, this preference is set (if the
$wgEnableRcFiltersBetaFeature flag is set) via BetaFeatures. This change
lets users on normal wikis use these too, and lets BetaFeatures-capable
wikis "graduate" the feature to be provided to all users by default.
Bug: T168376
Change-Id: I3c75f9f2f6287414bf330f116d959d078250392d
... so it can be used by ORES to know if it's
enabled on a specific page without duplicating
the checks of global variables, user preferences,
and request parameters.
Bug: T174725
Change-Id: I1cb402559edb242b40a77f509480560f0636264d
Makes the unseen changes description customizable
based on whether or not the beta feature is enabled.
Bug: T172030
Change-Id: I0cef7e5fb261e12f3ca069e7409f3aea3fc874cf
* Respect different default values for 'limit' and 'day'
in RC and WL.
* Make 'latestrevision' respect 'watchlistextended'
Introducing 2 properties to ChangesListBooleanFilter
* activeValue: The value that defines when a filter is active.
Most filters are active when they are set to 'true' but
'extended' has no effect when it is 'true' and applies
filtering when it is set to false.
* isVisible: Whether this filter is visible anywhere.
'extended' is not visible in the legacy form but
it is activated from preference or URL. When
understanding form submission, it should not be assume
to be 'false' when not present in the request.
Bug: T171134
Change-Id: I3e48a9f2d9b70f0b9f6d7c6329db9c8e8001ee49
Handle the fact that wl_notificationtimestamp
can be null.
Always join with 'page' table to support highlight.
Bug: T171127
Change-Id: I150a41b131d64163e06bfa56bddbd762bb636655
* Add classes prefixed with cl (for ChangesList)
to both RC and WL so that the JS app can locate
similar elements using the same selectors
* Make saved queries preference name configurable
so that RC and WL use different preferences
* Move some code from SpecialRecentchanges.php to
its base class so it's accessible to SpecialWatchlist.php
To use the RCFilters app on WL, append ?rcfilters=1 to the URL
Bug: T171132
Bug: T171218
Change-Id: If7c63284224df24fa02022b4ea74bef116f28ca6
When the 'watchlistunwatchlinks' preference option is enabled, this
adds a '×' link to each entry of the watchlist that unwatches the page
of that entry. When clicked, it changes into a '+' which can be used to
re-watch the page (effectively undoing the earlier unwatch).
When a page is unwatched, its entries and the entries of its associated
talk page (or vice versa) become translucent and are struck through.
Without JS, '×'/'+' link to action=(un)watch for the relevant page.
In addition, ChangesList classes have been modified to allow a prefixer
that adds a prefix to each line (used in this case to put the unwatch
link) and to add HTML data attributes to reliably determine the target
page of each entry. Unit tests have been updated accordingly.
Bug: T2424
Change-Id: I450b2901413d7e75c11de2a446829fdbb22d31e1
- mostly auto fixes
- some too long lines fixed
- ignore amp space in one case passing by reference
Change-Id: I6472f83bc3cbf4bd629d83050cc3319b19ec465c
In non-extended mode, the query that SpecialWatchlist ran
was unlimited, which is a very bad idea, since some users
have tens of thousands of pages on their watchlist.
There are broader performance issues with large watchlists,
but this doesn't help.
With this patch the wllimit preference is used to limit
the number of results both in expanded and in non-expanded mode.
Bug: T171027
Change-Id: Ifcefe6f77fa4adeca2e50714813004018819aee8
Without this, setting the 'days' param to a very high value
causes exceptions while doing timestamp math.
Bug: T149890
Change-Id: I5aee5f027cced8860eb966e2d6bdb07764ce861a
This is pretty fragile; it's easy to accidentally miss one of the
checks (as has already happened in e.g. parseParameters).
Although I don't yet know of any bugs as a result of this, it's
cleaner to do it at registration time.
There are no extensions using this feature.
Change-Id: I8547ea6432cae73e1bc272dbe959f2415b8a6d21
Fix a regression caused by aa063f4c5a. Restore the behavior
where:
* Without action=submit: Boolean preferences apply to the displayed form and its
results, but they can be overriden by the query string.
* With action=submit: Only boolean parameters in the query string apply;
preferences are not considered.
(However, boolean preferences not on the form, i.e. 'extended', still
always apply.)
This behavior is a consequence of how checkboxes work in HTML; only
checked boxes are sent to the server.
Bug: T160734
Change-Id: Ic050dd1445ade9449496bb051f04ca0a87b8b5d7
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
