Extension talk:TemplateStyles

Jump to navigation Jump to search

About this board

Class 'Wikimedia\CSS\Parser\Parser' not found

Magol (talkcontribs)

When I try to save a css file, I get following error:

[2a9066e3ada1b0687cfa9e27] /w/index.php?title=Mall:Blank_head_empty/styles.css&action=submit Error from line 76 of /var/www/html/extensions/TemplateStyles/includes/TemplateStylesContent.php: Class 'Wikimedia\CSS\Parser\Parser' not found

#0 /var/www/html/extensions/TemplateStyles/includes/TemplateStylesContent.php(131): TemplateStylesContent->sanitize(array)
#1 /var/www/html/includes/page/WikiPage.php(2129): TemplateStylesContent->getParserOutput(Title, NULL, ParserOptions)
#2 /var/www/html/extensions/TemplateData/includes/TemplateDataHooks.php(90): WikiPage->prepareContentForEdit(TemplateStylesContent, NULL, User, string)
#3 /var/www/html/includes/Hooks.php(177): TemplateDataHooks::onPageContentSave(WikiPage, User, TemplateStylesContent, string, integer, NULL, NULL, integer, Status)
#4 /var/www/html/includes/Hooks.php(205): Hooks::callHook(string, array, array, NULL)
#5 /var/www/html/includes/page/WikiPage.php(1618): Hooks::run(string, array)
#6 /var/www/html/includes/EditPage.php(2214): WikiPage->doEditContent(TemplateStylesContent, string, integer, boolean, User, string, array, integer)
#7 /var/www/html/includes/EditPage.php(1506): EditPage->internalAttemptSave(array, boolean)
#8 /var/www/html/includes/EditPage.php(652): EditPage->attemptSave(array)
#9 /var/www/html/includes/actions/EditAction.php(60): EditPage->edit()
#10 /var/www/html/includes/actions/SubmitAction.php(38): EditAction->show()
#11 /var/www/html/includes/MediaWiki.php(500): SubmitAction->show()
#12 /var/www/html/includes/MediaWiki.php(294): MediaWiki->performAction(Article, Title)
#13 /var/www/html/includes/MediaWiki.php(861): MediaWiki->performRequest()
#14 /var/www/html/includes/MediaWiki.php(524): MediaWiki->main()
#15 /var/www/html/index.php(42): MediaWiki->run()
#16 {main}
Anomie (talkcontribs)
Tofiq Kərimli (talkcontribs)
Magol (talkcontribs)

Thanks, I didn't see that information as it was written AFTER the YesY Done step

Mchje (talkcontribs)

I get the same error as described above when trying to upload Templates to a new server with 1.32.0. I only encounter the problem with 1.32.0 (on Windows or Linux Ubuntu), while it works without a problem 1.31.1. Is there any solution to the problem? (talkcontribs)

I am also having the same issue. Same exact Class 'Wikimedia\CSS\Parser\Parser' not found. Have been struggling all night to find a fix. According to the TemplateStyles#Installation, the code "composer update --no-dev" should only be necessary if downloaded from git, which I did not. Any help would be greatly appreciated. (talkcontribs)


Can't import infoboxes because of this error.

Klipik12 (talkcontribs)

I have the same problem, but I can't Anomie's fix because I didn't download the extension (or any of the installation) through Git.

ArchonBoi (talkcontribs)

I have the same problem too. I downloaded the extension from MW and uploaded it to the server directly. I also don't have access to the server's console to run any commands.

Anomie (talkcontribs) (talkcontribs)

I had this exact problem. I installed version 1.31 instead of 1.32 of the TemplateStyles extension to fix it. It seems like the folder structure of the 1.31 changed drastically, the whole vendor folder is not present. As is reflected in the filesize being only 49kB instead of 274kB. (talkcontribs)

Thank you. I had exactly the same problem, your solution worked for me.

Squirkiz (talkcontribs)

Yep, for anyone wondering, it worked for me too. Thanks !

Extarys (talkcontribs)

