People accidentally (or sometimes intentionally) calling the
parser recursively has been a major source of bugs over the
years. I think its much better to fail suddenly, instead
of having unclear signs like UNIQ's all over the place.
Change-Id: I0e42aa69835c15a5df7aecb0dc5c3dec946bdf6a
We're currently on jQuery v1.8.3. jQuery v1.9 introduces breaking
changes. The jQuery Migrate plugin adds a compatibility layer
that brings back most removed or altered functionality.
It can also be loaded on an older version of jQuery to make use
of the plugins' accessor tracking that helps finding code
that makes use of the deprecated functionality prior to upgrading.
Code:
http://code.jquery.com/jquery-migrate-1.2.1.js
Info:
http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate-final-released/http://jquery.com/upgrade-guide/1.9/#jquery-migrate-pluginhttps://github.com/jquery/jquery-migrate/
> The plugin can be included with versions of jQuery as old as
> 1.6.4 to identify potential upgrade issues via its JQMIGRATE
> console warnings. However, the plugin is only required for
> version 1.9.0 or higher to restore deprecated and removed
> functionality.
Loading it alongside jquery.js should be harmless. However to
benefit performance, I'm only loading it in debug mode.
Plus, there's a small chance that it does actually change
functionality because of the way it is implemented. The plugin
always overloads the methods with compatibility versions, which
should effectively be a no-op on top of old version of jQuery
like ours (one that already has the old functionality), but it
feels too risky at this stage when our only intent is
instrumentation.
Bug: 44740
Change-Id: I468d6b45eae8368fac6af746bbb2ccb702f862ff
img_auth.php does not currently handle filepaths for transcoded videos
at all, and instead falls back attempting to open files out of the
public zone, which obviously fails as these files do not exist there.
Add a branch that handles transcoded containers in the same manner as
thumbs and thus allowing access to those files from private wiki.
Bug: 65007
Change-Id: I7182206ba09dd2466fc51aa1d51116dd13db980c
As Rillke has reported in
https://translatewiki.net/wiki/Thread:Support/About_MediaWiki:Showhidebots/en
the text for the check box was incorrect. It turned out to be a strange
re-use of messages. Replaced it with a proper message.
No re-uses in core. Remaining re-use outside of core has been taken care of
in I4458ab7f6e53
Change-Id: I48042d0e60ce213db3db123179d9658cdd013a8f
Strict Standards: Declaration of ForeignDBFile::delete() should be
compatible with that of LocalFile::delete()
Followed-Up: I60cab27e0708a818c77791cc89194b6dd726da0b
Change-Id: I11d32c0a529ec76978cde38c038b4984ca13e8ba
Remove dependency on 'mediawiki.page.startup' since this is no
longer needed (it was there to ensure mw.util.init, which used to
populate mw.util.tooltipAccessKeyRegexp, ran first).
Change-Id: Iceecc228bce676de84de35220fa4d217be0f0b75
Follows-up d7a40c8 which creates the mediawiki.toc module and
moved the tocToggle method from mediawiki.util.
The tocToggle callback used to be a public method and therefore
had two things about that that are obsolete:
* Taking the toggle as parameter.
This is a private method now, and we already have a reference
to the toggle.
* Asserting that the #toc has an <ul>.
There is no need to defer this check this far in, nor to repeat
it on each click. The old code checked it earlier was well, but
we used to repeat the check here as the method was public.
Now that it is a private helper method we can simply return
early before setting it all up in the first place.
Also:
* Removed jsduck-like construction. This file is being indexed,
as part of src/mediawiki/, but turning this into a class seems
odd. It doesn't really have any structure to it.
It's just UI glue. Turned it into an ignored file (no doc blocks).
Change-Id: I21d4f735032b96f00291502e06d9d35a74648143
For browser testing, I need a reliable way to determine the branch in use
on a target wiki. One could parse the generator name forged when
querying the siteinfo, but that yields:
MediaWiki 1.24alpha instead of master
MediaWiki 1.24wmf2 instead of wmf/1.24wmf2
I am not really willing to reverse engineer the version to figure out
the branch, instead just expose it over the API.
Bug: 62509
Change-Id: If3db8f480ce0d590522741d40fb8e43b753efb41
Ensure that GitInfo::getHead returns a valid value before attempting to
use the git binary to extract a commit date.
Bug: 64948
Change-Id: Ib0d245306842706dbb5d4b9522bb381a5f55526c
Also removed isFunction check. This is an internal method and the
parameter is either a function or omitted/nulled. No need for aggressive
validation.
Change-Id: I6bbd82ca1b986b45a2f4653427396b9a6fceb6e8
* Document how to use it (including the tricky bit with it needing
a dependency on mediawiki.page.startup).
* Refer to mw.hook and #mw-content-text as recommended method of
getting just the wikipage content.
* Remove the deprecated backwards-compatibility selectors.
The core skins (Vector, Monobook, Modern, CologneBlue) all
have mw-body now. Third-party skins should adopt those if they
haven't already.
Change-Id: I30bdd893e0a0a340076efa7ce32fbd4b775bc3db
The .box-sizing() LESS function was moved in:
https://gerrit.wikimedia.org/r/#/c/127843/
And the usage in forms.less wasn't finding it anymore.
Change-Id: I7ae97bd5d4aa113af039182ff39817926bbbf3ed
This is an old remnant that was intended to remove outline from
images inside anchor links. However the watch star is no longer
implemented this way and this is doing nothing. Except when
the element is focussed (using keyboard tab index), then this
rule is overriding the default :focus and causing the user to
potentially get confused since it is no longer clear where the
focus has gone to.
Bug: 64934
Change-Id: I57ee089c1ae18bb7a6c55ae17eab3a06f9e1f7d2
Support reading git repository information from a JSON file in the cache
directory. When present, this file serves to provide information needed
by getHead, getHeadSHA1, getHeadCommitDate, getCurrentBranch and a new
getRemoteUrl method. A GitInfo::precomputeValues method is also provided
which can generate the cache file for a given GitInfo instance.
This support can be combined with a deployment step to reduce the need
to repeatedly gather information from the .git files/git binary. It also
allows computing information that can be lost when directory structures
differ between deployment staging hosts and hosts running MediaWiki.
This change also adds memoization of computed values for a given GitInfo
instance which may provide a small performance boost even for
deployments which are not using precomputed cache files.
Bug: 53972
Change-Id: I66e058acc5a71e5d82644f85d819f49d6ee9d1e6
