When this code parses a string that looks like this:
*
** A
** B
It creates an option group with 2 options, but the name
of the group is an empty string. This makes the OOUI
DropdownInputWidget fail later.
Since the empty group name is useless anyway, drop it. This
makes the code behave as if the parsed string looked like
this:
* A
* B
Live example for the issue:
https://el.wikipedia.org/wiki/MediaWiki:Protect-dropdown
Bug: T275125
Change-Id: I780c1be27740b0ed3b35aa569b5a528112d7238f
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
assertSame() is guaranteed to never do any magic type conversion.
This can be critical when accidentially comparing empty strings (a
value PHP considers to be "falsy") to false, 0, 0.0, null, and such.
Change-Id: I2e2685c5992cae252f629a68ffe1a049f2e5ed1b
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
There is no need to escape double quotes in content of XML.
Html::element() also does not escape double quotes in content.
ENT_NOQUOTES escapes '<', '>' and '&' but not "'" and '"'.
https://secure.php.net/manual/en/function.htmlspecialchars.php
Change-Id: I3b585c43e532cca1a8951d6c9e8b4825fc3b012d
MWNamespace has three internal caches, only one of which can be cleared
(and that somewhat oddly by passing a boolean to
MWNamespace::getCanonicalNamespaces()).
This change introduces a MWNamespace::clearCaches() method to clear all
three caches. It also adds some resetting in tests that seemed to be
missing it.
Change-Id: I1dcfcd8713888b3ff8fc75e95329ba72bd95d0c9
Apparently that is intentional and documented. Huh. Whoops.
This reverts commit 0f1cc3bb6e.
Also add test cases for this bizarre function.
Change-Id: I0311f7c85cd575f2a66d50589ec364072be486fb
The same behavior was implemented by Xml::listDropDown(),
Article::confirmDelete() and HTMLFormField::getOptions().
A new function Xml::listDropDownOptions() is added and
all three are changed to use it.
Additionally:
* Xml::listDropDown() now uses XmlSelect internally to generate the
dropdown HTML.
* Xml::listDropDownOptionsOoui() is introduced to handle converting
the existing format to the OOUI format, which was previously
duplicated in Article::confirmDelete() and HTMLFormField::getOptionsOOUI().
* This change allows HTMLForm 'select' fields (HTMLSelectField) to
support nested options (optgroups) in OOUI mode. This is a
prerequisite for T117781.
Bug: T117781
Change-Id: I0a088f61eb32ec59677113583c7ecdcbc3fd2af0
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I46261416f7603558dceb76ebe695a5cac274e417
tl;dr: Having unnessary complexity in security critical code is bad.
* Extra options add extra complexity and maintenance burden
** Thus we should only have one html output mode. well formed = false
was already vetoed in T52040, so lets go with WellFormed=true.
* Options which are used by very few people tend to get tested less
* Escaping is an area of code where we should be very conservative
* Having escaping rules depend on making assumptions about which
characters various browsers consider "whitespace" is scary
* $wgWellFormedXml=false has had a negative security impact in the
past (Usually not directly its fault, but has made other bugs
more exploitable)
* Saving a couple bytes (even less bytes after gzip taken into
account) is really not worth it in this context (imho).
Change-Id: I5c922e0980d3f9eb39adb5bb5833e158afda42ed
It seems both of these tests assertions all expect
this to be false.
Ic675e92d8dd8f11fa67914d2ce1dc00a379106ca
ended up discovering these issues somehow
with these tests suddenly starting to fail.
Change-Id: I9d2d3c18d1c9640e2ff04d6fd4296abb86e26877
* Remove trailing space in self-closing tag.
Brings parserTest output of Parser and Parsoid closer together.
* Remove various line breaks at begin and end of script contents.
* Remove FILTER_NOMIN from makeConfigSetScript() output.
This isn't part of any user- or page-dependent module and not minified.
And Xml::encodeJsCall already ensures compact output for prod mode.
Bug: T127328
Change-Id: I85a5a59fd0955c1a112e8b24b933f0d9e983a156
* Modify Xml::monthSelector
* Tweak XmlTest.php to swap the order of some props (XmlSelect
output swaps the position of id and name props of <select>s)
Bug: T93234
Change-Id: If7e41251a6b2314e36dac8b7522c8e7b765f1814
We were always adding it previously, which seemed harmless since
'mediawiki.ui.input' RL module, providing the styling, was only loaded
if $wgUseMediaWikiUIEverywhere was true… unless someone loaded it
manually to have specific input fields styled. Whoops.
There are a lot more unconditional additions like this in tons of
places in the code, and someone should check whether each one is
intentional or not, but probably no one will. Oh well.
Bug: T92496
Change-Id: I5e91a3852a76ebbbfe64485bccb4c30ddee28b66
This provides better mobile experiences on various pages
and a more consistent UI across both mobile and desktop.
It does this in two ways.
1) Forces HTMLForms to not use table based layouts so as
not to interfere with responsive nature of mediawiki ui elements
2) Applies MediaWiki.UI classes to most pages
If a page is created via Xml or Html classes it will use mediawiki ui
Where possible I've added classes unconditionally, but for cases of buttons
this is behind the $wgUseMediaWikiUIEverywhere global since button styling is
enabled on pages by default and for checkboxes since it is changes HTML markup.
3) Adds all MediaWiki.UI styles to pages which can use it
When enabled:
* Apply these styles to all pages which use HTMLForms
* Apply to EditPage
* Apply to anything that uses certain elements outputted by the
Xml or HTML helper classes
* Apply to History page
* Apply to protection page
* Apply to move page
* Apply to deletion page
Currently kept behind a global to allow us time to finetune
existing elements. After further testing we will look to kill the
globals and make mediawiki.ui the default
See: I430c0fbb79d2a33bb828b2427bda0ee01115d73f
Change-Id: I47db5eab4569514d039261d11b6dedb0eeae17b5
* $wgHtml5 = false; is now ignored completely.
* $wgDocType and $wgDTD have been removed.
* $wgXhtmlDefaultNamespace is now ignored.
* XHTML5 will be output if $wgMimeType is set to an XML mime type (according to HTML5's rules).
* For backwards compatibility with extensions $wgHtml5 and $wgXhtmlDefaultNamespace are set
in Setup.php but depending on them is deprecated.
Change-Id: Iad9634e2ee420b5a3bbffe550421fde4fa1819b0
This commit depends on the introduction of
MediaWikiTestCase::setMwGlobals in change Iccf6ea81f4.
Various tests already set their globals, but forgot to restore
them afterwards, or forgot to call the parent setUp, tearDown...
Either way they won't have to anymore with setMwGlobals.
Consistent use of function characteristics:
* protected function setUp
* protected function tearDown
* public static function (provide..)
(Matching the function signature with PHPUnit/Framework/TestCase.php)
Replaces:
* public function (setUp|tearDown)\(
* protected function $1(
* \tfunction (setUp|tearDown)\(
* \tprotected function $1(
* \tfunction (data|provide)\(
* \tpublic static function $1\(
Also renamed a few "data#", "provider#" and "provides#" functions
to "provide#" for consistency. This also removes confusion where
the /media tests had a few private methods called dataFile(),
which were sometimes expected to be data providers.
Fixes:
TimestampTest often failed due to a previous test setting a
different language (it tests "1 hour ago" so need to make sure
it is set to English).
MWNamespaceTest became a lot cleaner now that it executes with
a known context. Though the now-redundant code that was removed
didn't work anyway because wgContentNamespaces isn't keyed by
namespace id, it had them was values...
FileBackendTest:
* Fixed: "PHP Fatal: Using $this when not in object context"
HttpTest
* Added comment about:
"PHP Fatal: Call to protected MWHttpRequest::__construct()"
(too much unrelated code to fix in this commit)
ExternalStoreTest
* Add an assertTrue as well, without it the test is useless
because regardless of whether wgExternalStores is true or false
it only uses it if it is an array.
Change-Id: I9d2b148e57bada64afeb7d5a99bec0e58f8e1561
The HTML and XML test now set the globals they depend on
(instead of relying on the default settings).
Tests for the "other" scenarios still exist, globals are
overridden inline. They are automatically restored after each
test## function by PHPUnit from MediaWikiTestCase::tearDown.
Also fixed 2 other problems with the test suite:
* HtmlTest::testDropDefaults forgot to pass
$message to the assertion from the provider ($case[3]).
* The data provider for HtmlTest::testDropDefaults was calling
Html::element directly (instead of calling it within the test)
which is problematic because data providers are expected to be
static. PHPUnit calls them outside the setUp/tearDown flow.
(also fixed the function to be public static, as PHPUnit
expects).
That last one was crucial to make the test still pass correctly.
Updated the expected strings to what they are with these
fixed non-leakage settings.
Took wgHtml5 without xmlform as default. And added tests
for variations where it made sense.
Change-Id: Iccf6ea81f4bc2639273ab2ad101c58788ee49d45
Improve Xml::languageSelector: add parameters to change label message and id/name of the select tag.
Use languageSelector in SpecialAllmessages (less code duplication)
Patchset 10 July: add tests per MaxSem; add version for new parameters and change the message parameter to require a Message object per Nikerabbit
Change-Id: I7fbb29ee2dc37a2b6a5e2cfc88207a0b47b83e9b
Since we're here: nothing uses $namespaceNames, $mNamespaceIds or $namespaceAliases
outside of this class (core or extensions) so lets make it protected.
* Previously it was passing $selectAttribs['name'] to Xml::label, which uses its value for the <label for=""> attribute. This works as long as $selectAttribs['id'] and $selectAttribs['name'] match, but when they don't it fails. <label for=""> always corresponds with <{input,text area,select} id=""> in browsers, never with "name".
* Make name/id match eachother by default to avoid backwards compatibility breakages (they used to match in the Xml class method as well)
* Add HtmlTest.php entries similar to the ones in XmlTest
* Fix E_NOTICE about $params['selected'], default to ''
-- Follows-up r109974, r109698, r109990
-- Bug originally introduced in r41425
-- XmlTest.php still runs successfully
-- HtmlTest.php runs successfully