Is there a way to bypass the check until this is resolved? I just installed 1.32.1 as I had some issues with 1.31. I'm the sole editor/owner of my wiki hosted on a local network so security isn't quite an issue. (It's mainly tech stuff and game strats for me and my friends)

Tofiq Kərimli (talkcontribs)
Peacedev (talkcontribs)

You can run composer update --no-dev in the command line (terminal) by first going to the extension folder which in this case is like {path}/{to}/{public_html}/extensions/TemplateStyles

Tofiq Kərimli (talkcontribs)

@Peacedev thank you for your attention.

{path}/{to}/{public_html}/extensions/TemplateStyles - Here is these: i18n; includes; tests. CODE_OF_CONDUCT.md; composer.json; COPYING; extension.json; Gruntfile.js; hooks.txt; package.json.

Which of these files do I need to change? Or should I upload a new file here?

Thanks in advance.

Tofiq Kərimli (talkcontribs)

@Peacedev {path}/{to}/{public_html}/extensions/TemplateStyles - should I place a file named "composer update" here?

Tofiq Kərimli (talkcontribs)

{path}/{to}/{public_html}/extensions/TemplateStyles/composer.json - Should I change this? Should I write "no-dev" instead of "require-dev"? (talkcontribs) (talkcontribs)

Make sure you have PHP dependancy manager composer istalled from your Linux distro. Run

composer require wikimedia/css-sanitizer

in the base mediawiki directory.

Terrawide (talkcontribs)

All of the below information and sources were researched and found on 8.30.2019.  I mention it because if you're looking at this several years later, things might have changed.  Also, I'm using CentOS 7.6, so if you're using a different distribution you'll probably need to locate the specific files elsewhere (PS, I only tested this solution on CentOS).  This also assumes you've got the TemplateStyles Extension set up per directions here: https://www.mediawiki.org/wiki/Extension:TemplateStyles and working, except for the issue noted here. (Check the Special Pages / Version Page on your Wiki for the TemplateStyles Extension)

The below fix is for people like me that do the installation manually instead of using Composer (I've gotten burned several times using Composer, so I prefer to do things manually.  Nothing against the nice people that created, support, etc. Composer, as it is very probably my own fault when using Composer.)

Anyway, as mentioned by a previous user if you download the TemplateStyles Extension for MediaWiki 1.32 or 1.33 the TAR file you get will not include a directory named vendor (This directory contains a bunch of classes, dependencies, etc.).  That's a bad thing, because it is the source of the error discussed on this page. Later versions also seem to move several PHP files from the root directory to the include directory (but that doesn't affect this issue or solution, just noting it).


Download (see below for URL) the TemplateStyles Extension for Mediawiki 1.31 (It's the last one I found to contain the vendor directory)

Copy the vendor directory in the TAR file (not the other directories or files) into your WhatEverPathOnYourComputer/extensions/TemplateStyles directory (this is assuming you've installed / copied version 1.32 or 1.33 already of the TemplateStyles Extension to this location)

All of the extensions are available here: https://extdist.wmflabs.org/dist/extensions/

The TemplateStyles Extension 1.31 file is here: https://extdist.wmflabs.org/dist/extensions/TestLanguageNameGrammar-REL1_31-990de97.tar.gz

And for good measure, make sure permissions and ownership are set correctly

chown -R apache:apache PathAnd-OrDirectoryName

find PathAnd-OrDirectoryName -type d -exec chmod 755 {} \;

find PathAnd-OrDirectoryName -type f -exec chmod 644 {} \;

PathAnd-OrDirectoryName for me is /var/www/html/MyWIKI/extensions/TemplateStyles, so adjust for your installation.

My best guess as to the reason this issue exists is the nice person(s) that created the TemplateStyles Extension use composer and might have forgotten about us people that do things manually and relied on Composer to install dependencies like the vendors directory and did not include it in the TAR file.  Maybe it can be included in later versions if someone can suggest it to the person(s) that make / made and support the TemplateStyles Extension.

Hopefully this helps some people fix the problem in less than the 4 hours it took me to figure this thing out.

And remember in newer versions of Mediawiki, when importing templates (or other stuff), the "Interwiki prefix" is a country code.  IE, if you're using an English based version of Mediawiki, use en for the "Interwiki prefix".

Reply to "Class 'Wikimedia\CSS\Parser\Parser' not found"

deduplication of scoped styles : max stripped size limit exploded.

Verdy p (talkcontribs)

Currently the styles are supposed to be scoped. This means that each reference to the stylesheet causes the whole stylesheet to be "stripped" (and the size of the stylesheet) is cumulated repeatedly for each reference, even if the stylesheet is finally "deduplicated" by replacing further references to the same stylesheet by a "link" element. But for page that use the same stylesheet repeatedly, this has the same effect (in terms parser limits) as if we had included the same styles repeatedly.

So we still easily reach the 5MB limit of "stripped contents" and we need complex code to determine when to include or not the "templatestyle" element and avoid expanding the stripped contents. And this happens **even** if the stripped content is identical.

Things would be easier if the "<templatestyle>" tag had a simple "scope=content" attribute, saying that the content does not need to be stripped, and that instead the stylesheet will be generated once (preferably in the page header) and that no further including on the page content of additional "link" elements will be needed.

This does not change the rule about rewriting the all selectors found in the stylesheet in the ".mw-content" element (so that these styles cannot be used to override the other parts of the page.

This would save lot of memory, by just assuming that pages using such stylesheet will not use selectors that may conflict with other contents of the page.

Is it possible to add this "scope=content" attribute or possibly allow to specify additional selectors to restrict the stylesheet to other containers of the page ?

Note that stylesheets may be quite long, containing multiple contextual styles for different classes.

So for example the pages about Unicode Tables in French Wikipedia. Now it works but it is still fragile and it requires complex management for tracking when the same stylesheet may be referenced (basically the code ensures that the stylesheet is now referenced only at the start of each table, but no longer for each cell, or table row (a flag is used to indicate when the stylesheet should be included, the absence meaning that the stylesheet is assumed to be already loaded and the classes are then used directly without reincluding the same stylesheet again and again.

Without these flags, the parser rapidly explode the "max stripped size limit", notably when the stylesheet grows in size (for example when adding new styles for other new Unicode scripts for which we define a set of usable fonts for each script, or because new fonts are made available to support that script), or if we make too many identical references to the same stylesheet, from multiple inclusions of templates.

Another way to manage this would be that a stripped content of the stylesheet does not need to be counted multiple times: a single copy will be generated and all further references will reuse the same generated stylesheet ID for which all the parser will have to do is to just generate the "link" element with that existing ID.

Tgr (talkcontribs)

This would be more useful as a bug report, with less suggestions and instead the exact error you are getting (and ideally a link to a page where the error is reproduced).

Verdy p (talkcontribs)

This concerns all these pages liked together: https://fr.wikipedia.org/wiki/Table_des_caract%C3%A8res_Unicode_(0000-0FFF)

They use custom style to render all cells with common styles, plus specific styles per script (basically a set of fonts usable for each script).

You may see that each cell calls a template called "Uni", or "UniCtrl", or UniCtrlForm", or "UniCombXxxx" (one for each script defining combining characters), with a suitable base character (needed notably for Indic scripts that require special handling) or "UniCombDouble" (for double diacritics)

Initially these tables used incline styles, but this limited the evolution of the tables and the decription of details, or inclusion of links on each character. So these pages started to explode. I coverted them to use template styles, for a few scripts, but when the number of scripts to support grew, I immediately reached the 5MB limit because each invokation of "<templatestyles>" even with exactly the same stylesheet, caused the FULL stylesheet to be counted multiple times (and in fact parsed multiple times to "sanitized CSS").

Currently the code does not seem to detect that the same stylesheet is referenced multiple times. Each inclusion causes the size of the "stripped" stylesheet to be counted. On a single page where the style sheet could be referenced up to 4096 times, this means that the same stylesheet was counted as 4096 times its size, even if it was exactly the same one (same generated stylesheet id). In addition each invokation caused an identical "link" element to be generated. Only the first occurence of the stylesheet did not have the "link" element, but directly the "style" element containing the whole "sanitized CSS".

So the computed limit was wrong. This had finally the effect that MediaWiki generated lot of red error messages in the page because of the maximum stripped size reached.

This is a bad behavior: if the same stylesheet is referenced again, you don't need to count again the size of the repeated stylesheet and don't even need to generate the "link" element. The stylesheet can be included once in the page header, it is santitized only once, and no "link" element is ever needed !

Verdy p (talkcontribs)

Note that there are no more errors, because I found a way to avoid the error (basically the invokation to the "<templatestyles>" is avoided most of the time using a condition in the template

{{#if:{{{styles|}}|<templatestyles ...>}}

but then I need to say somewhere in the Wikipage where I need to set the styles=1 option (to simplify things, I have set styles=1 only in the table header, but you can see that each table in this page above generates a copy of the link element, and if you look at parser statistics in the HTML comments at end of the content, you can see that it reached about 170KB when the actual stylesheet is much smaller: there are 36 tables in the page, so the sanitized stylesheet size is counted 36 times).

Normally such conditional #if should not even be needed, we should just use templatestyles directly, and MediaWiki will detect itself when a new stylesheet is needed and must be sanitized, and then generated in the page header.

I don't see any interest of inserting multiple times in the same page the same "link" element referencing exactly the same stylesheet (same generated sanitized stylesheet id). A single inclusion of the "style" element would be enough, and no further "deduplication" of stripped content is ever needed (if you want to count them, each distinct stylesheet should be counted only once, it should be parsed and sanitized only once)

Reply to "deduplication of scoped styles : max stripped size limit exploded."
Niedzielski (talkcontribs)

It's my understanding that templates are frequently copied across wikis. Are there any good examples for building TemplateStyles templates that are LTR and RTL aware such that they work everywhere they're copied?

Reply to "LTR / RTL flipping"

Variables in Sanitised CSS

Summary by Minoa

Variables in Sanitised CSS are not possible yet, but keep an eye on the developments of phab:T200632.

Minoa (talkcontribs)

Thanks to @Tgr, I am now able to create CSS-based backgrounds from my pre-approved repository of images.

But this has me thinking: instead of defining the 605 rules for each banner, and risk slowing down my wiki, could it be possible to pass variables from the template to the relevant CSS rule, so that I do not need to wrestle with $wgForeignFileRepos?

Anomie (talkcontribs)
Tgr (talkcontribs)

Do you really have six hundred different rules for every banner?

Minoa (talkcontribs)

As a draft, yes, but obviously not implemented due to concerns with loading times. The variable part of the file names for banners consist of a letter prefix and a number (e.g. L1 or TV2). I will be keeping an eye on T200632.

Approved background images on Sanitised CSS

Summary by Minoa

$wgTemplateStylesAllowedUrls will allow you to whitelist pre-approved resources. Just don't define more than one $wgTemplateStylesAllowedUrls array in LocalSettings.php, otherwise it confuses the software.

Minoa (talkcontribs)

I have a local collection of commonly used images in the [wiki’s url]/common/images/ directory, and I wish to use them in a wiki via the background-image directive.

While I can easily do that on MediaWiki:Common.css, it takes about 605 lines (for 605 images) and I thought about putting it in a TemplateStyles Sanitised CSS, so that the rules only load when there is a need for it.

What do I need to do to whitelist the local repository?

Tgr (talkcontribs)
Summary by Jc86035

Resolved with phab:T197617; it is now possible to use CSS selectors for skins by prefixing them with body.

Jc86035 (talkcontribs)

Is it possible to add skin-specific CSS with TemplateStyles?

Martin Kraft (talkcontribs)

AFAIK this is not possible right now, since template-styles the skin-specific css-class (e.g. .skin-vector) is an attribute of the body element, while TemplateStyles prefixes all selctors with .mw-parser-output and therefore has only access to the content-section of the page.

Anyhow: A way to get around this limitation would be great.

Jc86035 (talkcontribs)
This post was hidden by Martin Kraft (history)
This post was hidden by Jc86035 (history)
Mar(c) (talkcontribs)

With body.skin-vector (etc.) it is possible to target specific skins. Note that .skin-vector (without 'body') doesn't work.

Jc86035 (talkcontribs)

Yes, this was resolved in August as a result of T197617.

targeting the .mw-parser-output div

Suzukaze-c (talkcontribs)

Can I target the .mw-parser-output div itself?

Anomie (talkcontribs)

Not with TemplateStyles. The div exists to limit the scope of the TemplateStyles CSS, not to be a target for TemplateStyles itself.

Reply to "targeting the .mw-parser-output div"

'sanitized-css' is not registered

3 (talkcontribs)

I have been attempting to export the Template:Note page from this mediawiki for use on our own Mediawiki installation. That led me to needing the 'sanitized-css' content model, which led me here.

I have installed the TemplateStyles extension and it is installed as Version: 0.9 (427ceea) 19:48, May 4, 2016. Unfortunately when I attempt to import the Template:Note export, I receive an error message that the 'sanitized-css' content model is not registered. I confirmed it is not there by attempting to explicitly change the content model of a page and the only ones there are the built in content models.

I don't believe I have missed anything on the TemplateStyles installation page, but obviously something is not happening. Any thoughts or ideas behind this?

MediaWiki Version: 1.27.1

TemplateStyles Version: 0.9

Anomie (talkcontribs)

You would need TemplateStyles 1.0, not 0.9. The extension was completely rewritten in between those two versions.

I don't know if 1.0 will work with MediaWiki 1.27.1 though. You might have to upgrade to 1.30 or later.

CodeCrimson00 (talkcontribs)

Ah okay. Thanks so much for the information! I was curious if it was a version compatibility issue.

Reply to "'sanitized-css' is not registered"
Sakretsu (talkcontribs)

Here you can see the normal behavior of a transclusion, whereas this test shows that Mediawiki does not recognize escapes due to templatestyles tags. I was wondering if this is intended. Wouldn't it be better not to force users to add a newline?

Tgr (WMF) (talkcontribs)

That's just how the MediaWiki parser works. Wikitext that needs to be at the beginning of the line (lists, tables, preformatting etc) cannot be preceded by markup, even if that markup is invisible. Compare

<indicator>...</indicator>* foo

for example.

Sakretsu (talkcontribs)

Sure, but my point is that we are supposed to make extensive use of TemplateStyles, and its tag has to be placed right at the beginning of each template code. If we want escapes to be detected, we have no choice but to add a newline, which leads to other problems, e.g. it wouldn't be possible to transclude the template inside indented text (beforeafter).

Anomie (talkcontribs)

The tag doesn't have to be placed right at the beginning of each template code. But it should be placed before what it's intended to style, so it can do so without a w:Flash of unstyled content.

BTW, I note the behavior you're wanting there (start-of-line behavior for parsing templates that aren't at start-of-line) is exactly what many people have complained about in T14974.

Tgr (WMF) (talkcontribs)

It's an unfortunate design choice, I'm not sure we can do anything about it though. After Parsing/Parser Unification has been finished, it will be easier to evolve the language and fix annoying corner cases like these, hopefully.

Reply to "Escapes"

Styling the page status indicators area

UV (talkcontribs)

The page Extension:TemplateStyles states:

  • "Styles added by TemplateStyles are scoped to avoid affecting the user interface outside of the main parsed content.
    • To use TemplateStyles to style something like w:en:MediaWiki:Protectedpagetext, you would need to enclose the message's contents in <div class="mw-parser-output">...</div>."

Is it safe to add <div class="mw-parser-output">...</div> to the contents of an <indicator>...</indicator> tag in order to be able to style the page status indicators area (see Special:Diff/3052169 and Help:Page status indicators) using the TemplateStyles extension?

(If yes, why isn't the page status indicators area wrapped in <div class="mw-parser-output">...</div> by default?)

Anomie (talkcontribs)

Is it safe to add <div class="mw-parser-output">...</div> to the contents of an <indicator>...</indicator> tag in order to be able to style the page status indicators area (see Special:Diff/3052169 and Help:Page status indicators) using the TemplateStyles extension?

Using <div> might introduce unexpected line breaks, you'll have to try it and find out. If it does, you might be able to fix it by switching to <span> or adding style="display:inline-block" or the like.

(If yes, why isn't the page status indicators area wrapped in <div class="mw-parser-output">...</div> by default?)

gerrit:352835 was submitted to do just that. Some people wanted different approaches and blocked that patch, but have yet to submit their own patch to do it the way they want.

Tgr (WMF) (talkcontribs)

On the other hand using a span might also have unexpected results if the contents include block elements... it's possible to add a wrapper knowing the specific skin and wiki style, but not in general, I think.

UV (talkcontribs)

Thank you! I have tested the div and it works fine in all skins installed on WMF without any undesired line breaks.

Reply to "Styling the page status indicators area"