'isParserCachedUsed' implies that the parser cache usage has already occurred,
and obscures the true purpose of this method, which is to determine whether or
not the requested page *should* be looked up in the parser cache.
Only usage in extensions is in TextExtracts, which I changed to be both
backward- and forward-compatible in If5d5da8eab13.
Change-Id: I7de67937f0e57b1dffb466319192e4d400b867de
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
This adds supportsDirectApiEditing and
supportsDirectEditing methods to ContentHandler. Both
return false by default for the ContentHandler base
class, and true for TextContentHandler and it's
derivatives. (everything in core)
Extension content types that directly extend
AbstractContent / ContentHandler, often / generally don't
support direct editing. EntityContent in Wikibase
and Flow boards are the two such content types currently
in gerrit-hosted extensions.
The use and direct settings of the allowNonTextContent
member variable is replaced by enableApiEditOverride and
a setter for that. The only place allowNonTextContent is
used in all of Wikimedia-hosted git repos is core itself
(EditPage and ApiEditPage), so should be safe to make
this change.
With this change, Wikibase can remove its ApiCheckCanExecute
hook handler that disallows editing there, and MobileFrontend
could check if direct editing is allowed before enabling it's
editing features, instead of Wikibase having to add
MobileFrontend hook handlers to disable the features.
Bug: T96382
Change-Id: I276cd6ecedf38108f1f2be16b38e699e8c5d2d0c
The prepareSave function expects the latest revision ID of the article
being replaced. Instead, we were passing an ID only used for rollbacks
and other special effects.
Change-Id: I4647930566b9370052a820ae3a46e10a6bba65ce
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
* Remove is_object restriction from isValid.
* Implement rootValueTable to support rendering of other
root structures.
Also:
* Minor method documentation tweaks.
* Document why quotes are not escaped for strings in value cells.
Bug: T86270
Change-Id: Ic1d10393912fcefa22d675fd4aa2baf437d2a05a
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
Follows-up d2a82fcb60. These issues weren't previously exposed
as nothing uses JsonContent by default in core, and the extensions
using it (e.g. EventLogging) lock it down very early. As are
most of these methods were never really put to use (they were
called after the extension does its superset of checking, or
too early and WikiPage ignores it).
Bug fixes
* Empty JSON object was converted to an array by PST conversion.
The beautifyJSON method is intended for prettify purposes but
actually modified the content stored in the database and made
it no longer roundtrip ({} != []).
We can't change getJsonData to return an object since it's
a public method and people use it as an array. So we can't cast
it to a PHP object as that would break back-compat.
Turns out the class doesn't even support non-objects anyway (a
primitive in JSON can trivially cause a fatal as it wasn't
consistently considered invalid, though it didn't actually fatal
due to some lucky spaghetti code in WikiPage).
* Fix beautifyJSON by checking for empty objects to prevent
implicit {} to [] conversion.
* Add isValid() check to fillParserOutput() as it's called early
on. Otherwise it throws a warning that 'foreach' (in objectTable)
iterates over null. In practice it doesn't matter since the
entire parser output is rejected when WikiPage eventually
checks isValid (through Content::prepareSave).
* Consider all non- (PHP) array values invalid instead of just
non-null values.
Enhancements
* Display message "Empty object" instead of a completely blank page
for an empty object.
* Display message "Empty object" or "Empty array" instead of an
empty table cell.
* Render arrays as a list of values (without indices).
* Remove italics from table cells for values. The monospace font
should be enough. It also offsets it from the "Empty"
placeholders (which are italicised).
Refactoring and clean up
* Use FormatJson::parse so that we can use Status to distinguish
between null parse result and thus reliably cache it.
Ideally we wouldn't need to cache it, but right now this code
is pulled apart and called in so many strange ways that we end
up calling this several times.
* Improve fairly meaningless test (testBeautifyJson) that was
calling FormatJson in its data provider, exactly what the method
being tested did. It also provided the test with data that could
never end up in normal usage (a PHP-style associated array with
implied numerical indices).
* Document that this class rejects non-array values.
* Document the problem with WikiPage assumming PST can run on any
content. WikiPage fundamentally still assumes wikitext, in that
there's no concept of invalid content.
* Fix incorrect documentation for getJsonData's return value
(It may return null.)
* Fix incorrect documentation for beautifyJSON's return value.
(It never returned boolean.)
Bug: T76553
Change-Id: Ifed379ba4674a8289b554a95953951886bf2cbfd
They're currently documented as a 'compatibility hook'
in docs/contenthandler.txt. No longer used in any Wikimedia-hosted
git repository.
Superseded by the ContentHandlerDefaultModelFor hook.
Change-Id: I212230da7d6080cf500f930d4aa5a9024959d5f9
The new Extension:WikEdDiff is a custom inline difference engine.
There is currently no hook to integrate custom difference engines.
This patch adds a new hook called 'GetDifferenceEngine' in
/includes/content/ContentHandler.php in function
'createDifferenceEngine()'.
Passed variables:
$context: IContextSource context to be used for diff
$old: Revision ID to show and diff with
$new: Either a revision ID or one of the strings 'cur', 'prev' or 'next'
$refreshCache: If set, refreshes the diff cache
$unhide: If set, allow viewing deleted revs
&$differenceEngine: output parameter, difference engine object to be used
for diff
If the hook handler returns false, a valid difference engine object is
returned in the passed-by-reference variable $differenceEngine.
If the handler returns true, the default engine is used as fallback.
The specified diff engine class will typically be an extension of the
class DifferenceEngine (includes/diff/DifferenceEngine.php) with
modifications, e.g. of function generateTextDiffBody() and
__construct() (without deprecated parameter $rcid).
Also fixes a missing declaration in DifferenceEngine that is required for
extending this class.
Bug: 71916
Change-Id: I9da63c1ceb339bfeba7beddc712be51977b95f65
This hook is the counterpart of ContentGetParserOutput: it gives
high-level access to the parsing of a content object (as opposed
to lower-level parser hooks like ParserBefore*/ParserAfter* which
are called for all kinds of non-content input like interface
messages and don't have the necessary context to know what kind of
input is being parsed), but it is called when the parsing has
already finished.
The intention is to provide a convenient location for ParserOutput
modifications which depend on some global property of the parsed
content, but need to happen before LinksUpdate. Currently there are
no hooks between parsing (initiated by WikiPage::doEditUpdates()
calling WikiPage::prepareContentForEdit()) and updating the link
tables (initiated by the same method calling
Content::getSecondaryDataUpdates()), so any hook an extension would
try to use would face one of the following problems:
* the parsing output is not available yet
* LinksUpdate has run already, modifying list properties is unsafe
* there is not enough context to tell what's being parsed
A typical use of this hook would be to add tracking categories when
something is missing from the text (e.g. there are no references).
For the concrete use case, see I43ed79b6a54cd31820ecae8139e29c5880f5dd1b
Alternative approaches that have been suggested and do not require
a new hook but are not robust / do not rely on a clear contract:
* use ParserAfterTidy or a similar hook, assume that the input
being parsed is the main page content iff limit reporting is
enabled
* use ParserAfterTidy or a similar hook, assume that the input
being parsed is the main page content iff
ParserOptions::getInterfaceMessage() is false (this would yield
some false positives, but in those cases adding a tracking
category would probably have no effect)
Change-Id: I685b285fcc772382993116f7822a832eeecc0681
Since Id44d566a, the text passed to the parser when parsing a
&redirect=no page no longer contains the #REDIRECT directive. For the
benefit of extensions that want to know the redirect target from various
parser hooks, record the target on the ParserOptions object associated
with the parse.
Bug: 62856
Change-Id: Icd1da9911a43eabacbd9e9a369a8326f67f270ff
* All content handlers that deal with code/data tend to have
English as their page language & pageview language, so moved common
code to the abstract CodeContentHandler class.
* Renamed JSONContent & JSONContentHandler into JsonContent*
Change-Id: I46819a0572ef5becc211d0d82471ff7102edaa3c
Hopefully this will stop cache pollution when a MessageContent
ends up in parser cache. MessageContent objects just do
wfMessage()->parse(), which uses user language.
Bug: 41065
Change-Id: I75e8256a61b828cb9fc93227eb517a34ac6b9d15
We need to be able to set a different content model via the
constructor, so make it an optional parameter.
Change-Id: I8b31084e0cfbcca1b3785176eac492d837e0cb0f
* Created a ResourceLoader module for redirect page styling.
* Fixed a couple of bugs in Article code.
Keeping two of the old files for a while because they might still be
referenced by something (bug 69277 comment 11).
Bug: 69277
Change-Id: I8fa565833545e41d0232101566da8c5ffa850e36
Currently the names of associated Content classes are hardcoded,
meaning that any extension that wishes to subclass these implementations
must also re-implement that function, usually copying it exactly
with just the class name changed. Using "static" avoids that issue.
For ContentHandlers, I added a TextContentHandler::getContentClass,
which should be used when creating new Content objects.
Change-Id: I70f1a3291aec3460120ec20121a23f4cb68e04d1
When the method has a type hint of Content, there is no way to pass a
string, so remove that type from @param
Change-Id: Ifbf89d52cfa3ea8801c94f2d1b336e784133cce9
- Added since to @deprecated
- Use lowercase array on @param
- Added missing type on @param
- Swapped type and variable on @param
- Fixed spelling of @return
Change-Id: Idbbc6b4c8aadb6d98c636f53024ac513346c912b
As was discussed at the architecture summit, a basic JSON content
class which handles validation and basic display. Not intended to
be used directly, but for extensions to subclass.
Co-Authored-By: addshore <addshorewiki@gmail.com>
Change-Id: Ifcde9bcd0efcf15a3ab692dd2a0a3038559e0254
Fixes for change to enable the creation of blank pages. Added test
for this case.
Follow up: I3457c36a909d1dbfaeed04a1f0568c69e0ef3386
Bug: 57238
Change-Id: Id52be6cbe22c6098d1c0824d7a7848579aa05a84
This change enables the direct creation of empty pages without needing
to use a work-around (such as "{{subst:ns:0}}"). A warning is added as
the message "blankarticle" to request confirmation that the empty page
was meant to be blank. A automatic edit summary has been added when
creating a blank page. The message is: "autosumm-newblank."
The API has been updated to permit the creation of empty pages, when
"text" is null, but not non-existant.
Unit tests have also been added to test these features.
Bug: 57238
Bug: 65206
Change-Id: I3457c36a909d1dbfaeed04a1f0568c69e0ef3386
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I7b65fe04db431342cc58b469dc48f41a50c4e891
