Convert the wfDebugLog calls in ApiStashEdit to direct use of the PSR-3
logging layer and add severity information for each message.
Change-Id: Ic91e89ceee405a1d22e5e3c461ad37795cae4a6f
* These are hit when the stashed edit is several seconds
old. The old code was not using makeList() correctly.
Bug: T105597
Change-Id: I265307715996c50d819915a55ea34bbc0ed6c5c9
New types 'text' and 'password' for where a <textarea> or
<input type="password"> would be preferred over <input type="text">.
Some timestamp parameters get actually tagged as 'timestamp'.
'submodule' types change the 'submodules' output property from a boolean
to an object indicating the mapping from values to module paths. And
they get an indication of the submodule parameter prefix (e.g.
generator's "g"), if applicable. "generator" actually gets reported as a
submodule type, using this new mechanism.
action=paraminfo will now indicate ApiBase::PARAM_RANGE_ENFORCE status,
and return better-formatted defaults for timestamps and booleans.
Change-Id: Ic862d6f8fe13f7eb6b4298683514d33af5823e47
This is a hard deprecation, with getSecondaryDataUpdates returning an
empty array and addSecondaryDataUpdate throwing an exception. This seems
prudent since there are no known users of these methods, and they
interfere with the parser cache:
DataUpdates are basically jobs, they need access to services to
function. That makes them inherently non-serializable. This interferes
with the function of the parser cache, which serializes ParserOutput
objects in order to persist them.
This could be solved by splitting DataUpdates into DataUpdateDefinitions
and DataUpdateHandlers, similar to how JobSpecification works with
wgJobClasses. That however seems pointless and overkill, since
ParserOutput already has a mechanism for storing arbitrary data,
including any info needed by an UpdateJob: the setExtensionData method.
After this change, the preferred method to introduce custom data updates
is to store any relevant data using setExtensionData and
implement Content::getSecondaryDataUpdates() if possible. If not,
use the 'SecondaryDataUpdates' hook to construct the necessary update
objects from the info stored using setExtensionData.
Change-Id: I0f6f49e61fa3d8904e55f42c99f342a3dc357495
My previous patch broke this: ApiStashEdit would stash ParserOutput
with no custom DataUpdates, but calling getSecondaryDataUpdates still
failed after unserialization. This patch should fix that.
Bug: T86305
Change-Id: Ic114e521c5dfd0d3c028ea7d16e93eace758deef
The former is by far the most common.
Skipped:
* resources/lib/jquery.ui/jquery.ui.datepicker.js
* resources/src/mediawiki.special/mediawiki.special.upload.js
Change-Id: I73c93797e745128ba703e4865080c36784caa474
* This also changes previews to render section edit tokens but
remove them on output, avoiding cache fragmentation.
* Also shortened the resulting getStashKey() value.
Change-Id: Ic8fa87669106b960c76912b864788b781f6ee2e6
* Unlock the key at the right point, so checkCache actually sees the result
* Turn CRLF to LF just as EditPage does via getText(), this avoids misses
* Added a bit more debug logging
Change-Id: I5c296325ebee2501e5de59b8090e1ddde8689f17
An early version of what ultimately became commit 3a6c9d36c used
'ApiPreparedEdit' instead of 'ApiStashEdit'. The class / file were renamed but
not the log group.
Change-Id: Ib4de1f1f21f058d3be627048bc93e7730515d340
* This lets edits be prepared while users enter edit summaries.
* The edit form will now make use of this API, controlled by
$wgAjaxEditStash.
Change-Id: I4f4057bc0d1d4a66a8f7cfb7cdc26d443a8eb0c4
