In the JavaScript and CSS content handlers we render the page "as
wikitext" solely to generate categories, toc, etc, and then throw that
output away and replace the generated HTML. Simplify the code paths
and the caching by using the canonical options which don't split by
user language, etc.
Three minor issues with the current patch, which can hopefully be
addressed in follow ups:
1. WikiPage::makeParserOptionsFromTitleAndModel() has a very cumbersome
name and arguably doesn't belong in WikiPage in the first place.
T313455 already exists to find a better place for this/way to do this.
2. Title::isConversionTable() requires a downcast of the page reference
to a full title object. This method also probably wants to live
somewhere else.
3. It really would be nice to combine this more properly with
ContentHandler::getParserOutputForIndexing(), but that method
uses a ParserOutputAccess object which requires a PageRecord,
and we don't have a PageRecord available in fillParserOutput().
Bug: T307691
Change-Id: I081105741b507ed49e19cb878550ba4293e09413
Previously:
* It was unclear that generate-html is an optional optimization
* Most of MediaWiki core was doing $parserOutput->setText('') if
html wasn't generated. However this is wrong and will cause
$parserOutput->hasText() to return true and also potentially cause
cache pollution if a content handler both does that and supports
parser cache (Like MassMessage; see T299896)
* The default value of mText in the constructor was '', and most
of the time MW used that default. This doesn't seem right. If
setText() is never called, the ParserOutput should not be considered
to have text
* It was impossible to set mText to null, as $parserOutput->setText(null)
was a no-op. Docs implied you were supposed to do this, so it was very
confusing.
This patch clarifies docs, changes the default value for ParserOutput::$mText
from '' to null, and makes $parserOutput->setText(null) do what you
expect it to. The last two are arguably breaking changes, although
the previous behaviours were unexpected, mostly undocumented and
based on a code search do not appear to be relied on.
It seems like the main reason this only broke MassMessage is most
content handlers either don't support generateHtml, or they don't
support parser cache.
Bug: T306591
Change-Id: I49cdf21411c6b02ac9a221a13393bebe17c7871e
Depends-On: I68ad491735b2df13951399312a4f9c37b63a08fa
This edition brought to you by:
grep -ERIn $(grep -o "'[A-Za-z0-9_]*'" includes/MainConfigNames.php | tr
"\n" '|' | sed 's/|$/\n/') includes/
I only corrected a fraction of the results provided by that command. I'm
submitting the partial patch now so it doesn't bitrot.
Bug: T305805
Change-Id: If1918c0b3d88cdf90403921e4310740e206d6962
Update/Create override classes of ContentHandler.
Soft-deprecate and remove method from Content and classes that override them.
Bug: T287158
Change-Id: Idfcfbfe1a196cd69a04ca357281d08bb3d097ce2
Update ContentTransformer to access ContentHandler::preLoadTransform through the service.
Prepare object to hold a data that required for ContentHandler::preLoadTranform params.
This is a fully backwards compatible change.
We are doing hard deprecation via MWDebug::detectDeprecatedOverride.
However, with the ContentHandler calling Content and
Content calling ContentHandler, it doesn't matter whether
callers use Content or ContentHandler. This will allow us
to naturally convert all callers.
Bug: T287157
Change-Id: I89537e1e7d24c6e15252b2b51890a0bd81ea3e6b
If an exctension ContentHandler overrides one of the
subclasses of the core ContentHandler, for example
TextContentHandler, when switching calls we no longer
call deprecated Content::preSaveTransform for the
extension Content model.
Bug: T288191
Change-Id: Ie7edc97be9098f3cd188949bd37943c37a0b65ff
Create ContentTransformer to access ContentHandler::preSaveTransform through the service.
Prepare object to hold a data that required for ContentHandler::preSaveTranform params.
This will require making a semi-backwards-incompatible
change no matter what, we don't really have a great way
of hard-deprecating overriding methods.
However, with the ContentHandler calling Content and
Content calling ContentHandler, and with the ProxyContent
trick to stop infinite recursion, it doesn't matter whether
callers use Content or ContentHandler. This will allow us
to naturally convert all callers. But won't really allow
hard-deprecation.
Bug: T287156
Change-Id: If6a2025868ceca3a3b6f11baec39695e47292e40
When a JavaScript page is moved, a "redirect" in the form of
mw.loader.load(...) will be left behind, so any other
JavaScript loading the page that way will still work, albeit
with an extra HTTP request.
This also implements Content::getRedirectTarget(), so redirects
are marked properly in the database, and users viewing them
are redirected properly. A magic "/* #REDIRECT */" comment
must be in front of the mw.loader.load call. This is done so
that pages which currently are just one mw.loader.load call
aren't turned into redirects.
Bug: 71200
Bug: 33973
Change-Id: I10fdff087a901da56fad64531f0e382f90ebcf37
* 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
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
- 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
Reasons for touching this are:
* "@param type $var" were mixed in a lot of places. Both works but the
MediaWiki coding conventions suggest that specific order.
* Things like String and Bool aren't objects and shouldn't be uppercase.
* Tried to fill missing types in "@param $var".
* Tried to fill missing descriptions in "@return type" when I could.
* Removed duplicate descriptions if a @see is sufficend.
* Removed useless descriptions ("isUsefull returns true if usefull").
* Removed useless @return void.
* Replaces mixed[] with array (does have the exact same meaning).
* Tried to find better replacements for "varargs", phpDocumentor
suggest $var,...
* Order should be @since, @param, @throws, @return, @see. This is the
order Doxygen renders this.
There is always more to do but I think this is already much better
than before. Please feel free to put more change sets on top of mine
or request more changes by adding comments.
Change-Id: I05262ce06caabf79f68772302524ac91bbead1c6
MediaWiki is licensed under GPL so we should really add the header to
our PHP code unless reusing code licensed differently.
Tested using:
ack-grep --php -L 'This program is free software' \
includes/ maintenance/ mw-config/ resources/ skins/
Output the following files:
includes/ExternalEdit.php (public domain)
Various other licenses:
includes/json/Services_JSON.php
includes/libs/CSSMin.php
includes/libs/IEContentAnalyzer.php
includes/libs/JavaScriptMinifier.php
includes/libs/jsminplus.php
includes/normal/Utf8Case.php
includes/objectcache/MemcachedClient.php
File autogenerated from a GPL file and Unicode data:
includes/ZhConversion.php
A few lines coming from stack overflow:
maintenance/mwdoc-filter.php
Message files do not have any license :-/
Change-Id: I214a988edfa9e2dfcc762612a0f7d47eee8bcb74
