They are replaced by Selenuium tests in Node.js.
Bug: T162455
Change-Id: I1f5bc8f9c5cd687a6ba116f2f0461eb2992096c7
Depends-On: Ibd8a39cc75231932f872456b8d3ec1fe41ef23e2
* Use the exactly same routines to deliver png images that are used in
mathml mode.
* Change the output to use mathoids png image rather than the mathml
and svg output.
* Locally tested on Firefox and Chrome: Depending on the mode either
the SVG or the PNG path is used.
Bug: T74240
Change-Id: I4b1cac92eb9a02190f316faab6621940951603d5
The motivation for this patch is to make the code less complex, better
readable, and less brittle.
Example:
public function onExampleHook( Parser &$parser, array &$result ) {
/* This is the hook handler */
}
In this example the $result array is meant to be manipulated by the
hook handler. Changes should become visible to the caller. Since PHP
passes arrays by value, the & is needed to make this possible.
But the & is misplaced in pretty much all cases where the parameter is
an object. The only reason we still see these & in many hook handlers
is historical: PHP 4 passed objects by value, which potentially caused
expensive cloning. This was prevented with the &.
Since PHP 5 objects are passed by reference. However, this did not
made the & entirely meaningless. Keeping the & means callees are
allowed to replace passed objects with new ones. The & makes it look
like a function might intentionally replace a passed object, which is
unintended and actually scary in cases like the Parser. Luckily all
Hooks::run I have seen so far ignore unintended out-values. So even if
a hook handler tries to do something bad like replacing the Parser
with a different one, this would not have an effect.
Removing the & does not remove the possibility to manipulate the
object. Changes done to public properties are still visible to the
caller.
Unfortunately these & cannot be removed from the callers as long as
there is a single callee expecting a reference. This patch reduces the
number of such problematic callees.
Change-Id: I21d53c989ea487607dc69e6b3365c023ef6729f5
Without this change it would no longer load in safe mode (T185303)
because the module would be missing.
I think this has been copy-pasted from VisualEditor, see commit
I6d097ccbf1dc2462843219adcf96bf8313e30289 there for explanation.
Bug: T185303
Change-Id: I6644a361d1450c394a7f82dc3dad97515982846d
Without this change it would no longer load in safe mode (T185303)
because the module would be missing.
I think this has been copy-pasted from VisualEditor, see commit
I6d097ccbf1dc2462843219adcf96bf8313e30289 there for explanation.
Bug: T185303
Change-Id: Ieed46488c94c5809e9f17f667c6926a21ffe838b
Insert required backslash to LaTeX commands.
This should help to avoid that users ommit the backslash for LaTeX commands unintentionally.
Change-Id: I970cec2cb597815cc4272ed573ac1a2ee2682e55
* currently the phpunit tests are not triggered by jenkins
* some test can't be re-enabled possible reasons:
** the texvc and texvccheck binaries are not available from jenkins
** the binaries can not be generated
** the path to the binaries are not set up correctly
Bug: T142120
Change-Id: I0c8fe5ad652c4663eeb029781521acbf56e42bad
The following sniffs now pass and were enabled:
* MediaWiki.Commenting.FunctionComment.WrongStyle
* MediaWiki.Commenting.LicenseComment.InvalidLicenseTag
Depends-On: I4e9749d8058cd6e55c7a4818d01c9d10a9d62efc
Change-Id: Ic4fbcb9ca724e940c102ac6feee0740b583cb14e
A formatter like this is not supposed to check if the format is known
or not. The code calling these formatters can introduce new (sub) formats
any time. What a formatter like this should do then are two things:
* If it's some HTML format, always return HTML.
* If you really can't identify the format, do a sensible fallback.
This currently blocks introducing a new format in Wikibase.
Bug: T46727
Change-Id: I585069e8f2ba33ec657ca4d514c6d502fe0f5ba3
This is obviously copy-pasted from somwhere else. Note that this tag
only appears in these two files. No other file does have it. It's not
useful for anything this way.
Change-Id: I7e0dcf0594fb59b396b1fd26b13383d59227b3f9
Documenting protected members as protected members is not really helpful.
One can see this by looking at the code.
Same for documenting a variable named "$html…" as "HTML". This does not
add anything.
Change-Id: I72364b6857166d77b9c85aa884cd139dc163c6bb
The @file tag is helpful when a block of documentation does not refer
to a class, but to a file. This is not the case here. These comments
can be normal class level comments.
Change-Id: I5ea1a1ecbe2dd681b91b793d4e45e7cd8dee529e
