Commit graph

309 commits

Author SHA1 Message Date
Stephen Niedzielski 71672d60b3 Fix: search header attribute escaping
Broken in my previous commit, d6f4aaa. This causes attributes to be
doubly escaped. For example,
http://localhost:8181/wiki/Main_Page?uselang=he.

Change-Id: I9776a3c355081dc5fec7753edf256f55dfe6045b
2019-12-03 16:05:56 -07:00
Stephen Niedzielski d6f4aaa88e Hygiene: extract VectorTemplate inline HTML to SearchComponent Mustache file
Extract SearchComponent.mustache from VectorTemplate. The "search"
message is now escaped by the template parser. As is, htmlspecialchars()
for "wgScript".

A later patch will change each component renderer function as well as
renderNavigation() to return a string.

Change-Id: I3084b7e0ef73d320c85ee780c9eff13ecea92906
2019-11-20 16:41:05 -05:00
Isarra 411a015ec5 Move DataAfterContent outside of main content block
Bug: T226199
Change-Id: Ie04d8d2bb1d44ec8a1c03fcc6f807668bab0377c
2019-06-20 17:55:55 +00:00
Timo Tijhof d56792addb Fix <h1> to be present even if title is "0"
Regression from 74b9803d9a, caused by a bug in LightNCandy which
caused {{foo}} to render "0", and {{#foo}} to pass as true with "0", but then
in {{#foo}}<b>{{foo}}</b>{{/foo} render as empty string producing "<b></b>".
In other words, the conditional is passing and the inner block is executed,
but the placeholder is mistakenly converting "0" => null => "" (empty string),
causing the <h1> to render but without any text in it.

Work around this bug by simply removing the conditional. Several other skins
already don't have this conditional and it's unclear why or in what
situation MediaWiki would send OutputPage to SkinTemplate without a title.

I think it would make sense in such rare case to still have a consistent
layout for extensions and gadgets to interact with and not omit the H1
element, but render it with the value that OutputPage gave it, even if it
is the empty string.

Bug: T219864
Change-Id: I6e04b512d2fe2e949ff5385cb38ceebe392fb255
2019-04-02 19:47:38 +01:00
Michael Große 3669843c9f Fix invalid lang attribute on first heading
Bug: T219359
Change-Id: I0d6e036b65da024278fb492c6dfe44c79efb1e98
2019-03-28 11:54:40 +01:00
Jdlrobson 74b9803d9a Start extracting rendering from PHP into Mustache
This reverts commit 8d0377d926
now a conversation has happened.

Bug: T217172
Change-Id: Id51bbd4358bdcc1131c11e13d5548e9c0474e711
2019-03-05 13:22:24 +00:00
Isarra 8d0377d926 Revert "Start extracting rendering from PHP into Mustache"
This reverts commit a3ca2c3e16.

Reason for revert: This requires wider discussion before moving
forward, and a more complete implementation even once we do have
consensus.

No associated task exists on which to view or continue this
discussion: linked task briefly mentions Mustache in general as an
option as part of a much wider topic, but doesn't concern this
specifically.

Issues that should be discussed include:
* What the intent even is here: is this for one skin only? Is this
  the intended path forward for all of them? Depending on which, we
  have other issues: for the former case, that it is quite
  unhelpful in terms of maintenance and further development having
  more random code diversity out there, especially in this
  half-completed state; or if it is indeed intended for all of them,
  that an RfC is needed before anything is merged, as that is a very
  significant change.
* That using Mustache in MediaWiki does add (usually minor)
  performance overhead; we need to clearly establish in the task that
  this is indeed worth it here.

Change-Id: I0bafa55b554aa8a38553e20c75859ec5eec2c062
2019-01-28 16:49:48 +00:00
Timo Tijhof d306e07824 template: Avoid raw HTML parameter for jump link labels
Change-Id: I6c638118988b6fbea95697817edf8c59c0ef6a6b
2019-01-22 21:13:05 -08:00
Timo Tijhof a3ca2c3e16 Start extracting rendering from PHP into Mustache
Bug: T140664
Change-Id: I249fead8e1c7bc5dc295457bd46b05e7ed389414
2019-01-22 21:13:05 -08:00