This does not move the actual limit report data into
ParserOptions yet, that should be done separately
given that it will require serialization changes.
Let's get this change settled first before messing
with serialization.
This unifies canonical and non-canonical ParserOptions,
so ParserCache can now be used with both. It is hard
to say how this will affect the ParserCache capacity,
so we should monitor it after releasing this.
Change-Id: I154c0a77a5b0287b5572614d56339fb57ac56c33
Since 1.34 setting non-default HTTP engine
has been deprecated. It's time to remove
the old implementations. Only Guzzle is
now available.
Change-Id: I978b75827e69db02cbc027fe0b89a028adfc6820
The following User methods, deprecated in 1.37, have been removed:
- ::resetIdByNameCache,
- ::getStubThreshold,
- ::matchEditTokenNoSuffix,
- ::changeableByGroup
- ::changeableGroups,
- ::isAllowUsertalk
ActorStore::clearCaches() has been removed, since User::resetIdByNameCache
has been removed. User::$mAllowUsertalk has been removed, since
User::isAllowUsertalk has been removed.
Bug: T277511
Change-Id: I608a5277924fc50cc3d9fca6ba958bc6d9c321d0
Feature code that needs the composition API will need this as long as
we're still on Vue 2. This will also help migrate to Vue 3 more
seamlessly, as working around some breaking changes in Vue 3 requires
using the composition API.
Bug: T251974
Change-Id: I8e334ae5f447a8f9b64a7c910b2c1776cef118db
Use ContentRenderer::getParserOutput instead.
Extensions defining a content model should override ContentHandler::fillParserOutput.
Update tests.
Bug: T287158
Change-Id: I1c71a8429806f1813a39f5807256b2eb9fb9901f
Before this commit, each bind function would return an object containing
a reference to the function used in the event listener creation with the
intention that this could later be used to cleanup the event listeners.
This is problematic for the following reasons:
* In order to cleanup the event listener, it forces the client to know
which element the event listener was added to (button, checkbox,
document, window, etc.),. the event type that was used ('click',
'focusin', etc), and whether or not the "useCapture" param was also
used. The `removeEventListener` API won't remove the correct event
listener unless these three pieces of info are known by the client [1].
* Because the above point is tricky to get right, numerous potential
memory leaks were possible with the `unbind` function as the
`useCapture` param wasn't being passed in some cases.
This commit aims to simplify the cleanup API by returning an anonymous
function in each bind function that the client can call to cleanup the
relevant event listeners without knowing any of the implementation
details. This also makes the `unbind` function unnecessary.
** This is a breaking change to the checkboxHack API ** but because
there aren't any known clients of the return values [2], a formal
deprecation process was assumed to be unnecessary. Note gadgets should
not be using the internal function mw.loader.require so these were
not considered.
[1] https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/removeEventListener#matching_event_listeners_for_removal
[2] https://codesearch.wmcloud.org/search/?q=checkboxHack&i=nope&files=&excludeFiles=&repos=
Bug: T291096
Change-Id: Ia2d79f27dd81fdc74a44829da3ca472f4c01d4b5
LinkCache::addGoodLinkObj was hard deprecated.
Use addGoodLinkObjFromRow() instead. PHPUnit tests
must use LinkCacheTestTrait::addGoodLinkObject().
Bug: T284955
Change-Id: I0c22be2f00e6d6d4ba6dd1511c5385cad55e8ff7
After the hooks were removed we are finally ready to stop
reading user options from primary before writing them on save.
The new save hooks only work on modified options, so options
saving code can be significantly simplified.
Change-Id: I48df616c9f35d9a0b2801ada1b7dbef0bd4ad058
MWNamespace has been deprecated in favor of the NamespaceInfo
service in 1.34 and should no longer be used.
All methods are unused in wikimedia-deployed extensions.
Bug: T291389
Change-Id: Ibe2069dea1af983d8fda53e734396c5a7a8b7321
Encourage localization and factor out common code by taking a message
key as the first argument to ::addWarningMsg() instead of a wikitext
string. This also plays nicer with Parsoid by separating out the
localization code from the parse.
Bug: T293515
Change-Id: I6a7c04c67ac586ab00d4edcbb3d09485a7794e23
This is a uniform mechanism to access a number of bespoke boolean
flags in ParserOutput. It allows extensibility in core (by adding new
field names to ParserOutputFlags) without exposing new getter/setter
methods to Parsoid. It replaces the ParserOutput::{get,set}Flag()
interface which (a) doesn't allow access to certain flags, and (b) is
typically called with a string rather than a constant, and (c) has a
very generic name. (Note that Parser::setOutputFlag() already called
these "output flags".)
In the future we might unify the representation so that we store
everything in $mFlags and don't have explicit properties in
ParserOutput, but those representation details should be invisible to
the clients of this API. (We might also use a proper enumeration
for ParserOutputFlags, when PHP supports this.)
There is some overlap with ParserOutput::{get,set}ExtensionData(), but
I've left those methods as-is because (a) they allow for non-boolean
data, unlike the *Flag() methods, and (b) it seems worthwhile to
distingush properties set by extensions from properties used by core.
Code search:
https://codesearch.wmcloud.org/search/?q=%5BOo%5Dut%28put%29%3F%28%5C%28%5C%29%29%3F-%3E%28g%7Cs%29etFlag%5C%28&i=nope&files=&excludeFiles=&repos=
Bug: T292868
Change-Id: I39bc58d207836df6f328c54be9e3330719cebbeb
This function, added in 1.34, does not appear to be used outside core:
https://codesearch.wmcloud.org/search/?q=-%3EgetAllFlags\%28\%29&i=nope&files=&excludeFiles=&repos=
It currently exposes representation details of ParserOutput (that is,
whether a boolean flag is stored in an explicit property, in the
$mFlags array, or in the $mExtensionData array) and so it would be
best not to expose it outside core so as to facilitate any future
change in the internal representation of ParserOutput.
Bug: T292868
Change-Id: I7b6d309425ff01dc211334b848068d0b9c0f9261
This moves the implementation of ParserOutput::addTrackingCategory()
to the TrackingCategories class as a non-static method. This makes
invocation from ParserOutput awkward, but when invoking as
Parser::addTrackingCategory() all the necessary services are
available. As a result, we've also soft-deprecated
ParserOutput::addTrackingCategory(); new users should use the
TrackingCategories::addTrackingCategory() method, or else
Parser::addTrackingCategory() if the parser object is available.
The Parser class is already kind of bloated as it is (alas), but there
aren't too many callsites which invoke
ParserOutput::addTrackingCategory() and don't have the corresponding
Parser object handy; see:
https://codesearch.wmcloud.org/search/?q=%5BOo%5Dutput%28%5C%28%5C%29%29%3F-%3EaddTrackingCategory%5C%28&i=nope&files=&excludeFiles=&repos=
Change-Id: I697ce188a912e445a6a748121575548e79aabac6
Make ::setCategory() consistent with the corresponding singular method,
which is ::addCategory(), not ::addCategoryLink(). Also, don't return
a value.
This renaming is in preparation for factoring out a write-only base
class from ParserOutput suitable to be used by Parsoid.
Note that OutputPage does distinguish a 'category link' from a
'category list', and there are separate OutputPage::getCategories()
and OutputPage::getCategoryLinks() methods. However, the category
map in ParserOutput isn't exactly the same as either of these:
it's actually a map (or list of pairs) of category name to sort key.
Rename ParserOutput::getCategoryLinks() to ::getCategoryNames()
in order to clarify that the concept involved is not the same as
the OutputPage "category links" methods.
Code search:
https://codesearch.wmcloud.org/deployed/?q=-%3E(get%7Cset)CategoryLinks%5C(&i=nope&files=&excludeFiles=&repos=
(Note that many of the code search matches are for the methods in
OutputPage, which we are trying to disambiguate here.)
Bug: T287216
Change-Id: Idb383d3d9ef7b76f8a0208a057a3cb8c639465c9
Instead of a paragraph of prose listing things that are now gone, give
an actual list, and match the method with the replacement, rather than
having people have to scan each option.
We don't use the term 'hard deprecation' in user-facing documentation.
Change-Id: I9c4ac0bcf4464bbc28f4e6eb1a4c2bd2693f5668
No longer used from there by the mediawiki.cookie module
No deployed javascript tries to use these, but a few undeployed
extensions do, so added to release notes.
Bug: T291760
Follow-up: I600332cdb738f0b443549948b9f070f3ccfa12aa
Change-Id: Ia02048137f191b950ae789a9d206c1d9afbce83a
- Added a test where ParserOutput objects with CacheTime
properties set are unserialized from previous versions.
- Generate new serialization tests for 1.38
Now all serialization in production is JSON, so changing
property visibility shouldn't affect ParserCache.
Bug: T263851
Depends-On: I283340ff559420ceee8f286ba3ef202c01206a23
Change-Id: I70d6feb1c995a0a0f763b21261141ae8ee6dc570
Fix the last drifts between the two. Custom CSS IDs/names/classes in
FileDeleteForm were replaced with the base one, as I think it's better
to be consistent, and it wouldn't be trivial to allow changing those
values in a clean way. Question for reviewers: should this part be
announced on tech news in case somebody is using those values in a
script?
Move the file delete intro above the form, like we do for normal
deletion.
For normal deletion, use the content of the wpReason field as default
value for that field, not the result of merging the dropdown and the
"other" field, which doesn't seem correct (the file version was already
doing this).
Make the file deletion form use the title as token salt like the base
form -- it shouldn't make any difference AFAICS.
After this patch, it should be possible to make DeleteAction extend
FormAction with low effort.
Bug: T288282
Change-Id: I8b115ecb1c94af63d686a575b18362ac32105ae2
