Use the existing class mw-changeslist-links to visually separate
the user tools in CSS rather than in the HTML.
Bug: T205581
Change-Id: I024c8298ca5da753d96ec392be05d4530bb3ffa9
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
Per T205581#4768548 cached HTML might render a comment with
double brackets in the text. The CSS selector should not apply
there so a new class is used.
Using a BEM convention for the time being. This class can be
removed in future if needed.
Bug: T205581
Change-Id: If1552d6ddd4729b8beca45a1ca19ec6ce36e6118
From now on, the edit summary in ContribsPager results
will be wrapped in brackets via CSS pseudo elements.
Changes:
* Linker::revComment and Linker::commentBlock now accept a parameter which
can be used to disable wrapping in the text
* ContribsPager makes use of it
Bug: T205581
Change-Id: I60403a4a23d89107b7a28f0c12326d828a76614e
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
It's not entirely clear from the documentation whether this method
returns wikitext or HTML, so make it explicit.
Change-Id: I094e370e921c43dd8c5dc4376b3dddd803665d90
Try to paste and preview this in the wikitext as well as the summary
line: [[:a]] [[ :a]]
The wikitext will show "a a", but the summary line will show "a :a".
This is only a display issue, all 4 links correctly link to the
article [[A]].
Change-Id: I08253a6d0b55b9aa3eace519bbdc1a456400bf84
This talks about references and values the way they worked in PHP 4.
Comment was added in r4927 (b025ad54) in 2004.
Change-Id: I58a74219665bed9e804d7c01f271fd96fd889072
This prevents some double escaped warnings. Requires
I2f4e33656b9f94 to be effective. Follow up faf2e14517.
Change-Id: I255c96592f3baff2df34e07c81510c8874908e28
Bug: T202797
The alignment parameter is totally safe (See the very convoluted
code in the parser) but its best practise to escape things right
before the output. Additionally this protects in case any extension
uses a hook to do anything silly.
Change-Id: Ie19b106409d55c704b69280e2d0e2bb29068bd2e
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
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
This allows extensions to essentially reimplement Linker#makeImageLink
completely. Before this wasn't 100% possible as these three are needed for
that.
Inspired by wikiHow's core hacks to /includes/Linker.php, which can now be
moved to an ImageBeforeProduceHTML hook subscriber. wikiHow uses those
changes together with the WikihowArticle extension to heavily modify the
article DOM for various extensions and the default skin.
Change-Id: I8b5ab42d9cf021d66b90d15be68a0239643c10e3
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
This makes things centralized to reduce maintenance cost and also
enables me to use this methods in Wikibase to handle RC injection
Bug: T185034
Change-Id: Ic8c602e316144ccb5b05c69a0cc607cd53e38912
These comments do not add anything. I argue they are worse than having
no comments, because I have to read them first to understand they
actually don't explain anything. Removing them makes room for actual
improvements in the future (if needed).
Change-Id: Iee70aad681b3385e9af282d5581c10addbb91ac4
And changed a little bit signature of Linker::titleAttrib
and Linker::tooltipAndAcceskeyAttribs. Added $options
parameter to the second one and made $options parameter
satisfied by passing an array with options, because there
is one more now: 'nonexisting' which tells to add text
about the thing that the page does not exist to its tooltip.
Bug: T19099
Change-Id: Ia76dd6db363f6add5efb8955be9e23a1f8e8476f
I can see that "parent::__construct" literally calls the parent
constructor. I can see that stuff preceeded by the keyword "protected"
is protected. I really (really) don't need comments explaining such.
Change-Id: I7458e714976a6acd3ba6a7c93fdc27d03903df83
The toctitle is in user interface language. This change add the
HTML attributes lang and dir to the toctitle.
This allows to copy (a part of) the rendered HTML to a word processing
and the language for spell checking has the right language.
Change-Id: I17730869f81744560672d7d0acb67ced71e69c4e
Importing revisions in MediaWiki has long been weird: if the username on
the imported revision exists locally it's automatically attributed to
the local user, while if the name does not exist locally we wind up with
revision table rows with rev_user = 0 and rev_user_text being a valid
name that someone might later create. "Global" blocks too create rows
with ipb_by = 0 an ipb_by_text being a valid name.
The upcoming actor table change, as things currently stand, would
regularize that a bit by automatically attributing those imported
revisions to the newly-created user. But that's not necessarily what we
actually want to happen. And it would certainly confuse CentralAuth's
attempt to detect its own global blocks.
Thus, this patch introduces "interwiki" usernames that aren't valid for
local use, of the format "iw>Example".[1] Linker will interpret these
names and generate an appropriate interwiki link in history pages and
the like, as if from wikitext like `[[iw:User:Example]]`.
Imports for non-existant local users (and optionally for existing local
users too) will credit the edit to such an interwiki name. There is also
a new hook, 'ImportHandleUnknownUser', to allow extension such as
CentralAuth to create local users as their edits are imported.
Block will no longer accept usable-but-nonexistent names for 'byText' or
->setBlocker(). CentralAuth's global blocks will be submitted with an
interwiki username (see Ieae5d24f9).
Wikis that have imported edits or CentralAuth global blocks should run
the new maintenance/cleanupUsersWithNoId.php maintenance script. This
isn't done by update.php because (1) it needs an interwiki prefix to use
and (2) the updater can't know whether to pass the `--assign` flag.
[1]: '>' was used instead of the more usual ':' because WMF wikis have
many existing usernames containing colons.
Bug: T9240
Bug: T20209
Bug: T111605
Change-Id: I5401941c06102e8faa813910519d55482dff36cb
Depends-On: Ieae5d24f9098c1977447c50a8d4e2cab58a24d9f
* in links (T103714)
* in indicators (T104196)
This change removes the automatic Sanitizer::decodeCharReferences from
Sanitizer::escapeId and Sanitizer::escapeIdInternal. Where decoding of
HTML entities are wanted an explicit call to
Sanitizer::decodeCharReferences is added.
Explicit decode HTML entities in non local autocomments. (T104311)
Bug: T103714
Bug: T104196
Bug: T104311
Change-Id: I88e8e2077e6f5eec2b232391f7818370894a62dc
