Previously, a manually constructed autocomment in the form of
/* [[Some link]] */
would create a link to the the section, and then the "Some link" page.
After T165189 was implemented, the entire autocomment is now a link to
the section, so we're creating links inside of a link...which is
problematic. In most contexts (history and watchlist particularly), the
section link is more important than the title in the section heading, so
that's what we'll favor here.
It's worth noting that this situation is a manually created edge case.
Even if the section heading is a wikilink, the edit summary will
autofill a section autocomment without the double brackets.
We'll now render the double brackets ([[...]]) and not link them. This
is what the user literally typed, and matches the existing practice of
rendering templates in section headings with their literal syntax. And
as a bonus, it's still possible for user scripts such as wikEdDiff to
turn the rendered double brackets into a real link if users want.
Bug: T165189
Change-Id: Ib10679edd76c72a60d7e1c89fc8454166e34c463
A follow-up to 0a8e16d7cf thanks to Anomie's code review.
The section title is now inside <span dir="auto"> and <span
class="autocomment">, as before. $wgLang->getDirMark() between the arrow
and the text was restored.
Given the comment
/* External links */ removed bogus entries
the HTML before 0a8e16d7cf looked like:
<a href="#External_links">→</a><span dir="auto"><span
class="autocomment">External links: </span> removed bogus entries</span>
after this change, it will look like:
<span dir="auto"><span class="autocomment"><a
href="#External_links">→External links</a>: </span> removed bogus
entries</span>
The issue of having links be inside other links will be addressed in a
separate patch.
Bug: T165189
Change-Id: I31d87a87ccaf50de58fdd0621c46133b2881b490
HTML doesn't allow certain semicolon-less HTML entities in attribute
values to avoid breaking legacy markup like:
<a href="http://example.com?foo¶m=bar">...</a>
(Note that the & in that URL is not properly entity-escaped as `&`.)
Unlike wikitext, HTML generally allows semicolon-less legacy entities
in text.
Our alt and link option processing shove text through
Sanitizer::stripAllTags, which does entity decoding including these
legacy semicolon-less entities. Wikitext doesn't allow semicolon-less
entities, so escape & characters where appropriate to protect alt/link
options and avoid breaking URLs.
This was a "regression" in how alt options were handled starting in
ddb4913f53 when we switched to using
Remex for Sanitizer::stripAllTags -- semicolon-less entities (previously
invalid in wikitext) were now being decoded when stripAllTags was
called on alt text. This change became a problem when
ad80f0bca2 sent link option text through
Sanitizer::stripAllTags (with the new semicolon-less entity decode)
instead of PHP's strip_tags (which, in addition to its other faults,
doesn't do entity decode at all). This suddenly started decoding
"non-wikitext" entities like `¶` inside URLs, breaking links.
Filed T210437 as a follow-up to consider changing the behavior
of Sanitizer::stripAllTags() globally to prevent it from decoding
semicolon-less entities for all callers.
Bug: T209236
Change-Id: I5925e110e335d83eafa9de935c4e06806322f4a9
Remex is pure PHP so there is no reason to use an external tidy any
more. Configuration variables and implementation classes were
deprecated in 1.32 or earlier. We've kept only $wgTidyConfig
which can be used for experimental features or debugging Remex.
Bug: T198214
Change-Id: I99d48f858d97b6e1d1e6cd76a42c960cc2c61f9f
Future parsers will not support the output generated with tidy disabled.
Parser tests using untidied output will also be deprecated (and
rewritten) in a follow-up patch.
No new release notes necessary since user-visible tidy configuration
was deprecated previously (in 1.32), and individual methods which had
disabled tidy during execution were individually release-noted as they
were updated.
Bug: T198214
Depends-On: I0f417f75a49dfea873e9a2f44d81796a48b9f428
Depends-On: If5c619cdd3e7f786687cfc2ca166074d9197ca11
Change-Id: I592e0e0dfef7d929f05c60ffe4d60e09725b39cc
For historical reasons, we used a complicated test to try to determine
if a test is "parsoid only" based on the presence of the string "parsoid"
in the parser test options clause. But really test clauses should be
marked up specifically as html/php or html/parsoid, we don't need to
play hacky games any more. Remove some unnecessary code and simplify
the test logic.
Change-Id: Ia331e7e12a75aa19aeb96601712f169f2aa75bf9
Previously, they were always displayed in defult language unless
forced explicitly in wikitext, e.g. [[File:Foo.svg|lang=ru]].
This change adds a feature flag that would enable always trying to
display in page language.
* If enabled, Parser will pass a new parameter - 'pagelang' - to
the media handler.
* SvgHandler uses page language when determining what language to
render the image in.
* 'pagelang' can always be overridden by 'lang'.
* If no translation in page language is available, the default
language (English) will be used for thumbnail URLs, to prevent
cluttering media storage and HTTP caches with useless copies.
Performance: this requires accessing image's metadata during parsing.
My testing indicates there were no code path where this wasn't the
case already, so no performance hit is expected, however we should
still keep an eye on page save performance.
Bug: T205040
Change-Id: I348840ef405e1370cc0c17d69051bce30153c9c0
Use Parser::stripAltText() consistently to handle link and alt options
in both Parser::makeImage() and Parser::renderImageGallery(). This
ensures that link option text can use <nowiki> to escape problematic
text so that (for example) the following works:
```
[[File:Foobar.jpg|link=<nowiki>a''b''c</nowiki>|alt=<nowiki>a''b''c</nowiki>]]
<gallery>
File:Foobar.jpg|link=<nowiki>a''b''c</nowiki>|alt=<nowiki>a''b''c</nowiki>
</gallery>
```
Previously the handling of the link option in
Parser::renderImageGallery() used a bespoke `strip_tags` invocation
which didn't replace <nowiki>s, and the handling of the link option in
Parser::makeImage() didn't strip tags at all, nor did it replace
<nowiki>s. For example, in Parser::makeImage() double quotes in
titles would be converted to embedded `<i>` tags before being passed
to Parser::parseLinkParameter(), with predictably poor results.
Tests added to confirm behavior of alt/link with HTML-escaped
entities and <nowiki>s exposed a bug in Remex: T207088. Tests
will fail on PHP 7.0 until that is fixed.
Bug: T206940
Depends-On: Ide67bba20f771868c0e119cb2874464dcf1d758a
Change-Id: Ife4c0edaa85e0cb294c5d4c1e31d5d7d828d9df4
Facilitate a gradual migration away from non-standard MediaWiki language
codes. This will ensure that (a) rules can be written with standard
BCP 47 codes, and (b) rules written with existing nonstandard codes will
continue to work once these are added to
LanguageCode::$deprecatedLanguageCodeMapping.
Change-Id: I3ba96faafaf40bd47fb5919621f7035f0431a698
When this was originally written, the plan was to read both the old and
new fields during the transition period, while stopping writes to them
midway through. It turns out that the WHERE conditions to do read-both
correctly are generally not handled well by the database and working
around that would require a lot of complicated code (see what's being
removed from ApiQueryUserContribs here, for example).
We can simplify things greatly by instead having it write both fields
during the transition period, reading from the old for the first part
and the new for the second part, as is being done for MCR.
Bug: T204669
Change-Id: I4764c1c7883dc1003cb12729455c8107319f70b1
Depends-On: I845f6ae462f2539ebd35cbb5f2ca8b5714e2c1fb
Depends-On: I88b31b977543fdbdf69f8c1158e77e448df94e11
Added spaces around .
Removed empty return statement which are not required
Removed return after phpunit markTestIncomplete,
which is throwing to exit the test, no need for a return
Change-Id: I2c80b965ee52ba09949e70ea9e7adfc58a1d89ce
Some tests implicitly assume that English is a language with no
defined variants, which makes those tests fail if $wgUsePigLatinVariant
is true.
Change-Id: Iac5257a2fcf914a58579f06e340e8a4533befefb
Static members of MagicWord have been removed.
Static methods are soft-deprecated and forward to the factory. They
will be hard-deprecated when all callers are removed from core.
MagicWord::clearCache() has been removed. Instead, call
resetServiceForTesting( 'MagicWordFactory' ) on your MediaWikiServices
object.
Change-Id: Ie061fe90f9b9eca0cbf7e8199d9ca325c464867a
Bug: T200247
* Re-enable parse on save as requested in T159014, instead hide
the feature behind an option.
* Add the MCR tables to the list of tables that need to be cloned. Fixes
unconditional exception.
* Fix some undefined member variables, remove assignment to unused
variable $this->databaseSetupDone.
Bug: T159014
Change-Id: I6be577ebcbadeb4e08079a82543d521fc2bb5948
We don't want to display the stylesheet as part of the TOC entry if
someone uses TemplateStyles in a heading.
Bug: T198618
Change-Id: I2f7316daaba0cce662b6a4702ab87322e6783655
This should give more intuitive hints in assistive technology,
identical (or similar) to the hints for the JavaScript-generated
button we had before 68527cf479.
See results of testing with Windows Narrator/VoiceOver: T195053#4428563.
Bug: T195053
Change-Id: I9358b29f56ac1e43e9c5ed00d30ce6ffdf903299
This is a clarification of what already happens in practice for lists
generated from wikitext syntax, since that parsing happens
simultaneously.
Parsoid, for its part, does list handling prior to paragraph wrapping,
so must make use of these definitions.
Further, this helps reduce paragraph wrapping in interstitial spacing of
lists from HTML syntax, as spec'd in the tests, though the possibility
isn't eliminated entirely.
The TOC generation code is altered to reduce the number of newlines
emitted in between list items, since those are now left intact.
Change-Id: I6888b6e8e6768b0737565b87924fefa5a06ebd18
The changes to the parserTests.txt highlight the differing opinions that
doBlockLevels and Remex had on whether these should be paragraph wrapped.
Since the only time they wouldn't have been was when found on a line
with other flow tags, this likely isn't a behaviour that was depended on
in practice. And, indeed, the task describes this as a bug.
A sampling of pages from an insource:/\<(ins|del)\>/ search on wiki bears
this out.
Bug: T17491
Change-Id: I311da777a63aa3c45013f2cfc090be35a022497e
Changes in the behavior:
* The toggle button generate no FOUC on loading.
* On keyboard navigation the toggle key is the space key and not the
return key.
* Animation on hide and show is missing. Maybe a new animation with CSS
can added.
* The state of the button is not saved in a cookie.
* Self-build TOCs can not get hidden.
Browser support:
* The new implementation does not need JavaScript and therefor it works
on browser with disabled JavaScript and on Grade C browser.
* The new implementation requires the CSS pseudo-class selector
:checked. Therefor IE8 and lower are not supported.
Risks:
* The new implementation needs additional HTML elements. These elements
also get cached and crawled. The elements have no content so they get
hopefully ignored by crawler.
* The new CSS code imitates some styles (link, focus). This must kept
up to date.
* Multiple TOCs on one page would generate the same id attribute.
This can avoided by appending a counter or better and easier a random
string to the id attribute.
Bug: T195053
Change-Id: I82db33d656b3795d7134a91d20ed9d93a3471086
