In addition to constructing a fake request using the data the caller
gave us, also pass through any other request variables that might have
been set. This is a bit of an evil hack, but it's the only thing we can
do to make random things like wpReviewEdit in FlaggedRevs work through
the API.
Change-Id: Idab5b524b0e3daae58ab4f26466c0f6d9d8d3044
We're currently working around a bug in an extension (bug 51643) by deviating
from lexicographical order in extension-list to ensure that one extension is
loaded before another. It'd be nice to be able to document that in the file
itself, but there is no convention for adding comments to the file;
mergeMessageFileList.php treats every line as a file name. We've previously
talked about including a comment header in the file as part of our reponse to
bug 50347.
This patch adds some minimal syntax-handling to mergeMessageFileList.php which
causes it to treat as a comment any substring starting with '#' and extending
to the end of the line. This change implements part of what aude projected for
Gerrit change 71056, but I don't see the harm in pushing ahead with it here.
Change-Id: I4b296aa69ad77ecb51f1a0e27ce6a698cf09732b
FlaggedRevs will have to use this to expose its edit notices to
VisualEditor.
Also add an $oldid parameter so edit notices can be generated based
on the revision ID being edited.
Change-Id: Ie44a01ebfa7002fa3a89f081e0f831442666ac03
Whenever the user scrolls beyond the natural offset (possibly
customised by the skin, e.g. in Vector it accounts for the
tabs and search bar, in Monobook it is relative to the content
area, etc.) we switch from absolute to fixed position.
Changed the 1em top/right padding to be actual padding instead
of part of the offset, as otherwise `window.scrollTop > offset.top`
would trigger too late and thus cause it to "jump" back about
13px (1em) whenever we switch (the scroll logic depends on the
floating-mode offset being 0).
Now it seemlessly switches between the two area modes.
Based on logic in VisualEditor for the sticky editor toolbar.
Using a class instead of an ID for the area element as otherwise
all selectors would require being like "#area.area-floating" to
work from the skin. This should've been the case from the
beginning (using IDs in CSS is almost always bad).
Falls back to absolute position in IE6, where 'fixed' is not
supported (and would use positon 'static' otherwise which would
be a problem).
Cleaned up useless 'null' value for $area variable.
Bug: 50870
Change-Id: Icb7cd68f48443c1770e3585c8567fea2ac16dad8
It already looks rather silly when querying for 'templatedata' prop
from the TemplateData extension (e.g. [1]), it will start looking much
worse once Ie66b0dd6 in TemplateData is merged (which makes it store
the props gzip-compressed).
Do not show very long (over 1 kB) or binary (containing a null byte)
values; instead display a helpful message and size.
Changing the display format slightly, it's now "Page: <propvalue-or-message>"
instead of "Page (<propvalue-or-message>)", because the helpful
messages themselves include parentheses.
[1] https://en.wikipedia.org/wiki/Special:PagesWithProp?propname=templatedata
Bug: 51888
Change-Id: Ib2db241a117b06faee2426c8ea9ae18eab499e08
ApiPageSet is calling $this->profileOut(), then calling a function that
calls $this->profileDBIn(). Move that function to after a new
$this->profileIn().
Also, add a unit test for this situation.
Bug: 51821
Change-Id: Ib4dbfb567faadcd5e3d7d058ca6bdf8b4c83f634
dir="ltr" was added to make block durations on Special:Log/block
readable for non-local admins, While removing it, I used a
solution to keep block duration on title readable for non-local
admins and making inner text readable for local users
Change-Id: I31aef50196319be7355ad14657e67ca23fc15e20
These functions existed to work around a bug (fixed in PHP 5.3) and
a missing feature (added in PHP 5.2) in older versions of PHP;
therefore, they are no longer necessary.
Change-Id: Ifebbe3d449fc57fd83f8350c28f467605c1a07b7
Previously it was displayed at the bottom and was rather hard to notice.
Also prefix the legend with "Legend:" to make the interface clearer.
Change-Id: I62f3dfb311ae648180363f36d60a5f400ea4f077
Some query pages are not useful for ApiQueryQueryPage, as they require
arguments that cannot be specified with that interface. Currently, the
list of such pages is in a private static variable in ApiQueryQueryPage;
this moves it to a global so extensions can add to the list.
Change-Id: Ieccd2e84803dc1de4e26cba85d6cdda13916647f
The docs comment says it returns an int but it often returned a string.
This led to casting this value into an integer in other parts of the
codebase and in extensions (grep MobileFrontend or Echo for EditCount).
Bug: 51633
Change-Id: I6fe5b26c24e674e8148c1fd278774b3fabe844c5
As pointed out in bug 48593 (patched by
813cedb0308da58f3a2a4dc8ebefe489bf3005bc), these style rules are
overwritten later in the file and ignored by browser.
This patch will remove them as they do not serve any purpose.
Bug: 51623
Change-Id: Ib8aed40238f53198f207d4e57d0ced54622ad9e2
MediaWiki uses a custom stylesheet for buttons in Vector skin. This
stylesheet, however, breaks the jQuery UI icon-only buttons by setting
their width to "auto". This patch will re-set the width to 2.2em for
single-icon buttons and to 3.4em for 2-icon buttons.
Bug: 48593
Change-Id: I650d0e211cb4a1ce47c3d2246a3f266316afbb54
Removing whitespace between buttons in jquery.ui.buttonset in vector skin.
jQuery UI Buttons are displayed inline-block. In case there is
whitespace between button nodes in the HTML source, the whitspace would
be also rendered. To avoid this, jQuery UI decided to put a negative
margin in place. However, this negative margin is not enough in Vector skin by
MediaWiki (see attached screenshots in bug 32687). By setting the margin
from -0.3em to -0.4em this issue will be addressed in all tested browsers.
Since the text and icons in the buttons have a padding around 1em, this
patch will not obscure text or icons in the buttons. The only downside
is the shadow that is multiplied below the button and thus darker. But
this was an issue before and it will be just more obvious after applying
this patch.
Bug: 32687
Change-Id: I2577fe0ed79f0704ff40c019ec824d8ba62c3bf1
