This support was added in https://gerrit.wikimedia.org/r/111390
but no parser tests were added at that time.
Bug: 32189
Change-Id: I299ce844919b3f20b3ce116adf64b37dd95325d0
Allow transparent tag hooks to be loaded during parser tests the way that
regular and function tag hooks can be.
Change-Id: I28ac9cc239628c248f72898d247fa1f6e2c308bd
When running parser tests on a sqlite3 database, the insertion of the
djvu image before running the test suite will fail because `NULL` is not
a valid value for the `bits` column of the `image` table. This will
cause the test suite to eventually fail, since {{NUMBEROFFILES}} differs.
Test uploads show that `bits` is usually set to 0 for both SVG and
DJVU uploads, so fix this (in both the standalone test runner and the
phpunit test runner).
Change-Id: I8689a547d34035534723e87c4c2680c4e67245f2
The tests currently depend on them never being renamed, which is bad.
(Actual file data in git is de-duplicated automatically AFAIK.)
Change-Id: Id2440326981218f9e7d51541a168db59183fdadf
Thumbnails for portrait-orientation images have always been "too big",
especially when displayed in a gallery. The 'upright' option did not
completely fix the issue. Using a square bounding box for thumbnails
(and 'framed' images) without an explicit size specifiction provides
a better default appearance.
This also provides a clean syntax for content authored using
Parsoid/Visual Editor, which prefers square bounding boxes.
See:
https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes
Bug: 63903
Change-Id: I665d8945843d3b5437a74e376b63c44965590116
This partially reverts r73950 which removed $wgServerName on the ground that it
was only used for {{SERVERNAME}}. When it was pointed out that $wgServerName was
also used by several extensions, the response was not to restore the variable, but
to proceed to remove it from extensions as well.
It is a useful variable to have, as the discussion on Id819246a9 makes clear
(see Tim's comment on PS12 and Timo's reply). So let's reintroduce it, and expose
it in mw.config and ApiQuerySiteInfo as well.
Change-Id: I40a6fd427d38c64c628f70a2f407b145443ea204
Support for DjVu is detected and parser tests that rely on it are disabled if needed.
Introduce DjVuSupport to easily detect DjVu support in unit tests
Change-Id: I53fd7b54e765d5f349abe74481bbc6f62f2b349e
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: Ic8aaf0a93796b97d0fa4617c1f86ff59f4b36131
The parser tests now include more generated thumbnails, so we need to
update the list of thumbnail files we clean up after a run.
Change-Id: Ibabab27ecb895a61f57fff265c8d6d3147666e0d
The mediawiki default thumb size is 180px. The Parsoid default thumb
size is 220px, to match the default thumb size for most WMF wikipedias
(see https://bugzilla.wikimedia.org/show_bug.cgi?id=43336).
This discrepancy leads to inconsistent image-related test output.
Allow a test to set an explicit default thumb size with the
'thumbsize' option so that it is possible to write consistent tests.
Change-Id: Ib764d1f1660a50caaf8f0ff245822d1d1a1d264e
The parserTest.inc file created metadata saying that Foobar.svg was
240x180px, but created an empty SVG file; the DEFAULT_WIDTH and
DEFAULT_HEIGHT in includes/media/SVGMetadataExtractor.php would have
caused this to be treated as a 512x512px image.
In NewParserTest.php, a 200x200px image was created for Foobar.svg.
That caused inconsistent and confusing results for SVG-related parser
tests, depending on which of the testing frameworks you used.
Fixed both of these to use a consistent 240x180px image, since
non-square images are better for checking correct scaling.
(Parsoid has always used a 240x180px size for Foobar.svg).
The non-square image has caused three parser test results to
slightly change.
Change-Id: Ib60a7412d9be808a0995e94d3aa373f2c5ca9bad
* This backend passes all filebackend and parser tests
* Fixed setupUploads() in parser tests to just use create() instead
of using store() and having a race condition in the process
* Fixed 'use-filebackend=' for Parser tests
bug: 58094
Change-Id: Ib0c38183cb7f9f2325da98c8a8a1eb2b8e39a7aa
Actually this messes with the implicit backend made for things like Math (when unconfigured), which uses the "new" operator.
This reverts commit 1f129a22cb.
Change-Id: I4c72c4f7c8b82e38df5496cf2b90fc9e19c40334
* Moved some of the graph construction work to FileBackendGroup.
This helps the code in not depending on the rest of MW so much.
* Updated tests and FileBackendMultiwrite, which are the only things
directly constructing FileBackend objects.
Change-Id: I188a053c70ce088ce34613d5db40e6708e3ea9b7
Currently, if an extension doesn't want a TOC, it has to remove it manually.
This change wraps the TOC in markers that make it easy to remove it in ParserOutput
on demand without fragmenting the parser cache with stuff like "use/not use TOC".
Change-Id: I2889bcb9eb999c9049601e92440132118e1a8a41
Change I36865e38 adjusted the parser test class to hook
InterwikiLoadPrefix, and prevent any other uses of that hook. Which is
ok, except it doesn't clean up after itself so it winds up breaking any
other parser tests that use the same hook.
Change-Id: I351a56ac39a44721d427e9c980eaf5fff246fb57
This allows us to test whether the parser properly respects the
$wgAllowExternalImages option.
I also renamed the 'rawhtml' option to wgRawHtml so that parser test
options which set wiki configuration variables have consistent names.
Bug: 51092
Change-Id: I6c453b3e366cf775d8eef2dcbde09fcfa7027125
The Math extension has at least one test marked with the parsertest
option 'texvc'. We now use it to detects whether $wgTexvc points to an
executable binary and would skip such parser tests if not.
'math' option is kept for backward compatibility, just in case.
Math extension has been updated to use this as of
https://gerrit.wikimedia.org/r/#/c/69873/
bug: 49884
Change-Id: I992b5a5b7aac067f1e368cb3eeba224c056b76f9
Some of our parser tests lookup interwikis. This was originally done
(parser/parserTest.inc) by inserting a set of interwikis in the database
and was later lamely copy pasted in the PHPUnit wrapped test suite
(phpunit/includes/parser/NewParserTest.php).
Since that time, we had duplicate code and had the test hitting the
database to fetch interwiki. Nowadays, we can trick the Interwiki
lookup class by using the InterwikiLoadPrefix hook, that let us skip
database lookup entirely (by having the hook returning false) and get
rid of the duplicate code.
The good old parserTests.php still pass the tests :-]
Change-Id: I36865e3890e08a05b8a6aaafa309a87556e235b9
See bug for context.
The implementation is slightly untidy because I've written it so
as to avoid invalidating the existing SVG thumbs -- there will be
no immediate difference (visual/performance/other) as a result of
this.
Tested by me in both...
* [[File:Example.svg|thumb|lang=fr]] AND
* http://example.org/w/index.php?title=File:Example.svg&lang=fr
...modes. Example file on
https://commons.wikimedia.org/wiki/File:Gerrit_patchset_25838_test.svg
Added parser tests.
Bug: 32987
Change-Id: I4cadf96ecd5e169a88ad468a0478d355db980103
Added spaces after/before parenthesis
Removed unneeded parenthesis around some statements
Broke a long line
Change-Id: I7fbe129f7bbf524dd0598ece2a9708643f08453b
* $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
- Don't set $wgMemc, $parserMemc and $messageMemc on each test,
the correct values for $wgMainCacheType and such are already set
in phpunit.php, so those objects are already the good ones
- Only destroy RepoGroup and FileBackendGroup once before starting
the tests instead of two
- No need to clear the MessageCache in addDBData(), it is already
destroyed in setupGlobals() (also avoids creating an object on
some tests to only call clear() on it)
- Group singleton cleanup after the test in tearDown()
Change-Id: Ib2d6522019160f63f3f968e69940413a1def2f8b
I eventually got tired of our parser tests creating and deleting fixture
files over and over. This patch mock the files in memory and just
expose the file metadata which is all we need for parser tests.
The mocked classes are under /tests/phpunit/mocks/ and respect the
hierarchy of /includes/.
The wiki.png and headbg.jpg files are still copied on each test :/
Change-Id: Iccdff67222e66d48d01dd1596d09df2ea24b8c2a
Because 1) `$wgStyleSheetPath = &$wgStylePath;` in default
settings, so setting one sets the other. No need to set both
and 2) in wmf-branches this variable is unset, thus this
caused an E_NOTICE internally when Test::setMwGlobals is
trying to access it to preserve the current value,
and 3) wgStyleSheetPath is deprecated.
Follows-up I1362932db223.
Change-Id: Ibd3f28e460fef995f68dfe1292d25fb75950dcf5
- Localisation cache does not depend on the database, only on the
localisation files themselves
- the backend is already set to LCStore_Null, so it will not interfere
with other caches (CDB, database, etc.)
Unloading the whole cache before each test thus only adds overhead
without any benefit, and slows down the test suite (this changes allows
to win about 20 seconds on my local machine).
Change-Id: Ifa36a7135d9f8355e1a10dd49ece806d90f657a2
- Move definitions of constant values from NewParserTest::setupGlobals()
to NewParserTest::setUp() so that the former only defines values
depending on the test
- Remove duplicate definitions
- Use setMwGlobals() to override the globals in NewParserTest::setUp()
- Change the overriding of $wgNamespaceProtection to use the normal
procedure instead of the "weirdglobal" thing
- Only define $wgUser, $wgOut and $wgRequest in NewParserTest::setupGlobals()
Change-Id: I1362932db2230455b23e469759ff3f9946da0392
The output for [[Image:Bad.jpg|thumb=Foobar.jpg|Title]] used to be:
<div class="thumb tright"><div class="thumbinner" style="width:1943px;"><a
href="/wiki/File:Foobar.jpg" class="image"><img alt=""
src="http://example.com/images/3/3a/Foobar.jpg" width="1941" height="220"
class="thumbimage" srcset="http://example.com/images/0/09/Bad.jpg 1.5x,
http://example.com/images/0/09/Bad.jpg 2x" /></a> <div
class="thumbcaption"><div class="magnify"><a href="/wiki/File:Bad.jpg"
class="internal" title="Enlarge"><img
src="/skins/common/images/magnify-clip.png" width="15" height="11" alt=""
/></a></div>Title</div></div></div>
Note that the target of the <a> is the thumb, not the original image,
and that the srcset is loading the full resolution version of Bad.jpg.
The attached patches fix the link target and srcset issues
(suppressing the srcset when a manual thumb is used). It also adds a
new "Thumb.png" pseudo-file to the parserTests so that we can write
new tests documenting how manual thumbnails are expected to work,
and adds the 'php' option to the thumbnail tests (since the Parsoid
parser generates different output).
Change-Id: I5be80bfce855b85f9debf3ef1776b877d1f84b9f
Rather than overload the 'disabled' option, explicitly mark Parsoid-only
parser tests with "parsoid" in the options field. These are disabled
by default when the PHP parser tests are run (but you could explicitly
enable them with --run-parsoid if you wished, in the same way that you
can enable other disabled tests with --run-disabled).
Document the 'php' option, which the PHP parser tests will ignore, but
will (in the future) be used to mark php-only tests which should be
ignored by the Parsoid parser.
Tweaked 'disabled' option to 'parsoid' for those tests which explicitly
call themselves parsoid-only. I was conservative in this patch; if
the title of the test didn't explicitly mention Parsoid, I left the
test disabled rather than switch it to parsoid.
Change-Id: Id6c396f7966fcb21c1e54e222ab0c9f4e3a34dcc
I don't know why Britney-Spears was in core parser tests as the example domain
name, but....well, suffice it to say she's not any more. We're using
example.org now, like sane people.
Change-Id: I47b53b94b4d7e8ad4a992de5e112685df48156c2
Our test classes often overload MediaWikiTestCase::setUp() but forget to
call their parent. This patch makes MediaWikiTestCase to flag whenever
its own setUp() is called and then simply assert it got called. Any
class failing the assertion is missing a call to its parent setup which
is easily fixed by adding: parent::setUp().
It would be nice to find a similar trick for tearDown().
Change-Id: Ia2afed6052eb3863d6c8e68c551cf03b33bb4be9
Removed $wgCleanupPresentationalAttributes, the associated
code it toggles and references to those in src and tests.
Also fixes bug 40329.
This was originally introduced in r94465 (released in REL1_19) but
disabled by default. Then enabled in r98053, after which several
bugs were filed and eventually the decision was made to remove
this feature.
Removed obsolete release-note entry, as this is to be backported
to REL1_20.
Change-Id: I4e86305520a3b22ef88381caab55d24abac932e3
Setting $wgContLang without changing $wgLanguageCode accordingly is a
very bad idea.
This caused about 20 exceptions when using LanguageCode set to 'fr'
on my installation:
"MWException: Error in MediaWikiLangTestCase::setUp(): $wgLanguageCode
('fr') is different from $wgContLang->getCode() (en)"
Follow-up of I2987db68 (2b0edc8).
Change-Id: I56d3f1bfc78d6a2e40460533524e82f360490206
* adds $wgResponsiveImages setting, defaulting to true, to enable the feature
* adds 'srcset' attribute with 1.5x and 2x URLs to image links and image thumbs
* adds jquery.hidpi plugin to check pixel density and implement partial 'srcset' polyfill
** $.devicePixelRatio() returns window.devicePixelRatio, with compat fallback for IE 10
** $().hidpi() performs a 'srcset' polyfill for browsers with no native 'srcset' support
* adds mediawiki.hidpi RL script to trigger hidpi loads after main images load
Note that this is a work in progress. There will be places where this doesn't yet work which output their imgs differently. If moving from a low to high-DPI screen on a MacBook Pro Retina display, you won't see images load until you reload.
Confirmed basic images and thumbs in wikitext appear to work in Safari 6, Chrome 21, Firefox 18 nightly on MacBook Pro Retina display, and IE 10 in Windows 8 at 150% zoom, 200% zoom, and 140% and 180%-ratio Metro tablet sizes.
Internally this is still a bit of a hack; Linker::makeImageLink and Linker::makeThumbLink explicitly ask for 1.5x and 2x scaled versions and insert their URLs, if different, into the original thumbnail object which (in default handler) outputs the srcset. This means that a number of places that handle images differently won't see the higher-resolution versions, such as <gallery> and the large thumbnail on the File: description page.
At some point we may wish to redo some of how the MediaHandler stuff works so that requesting a single thumbnail automatically produces the extra sizes in all circumstances. We might also consider outputting a 'srcset' or multiple src sizes in 'imageinfo' API requests, which would make ApiForeignRepo/InstantCommons more efficient. (Currently it has to make three requests for each image to get the three sizes.)
Change-Id: Id80ebd07a1a9f401a2c2bfeb21aae987e5aa863b
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
