By default user option 'underline' is '2' which means no skin override.
Once a upon a time, none of the popular MediaWiki skins specified whether links should have
underlines, and most browsers default to having an underline on links (when not hovering).
As such, there was an exception added for languages where underlines cause text to be unreadable.
Nowadays however all modern skins explicitly specify the intended design for links.
Neither the default skin (Vector) nor other popular skins I checked have underlines by default.
As such, this rule is redundant.
If a skin comes along that does specify underlines by default, then these rules should be placed
in that skins' stylesheet. Not in the HTML of all pages.
Incidentally, this was the last code branch in ResourceLoaderUserCSSPrefsModule that is true by
default. Which means from now on this <style> tag is automatically omitted from the HTML for
logged-out users and users that haven't changed the 'underline' or 'editfont' preference.
Implement the missing isKnownEmpty() method so that OutputPage does the automatic omission.
To test the new text-decoration rule in mediawiki.skinning:
* Change user preference language to "ar" and observe anchor links in the interface
not having underlines on-hover.
* Change $wgLanguageCode to "ar" and observe anchor links in the content not having
underlines on-hover.
History:
* 2011 (043f98a3; r101445) Move overrides from shared.css to ResourceLoaderUserOptionsModule
Also remove "!important" from underline css
* 2011 (33293c9b; r96261) Apply "!important" to underline user option css
* 2011 (81446abc; r91432; T31712) Move overrides from MessageXX.php to skins/common/shared.css
* 2006 (43b2fb56; r15823) Move overrides from LanguageXX.php to MessageX.php
* 2004 (f9f3e915) Add override to LanguageAr.php
Bug: T105313
Change-Id: I94dda30fb80b30e9c12a74a8b09065da55681929
This greatly simplifies logic required to compute module versions.
It also makes it significantly less error-prone.
Since f37cee996e, we support hashes as versions (instead of timestamps).
This means we can build a hash of the content directly, instead of compiling a
large array with all values that may influence the module content somehow.
Benefits:
* Remove all methods and logic related to querying database and disk for
timestamps, revision numbers, definition summaries, cache epochs, and more.
* No longer needlessly invalidate cache as a result of no-op changes to
implementation datails. Due to inclusion of absolute file paths in the
definition summary, cache was always invalidated when moving wikis to newer
MediaWiki branches; even if the module observed no actual changes.
* When changes are reverted within a certain period of time, old caches can now
be re-used. The module would produce the same version hash as before.
Previously when a change was deployed and then reverted, all web clients (even
those that never saw the bad version) would have re-fetch modules because the
version increased.
Updated unit tests to account for the change in version. New default version of
empty test modules is: "mvgTPvXh". For the record, this comes from the base64
encoding of the SHA1 digest of the JSON serialised form of the module content:
> $str = '{"scripts":"","styles":{"css":[]},"messagesBlob":"{}"}';
> echo base64_encode(sha1($str, true));
> FEb3+VuiUm/fOMfod1bjw/te+AQ=
Enabled content versioning for the data modules in MediaWiki core:
* EditToolbarModule
* JqueryMsgModule
* LanguageDataModule
* LanguageNamesModule
* SpecialCharacterDataModule
* UserCSSPrefsModule
* UserDefaultsModule
* UserOptionsModule
The FileModule and base class explicitly disable it for now and keep their
current behaviour of using the definition summary. We may remove it later, but
that requires more performance testing first.
Explicitly disable it in the WikiModule class to avoid breakage when the
default changes.
Ref T98087.
Change-Id: I782df43c50dfcfb7d7592f744e13a3a0430b0dc6
Follows-up f37cee996e which replaced the getHashMtime() and
getDefinitionMtime() methods with dummies that always return 1.
These getModifiedTime() implementations were only tracking the
definition summary or custom hash, which is already tracked
by getVersionHash().
Notes:
* SpecialCharacterDataModule: This one was odd as it was tracking
both the mtime *and* the file contents.
* UserCSSPrefsModule/UserOptionsModule: Remove redundant caching.
Already taken care of by getVersionHash() as of f37cee996e.
Bug: T94074
Change-Id: I6e37c3c2f85ef4599a8643b0efabc18de2f51ec4
Introduces ResourceLoaderContext::getUserObj(), which gets
a (possibly cached) User object for the context's username.
Use this instead of the $wgUser global.
Change-Id: Ifd9f634db145381625ab68067ae67791a3f494b8
This reverts most of commit 2d842f1425,
leaving only the test added in it, and reimplements the same
functionality better.
Instead of stripping /*@noflip*/ annotations in CSSJanus, which is
incompatible with other implementations that preserve it, extend
CSSMin to allow other CSS comments to be present before the
rule-global @embed annotation. (This required making the regex logic
in it even worse than it was, but it's actually slightly less terrible
than I expected it would be. Good thing we have tests!)
Bug: 69698
Change-Id: I58603ef64f7d7cdc6461b34721a4d6b15f15ad79
To do it, just remove /*@noflip*/ annotations in CSSJanus after
we're done processing. They are not needed anymore and some obscure
interactions with CSSMin logic for preserving comments caused
`/*@noflip*/ /*@embed*/ background-image: url(…)` not to work
correctly (it would not be embedded).
This also requires us to always do CSSJanus processing, even when we
don't need flipping, to consistently handle the annotations.
I'm not entirely sure if this is worth it, but I still greatly prefer
doing it to documenting this stupid limitation. :)
Bug: 69698
Change-Id: I311b12b08b2dff9d45efb584db08cf4a11318f59
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.
Change-Id: Ifbb1da2a6278b0bde2a6f6ce2e7bd383ee3fb28a
Removed the option 'Justify paragraphs' from MW Preferences
as it is not a necessary option there.
Added RELEASE NOTES.
Bug: 52810
Change-Id: I1fe6a5857070828726077e6ba229b786c017c858
The table of contents box is auto-inserted, can trivially be hidden or
exposed on a per-page basis with __MAGICWORDS__, includes a sticky
[show|hide] link, and can be easily hidden with site-wide CSS as
necessary. It needlessly adds complexity and user interface clutter.
Bug: 52813
Change-Id: If2139317dae4aa980b373c73d7b81dac627b5af8
Unwanted user preference option in MW adding to the clutter.
Users interested in hiding section-edit links can use per-user
(or site-wide) CSS.
Removed 'editsection' from Defaultsettings.php and
ResourceLoaderUserCSSPrefsModule.php
Updated Release Notes
Bug: 52811
Change-Id: I5fc49106621943ca7180ddb37590b624edac67d5
Split the variable assignment and the return statement in two lines for
better readability.
When there was two return statements in one method the logic was swapped
to have only one return statement.
Change-Id: Id7a01b4a2df96036435f9e1a9be5678dd124b0af
There was a discussion [1] on this on Persian Wikipedia and users
don't want it actually. It is such an UI inconsistency and detecting
links based on their color is hard. It may have problem on Amiri font
but not on System default font and Persian Wikipedia fonts.
[1] https://fa.wikipedia.org/wiki/MediaWiki:Common.css?oldid=10552148
Change-Id: I8168baff1b9e64d0c79dcd7a896b9cbeeed0b266
This requires minor changes in various parts of MediaWiki, and
being extra careful about cached rendered pages' HTML.
Fun fact: editsection links are not made in Parser. They're made in
Linker, in Skin *and* in ParserOutput.
Client-side code and screen-scrapers will have to be adjusted to
handle both cases (old HTML will still be visible on cached page
renders until they are purged); extensions using the DoEditSectionLink
or EditSectionLink hooks might need adjustments as well.
* Linker: Change the HTML of pages to move the link itself from the
beginning of the heading (before <span class="mw-headline">) to the end
of the heading (after the span).
* Skin: Change the class from .editsection to .mw-editsection; we use this
opportunity to clean up old cruft, and this makes it much easier to
handle cached renders (by just detecting the old class).
* ParserOutput: Implement a horrible hack to support cached parser
outputs with the old order of items.
* Ensure everything that should support both classes supports both
classes (this includes print stylesheets and some scripts).
* Implement styles for the new look for all the skins (did this in
shared.css; the styles are non-intrusive and can be overridden
easily, and all of the skins were using the same look before).
Change-Id: I6a6c12a90de3604012420b20c1f520e0ece170ab
If the editfont preference somehow had a value like "foo; color: blue",
we have a CSS injection problem. Normally preference validation should
protect against that, but the API module for setting preferences doesn't
perform any validation.
Change-Id: I5c12aa9a48bf4f6ea4a8fb44554d13189e7757fb
* (bug 35317) CSRF in Special:Upload
Revert r56793, which removed the CSRF check for Special:Upload for normal file
uploads. Cross-site posting of file uploads without user interaction has been
possible since at least as early as Chrome 8 (late 2010) and Firefox 6 (mid
2011).
Commonist has used api.php since version 0.4.0 (April 2010), and the API
already requires an edit token, so Commonist 0.4.0+ is not affected by this
change.
* (bug 34907) Fix for CSRF vulnerability due to mw.user.tokens. Patch by Roan
Kattouw and Tim Starling.
* Filter out private modules early in ResourceLoader::makeResponse() and just
pretend they weren't specified. This means these modules cannot be loaded
through load.php . This filtering must not happen in makeModuleResponse(),
because that would break inlining.
* Force inlining of private modules in OutputPage::makeResourceLoaderLink(),
disregarding $wgResourceLoaderInlinePrivateModules
* Remove $wgResourceLoaderInlinePrivateModules
* Remove special treatment of private modules ($private) in
ResourceLoader::makeResponse() and sendResponseHeaders(), because we're not
allowing private modules to be loaded through here any more
* Remove identity checks in ResourceLoaderUserOptionsModule and
ResourceLoaderUserCSSPrefsModule, they didn't make a lot of sense before but
they're certainly useless now.
* Factored out error comment construction in ResourceLoader.php and stripped
comment terminations from exception messages. I didn't find an XSS
vulnerability but it looked scary.
Patchset2:
Removes whitespace error that prevented automatic merge by Gerrit:
includes/resourceloader/ResourceLoaderUserOptionsModule.php
Change-Id: I2dec8b8caf9db3c64919763865cc10cccdd6a1a3
