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
This makes the PHP parser behavior consistent with the specification at
https://www.mediawiki.org/wiki/Help:Images#Size_and_frame which says:
"An image with frame always ignores the size specification."
This is actually a fix to File::getUnscaledThumb() -- which didn't
actually return an unscaled thumb if the 'height' parameter was set.
Bug: 62258
Change-Id: I0ce295a4681042c446314945da5f811448b44fe6
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
- Added spaces after if/foreach/catch
- Added new line before end of file
- Added or removed spaces before/after parenthesis, comma
- Added spaces around string concat
Change-Id: I0590070f1b3542108e242730e8d9a3ba9831e94f
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 meaning of the php/parsoid options changed slightly with
change Ie4e68960ca7c352af495ebb59ba83488935a44c4. Update the
documentation comment at the top of the parser test file to match.
Change-Id: If0caac128704a15b824ccbcfbfb3f49812510f1d
The PHP parser now uses the first image format option that appears,
and ignores subsequent format options. This enforces the "zero or one"
language in
https://en.wikipedia.org/wiki/Wikipedia:Extended_image_syntax#Type
and makes parser behavior more predictable. This also matches Parsoid
behavior.
Change-Id: Ifa32238b3d274123c7b98022cf688c33edfd7197
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 patch allows `!!wikitext` (for `!!input`) and `!!html` (for
`!!result`). This is more in line with what those sections actually
contain and closer to the semantics of how they are used.
The old names are accepted as aliases to accomodate parser tests to
provide a migration path for extensions and other users of the
parser tests framework.
In addition to `!!html`, this patch also accepts `!!html/*` and the
more-specific `!!html/php`. This allows tests to include a number
of different "outputs" for a given wikitext input, for example
`!!html/parsoid` and `!!html/php`.
Co-authored-by: C. Scott Ananian <cscott@cscott.net>
Co-authored-by: Arlo Breault <abreault@wikimedia.org>
Change-Id: Ie4e68960ca7c352af495ebb59ba83488935a44c4
Replacing 'id' attribute with 'class' to prevent pages' HTML from
becoming invalid due to using the same id.
Change-Id: Ibf561318a5005424e8920e693a62ccdb05bbd765
The parserTests options handling had a regex capture bug which caused
it to discard all but the first and last option values. Fix this (by
separating value splitting from key/value capture).
Add support for JSON-valued options, which parsoid would like to begin
using. Add support for backslash escapes in quoted strings.
Change-Id: I69323bb44b7a481bad6f490d0773a984239c0b9c
The MagicWord raw was not matched against the whole given string, which
result in a raw output, when this was not intented.
Fixing this by adding a new regex, which matches the string from start
to end.
Bug: 56199
Change-Id: I7781c415bd61447dd91872575877dd21f36fae9f
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
The parser unnecessarily made individual checks for existence of
pages that were neither in LinkCache nor linked only with a fragment.
A Title::isKnown() call in Parser::replaceInternalLinks2() (added in
bca8b8ad7d) caused this.
Title::isKnown() was used to avoid treating a link to a distinct page
as a self-link even when the title happened to match one of the variants
returned by Language::autoConvertToAllVariants(). This change fixes
the bug by moving the problematic portion of the self-link check into
LinkHolderArray::doVariants().
Change-Id: I586e11e8b47308980ea04087ebc4246c397a8f53
Ensures that HTML list items are on their own line, which fixes a
CSS issue with .hlist; it depends on a breakable character between
list items, and a newline does provide one. Should also unburden
HTML Tidy, as output now matched that of Tidy.
Bug: 39617
Change-Id: I82fb4d749a200cfc049b30d2ee6e96a5ff7574e2
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
This is an old, old bug: the earliest filed dup is bug 1857, on 2005-04-10.
See bug 51086 for a modern discussion, and bug 52763 for some non-obvious
consequences: indented text inside a blockquote must not trigger
creation of a <pre> block (unlike <div>).
This patch should bring the PHP parser and Parsoid closer together.
This also fixes (or works around) bug 15491, which is really a bug in tidy.
But because <blockquote> content is typically wrapped with <p> tags now,
we don't trigger the tidy bug (see
https://bugzilla.wikimedia.org/show_bug.cgi?id=15491#c7 for details).
Credit to Aryeh Gregor (https://bugzilla.wikimedia.org/show_bug.cgi?id=6200#c8)
and Vitaliy Filippov (https://bugzilla.wikimedia.org/show_bug.cgi?id=6200#c37)
for almost-correct patches for this bug, which saved me a bunch of effort.
Thanks to Subramanya Sastry for pointing out bug 52763 and preventing a
bunch of broken articles on enwiki.
Bug: 6200
Bug: 15491
Bug: 52763
Change-Id: I3696d4ab7b8ad6ebccf8483d6da1722353c1697d
Disambiguation related functions have been re-implemented in the
Disambiguator extension.
Bug: 35981
Change-Id: I4afa30bf2677c6541ef355013f8eaef46abfbe03
Dependency: I41637ea43a9e5000bcb8a782441ce36f1068881f
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 test demonstrates a bug with image link, list item, and table cell
parsing when language converter markup is present.
The test is disabled until the bug is fixed.
Bug: 52661
Change-Id: I2da85ab6ba58639d6959f1abb41461c76b3bf177
This extension adds a "mode" parameter to the gallery
tag, allowing different formats for the gallery tag
(galleries in the ui can be controlled by a global)
The added modes are:
*traditional - The original gallery
*nolines - Like the original, no borders, less padding
*packed - All images aligned by having same height.
JS also justifies the images.
(I think this one is the one that will go over best
with users.)
*packed-overlay - like packed, but caption goes over
top the image in a transloucent box.
*packed-hover - like packed-overlay, but caption only
visible on hover. Degrades gracefully on screen
readers, and falls back to packed-overlay if
you are using a touch screen. I kind of like
this mode when the caption is not that important
(ex a category where its just the file name).
This also adds a hook to allow people to make their
own gallery version. I believe there would be interest
in this, as different people have done different
experiments. For example:
* Wikia: http://community.wikia.com/wiki/Help:Galleries,_Slideshows,_and_Sliders/wikitext
* Wikinews: https://en.wikinews.org/wiki/Template:Picture_select
What I would like to see for this patch, is first it gets
enabled, with the default still "traditional". After
about a month or two we consult with users. If feedback
is positive, we change the default mode to one of the
others (probably "packed").
Adds a "mode" parameter to gallery for different
mode, including one 'height-constrained-overlay'
which looks much more like other modern websites.
Note: This makes one change to the old gallery format.
It makes Nonexistent files be rendered like thumbnails
(i.e. they are rendered with a little grey border).
One thing I'm slightly worried about with this patch,
is that I added an option to MediaTransformOutput::toHtml
to override the width attribute. I'm not sure if that
is the best approach, and would appreciate thoughts
on that.
This should be merged at the same time as Ie82c1548
Change-Id: I33462a8b52502ed76aeb163b66e3704c8618ba23
