To fix T123930, it would be very handy to have the summary for each
module without any of the additional explanatory text.
Bug: T166411
Change-Id: I778bab2b87971875aed4c804341ad59c1c6e021f
Enhanced RCFilters: Add the ability to filter by namespaces to RCFilters.
🎉🎁🎊
- Add the ability to separate groups of filters by 'views'
- Add the first views as 'default' (for predefined filters)
and 'namespace' as the list of namespaces.
- Add 'nsinvert' to namespace group
- Allow highlighting namespaces
- Allow searching on either view, depending on prefix
- Add a way to switch views by typing prefix, clicking the
'Namespaces' button or clicking a tag (either namespace
or filter tag, changes the view accordingly, and adds
or removes the prefix from the input to stay consistent)
- Add an optional wrapper text for tags, so we can represent
them with their respective prefixes and (if needed) with
a special message for inverted state.
- Add unit tests and make pass
- Bonus: Fix issue with URL not updating (and not being updated)
the inverted and highlight enabled states.
Bug: T159942
Bug: T163521
Bug: T164130
Change-Id: I7e83f0800cbeb289dfd3461c1c5a197c053147ca
The backend always merges the query with wiki/user defaults before
it gives us data. The frontend, though, initially assumed that the
state is given strictly by the URL parameters (especially after the
URL shorening commit). This made it so that the frontend state is
incompatible with backend state.
However, always merging frontend state with user/wiki defaults can
produce inconsistencies between URLs in the same wiki, preventing
users from sharing them -- and making it potentially break if ever
a wiki default changes.
The solution is to add 'urlversion=2' to all RCFilters-generated
URLs and have the backend recognize this parameter as 'do not
merge with defaults'.
When RCFilters frontend loads, it checks whether the parameter
exists; if it doesn't, it merges whatever it sees with the defaults
just like the backend, then it transforms the URL to represent the
correct full state, and adds 'urlversion=2' to the URL parameters,
making it consistent across accounts and through time for the
next time it will load.
This means several new behaviors over the 'short url' commit:
- Accessing Special:RecentChanges directly (no query) will result
in one of two things:
-- If there is a saved query that's set to default:
The system will load that saved query "straight forward" (as
if the user clicked that option from the menu) causing, also,
an ajax re-request from the server (since the server does not
yet know about saved queries or their potential for being
the default state.)
-- If there is no saved query default: The system will load
user/wiki defaults (like the backend does) and then fix the
url to represent this state fully (with parameters showing the
actual state of the filters.
-- Both cases will also result in adding 'urlversion=2' to
the end result URL.
- Accessing Special:RecentChanges?urlversion=2 (without any other
parameters) will result in loading a completely empty filter set
in RCFilters. We assume that 'urlversion=2' does not load defaults
even if it is the only parameter in the URL.
- Accessing Special:RecentChanges?hideX=1 (parameter set without
urlversion=2) will result in the front end taking the requested
parameters, merging them with user/wiki default (reproducing what
the backend does) and then adding urlversion=2 to the URL.
In all cases except for the default-saved-query-load case, the initial
load will **not** re-request data from the backend. The backend needs
to adjust to respect urlversion=2 as well (will come in an upcoming
commit) so the state and expectation of both the front- and back-end
are the same.
This commit also factors out URL handing to a separate class (UriProcessor)
and adds unit tests for it.
Bug: T166907
Bug: T166972
Bug: T166974
Change-Id: I0eed3bc0d4fa4810b6301b535c75b6bfbc8b4a5b
Similar to what WANObjectCache and CachedBagOStuff are already doing.
Also add missing tests for WANObjectCache (similar to those for CachedBagOStuff).
Bug: T167465
Change-Id: I1a0c9324726aa6a1b221def985773b1b819181fd
selectField() and selectFieldValues() are trivial, they just need to
pass it through to select(). In fact, selectFieldValues() was already
doing it, just no one ever updated IDatabase.
insertSelect() is a little more work. nativeInsertSelect() was
originally written as largely a copy-paste of select() and has since
gotten well out of sync. Now that we have selectSQLText(), we should be
able to just use that. DatabasePostgres's implementation can wrap the
parent implementation instead of being another copy-paste, but
DatabaseOracle seems to still need to be special.
Change-Id: I0e6a9e6daa510639d3212641606047a5db96c500
The handling of the 'editsection' option prior to I7fb9ffca9 was
unusual: it was included in the cache key, but the getter didn't ever
flag it as "used". This was overlooked in I7fb9ffca9.
This fixes the handling to restore that behavior. It's no longer
considered to be a real parser option, so changing it won't make
isSafeToCache() fail while reading it won't flag it as 'used'.
But to keep Wikibase working (see T85252), if 'editsection' is supplied
in $forOptions optionsHash() will still include it in the hash so
whatever Wikibase is doing by forcing that doesn't break. The hash when
it is included is the same as was used in I7fb9ffca9 to reuse keys.
Once optionsHashPre30() is removed, Wikibase should be changed to use
some other method to fix T85252 so we can remove that hack from
optionsHash().
Change-Id: I77b5519c5a1122a1fafbfc523b77b2268c0efeb1
Without this patch, Title::getPrefixedText() would return ":Foo"
if the namespace was unknown, potentially creating a misleading
link to the main namespace. With this change, getPrefixedText()
will return something like "Special:Badtitle/NS12345:Foo".
Note that round trip behavior is broken either way.
Bug: T165149
Change-Id: I0d491a2b58ff45f207f83ee62ca6e7e6ffbf790a
Some versions of html-tidy (e.g. the one currently in use on WMF wikis)
will try to move all <style> tags in the body into the head, effectively
removing them for our purposes. We need to avoid that for TemplateStyles.
Bug: T167349
Change-Id: I133776d16f366cad73ed30af0e5a665fdf9f5ed9
Guarded by the $wgUsePigLatinVariant variable, off by default.
Pig Latin is a language game where words in English are altered
according to the following rules:
* Words starting with a vowel have a '-way' suffix appended.
* Words starting with a consonant have the initial consonants (or 'qu'
group) moved to the end and an '-ay' suffix appended.
https://en.wikipedia.org/wiki/Pig_Latin
* Added 'en-x-piglatin' as a language name.
* Added 'en' to LanguageConverter::$languagesWithVariants.
* Added LanguageEn class and its corresponding EnConverter which
provides one-way translation from English to Pig Latin.
* Some minor internal changes in code that assumed that English
doesn't have a language class or converter.
Bug: T45547
Depends-On: I1d9691c784032669979f8109c9a5f65cbf4122c9
Change-Id: I7fa2d85d6364958c5138366e8b4504a2697a8731
Now that ParserOptions->isSafeToCache() exists, use it where necessary.
This also moves the use inside the makeParserOptions() method so other
callers can pick it up as well.
Then pass the flag as $forceParse into WikiPage::getParserOutput()
instead of duplicating the logic in several cases, and generally clean
up the logic in the module to let WikiPage decide when to use the cache
in more cases.
Change-Id: I0079e10a40997e4a3b59ac21ef6c92246a147736
We have several types of change lists (old RC/watchlist/related
changes, enhanced RC/watchlist, history) with slightly different
HTML, each with their own idiosyncracies. JavaScript code trying
to identify lines by log ID / revision ID has to jump through all
kinds of hoops to work with that.
To simplify the lives of frontend / gadget maintainers and provide
something approaching an API for these pages, we now expose the basic
attributes of each change line (revision ID for edits, log type/action
and ID for log events) as data attributes.
The OldChangesListRecentChangesLine, EnhancedChangesListModifyLineData,
EnhancedChangesListModifyBlockLineData, PageHistoryLine,
ContributionsLineEnding and DeletedContributionsLineEnding hooks
are updated accordingly. New hooks (LogEventsListLineEnding and
NewPagesLineEnding) are added for the change list pages which did
not yet have them.
Change-Id: I6dd006d0b1b0fd35c0020f0f9eea9113eca30b35
In 1bf5a652 the id selector was changed to a class selector for toctitle.
The cached HTML has been expired now and the id selector is not necessary
anymore.
Also remove the id selector #toc.tochidden for print style. This is not
necessary because the tochidden gets only added to .toc and not to #toc.
Change-Id: I43cfffdb0807e8ed8f6b7b8732ba857b709bee80
From 21% to 82%.
* Added missing @covers, broadened @covers where appropriate.
* Added tests for some code that lacked them.
* Added a parameter to control the use of hash_pbkdf2() so that the pure
PHP fallback could be tested. In the non-fallback test, force the use
of the extension, and mark it skipped if it is not installed.
Bug: T167003
Change-Id: I987e1a89ec343907f4ead7f6192b2d4deb58ac16
* Convert year/month date filter parameters to use start/end so that
ApiFeedContributions still works as expected after b668887
* Move SpecialContributions::processDateFilter (used to convert
year/month parameters to start/end parameters) to ContribsPager
since ApiFeedContributions also uses it now
Bug: T166859
Change-Id: I34fc8388a29e4cd36474934e6266127d0e3253cd
Using names that match real OOjs UI icons is confusing when trying to
find usages of the real icons and when debugging the tests.
Bug: T166730
Change-Id: Ibb97c0347476efc95f1a50c97822d7dab19737f2
Support diffing deleted revisions, user-supplied text, and additional
properties about the diffed revisions such as the user and edit summary.
Bug: T20189
Bug: T30047
Bug: T164529
Change-Id: I5565d717d9c2fd19da7cae02890a15e244cc238b
* ParserOptions is reorganized so it knows all the options and their
defaults, and can report whether the non-key options are at their
defaults.
* Definition of the "canonical" ParserOptions (which is unfortunately
different from the "default" ParserOptions) is moved from
ContentHandler to ParserOptions.
* WikiPage uses this to throw an exception if it's asked to cache
with options that aren't used in the cache key.
* ParserCache gets some temporary code to try to avoid a massive cache
stampede on upgrade.
Bug: T110269
Change-Id: I7fb9ffca96e6bd04db44d2d5f2509ec96ad9371f
Depends-On: I4070a8f51927121f690469716625db4a1064dea5
