@Tpt any idea what the syntax should be here. I have two ideas for the existing Css paramter:

Allow normal template styles somehow inject that directly if the CSS starts <templatestyles:

| Css = <templatestyles src="Index:Foo.djvu/styles.css"/> <templatestyles src="Global_styles.css"/>

Which imports Index:Foo.djvu/styles.css and Template:Global_styles.css

Direct lookup

| Css = /styles.css;Global_styles.css

Which imports the same CSS, but not via the TemplateStyles tag, but looks up the CSS itself (feature: "/" is relative to the index)

@Inductiveload I believe it should be better to use templatestyle because it does a lot of nice and useful CSS transformation and sanitization.

Using the <templatestyles> inside of the CSS field seems tricky because it means that this field is now able to contain actual CSS or <templatestyles> tags. I would be more in favor of the "direct lookup" option with a parameter named "templatestyle" or "style".

An other option would be to not have a parameter in the index page but automatically load "Index:CURRENT_INDEX/style.css" or something like that. It would still allow shared stylesheet between indexes if the /style.css page redirects to an other page.

@Tpt OK that makes sense.

I thought of the auto-loading, but I wasn't sure if that would rule out things like loading a shared CSS and a volume CSS (since I'm pretty sure there isn't an "import" in TemplateStyles). Not sure if that's a use case that is needed?

Not sure if that's a use case that is needed?

Me neither. There is already templatestyle for templates and Common.css for site wide CSS so I am not sure where it would be useful.

Here's a rudimentary patch for /style.css, if it exists.

Adding a field for additional styles could happen later if a serious need presented itself. You can also still include per-page styles directly with TS, or via a template.

Change 672760 had a related patch set uploaded (by Inductiveload; owner: Inductiveload):
[mediawiki/extensions/ProofreadPage@master] WIP: Default TemplateStyles for an Index

https://gerrit.wikimedia.org/r/672760

Change 672760 merged by jenkins-bot:
[mediawiki/extensions/ProofreadPage@master] Add default TemplateStyles for an Index

https://gerrit.wikimedia.org/r/672760

@Tpt ok, so what needs fixing here? What does your proposed patch at https://gerrit.wikimedia.org/r/674669 need?

@Inductiveload https://gerrit.wikimedia.org/r/672760 generated "null pointer exceptions" during Page: pages rendering if the page was not already connected to an index (trace in T278379). Antoine and I reverted the change to fix this error. It was the simplest way we found to fix this error quickly on Wikisource, sorry. I have started to write a change that should fix this problem: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/674691/1/includes/Page/PageContent.php
Feel free to integrate it into your change and push it again to gerrit.
Sorry again the quick revert.

@Tpt, is that fix complete or is there more that needs to be considered.

Also, it was mentioned that a failing test caught this. However, I have many failing tests in ProofreadPage anyway. Mostly seem to be to do with network access - is there a way to make these tests pass on a local machine?

@Tpt I'm also seeing a failure in the parser tests now:

 <div class="prp-pages-output" lang="en">
-<p><style data-mw-deduplicate="TemplateStyles:r11">.mw-parser-output *{color:red}</style><span>pg_num</span>TestTsCss p1&#32;<span>pg_num</span>TestTsCss p2&#32;
+<p><style data-mw-deduplicate="TemplateStyles:r155">.mw-parser-output *{color:red}</style><span>pg_num</span>TestTsCss p1&#32;<span>pg_num</span>TestTsCss p2&#32;
 </p>

Is there a way to indicate in a parser test that there's a "don't care" value?

@Tpt, is that fix complete or is there more that needs to be considered.

This fix is not complete, there is the problem caught by the failing test like you said.

However, I have many failing tests in ProofreadPage anyway. Mostly seem to be to do with network access - is there a way to make these tests pass on a local machine?

Yes, they should pass on a local machine (they pass on mine). What is the error you get? Have you properly configured DjVu support?

@Tpt The failures look something like this:

$ docker-compose exec mediawiki php tests/phpunit/phpunit.php extensions/ProofreadPage/tests/phpunit

7) ProofreadPage\Pagination\FilePaginationTest::testGetPageNumber
HTTP request blocked: https://commons.wikimedia.org/w/api.php?titles=File%3ALoremIpsum.djvu&iiprop=timestamp%7Cuser%7Ccomment%7Curl%7Csize%7Csha1%7Cmetadata%7Cmime%7Cmediatype%7Cextmetadata&prop=imageinfo&iimetadataversion=2&iiextmetadatamultilang=1&format=json&action=query&redirects=true&uselang=en by ForeignAPIRepo::httpGet. Use MockHttpTrait.

Nevermind, it's T268890, setting $wgUseInstantCommons = false fixed it. Rrrr!

Still need to figure out how to process the parser tests to:

• Set a content model
• Normalise data-mw-deduplicate="TemplateStyles:rXXX"

Change 675137 had a related patch set uploaded (by Inductiveload; author: Inductiveload):
[mediawiki/extensions/ProofreadPage@master] Add default TemplateStyles for an Index

https://gerrit.wikimedia.org/r/675137

Change 675137 merged by jenkins-bot:
[mediawiki/extensions/ProofreadPage@master] Add default TemplateStyles for an Index

https://gerrit.wikimedia.org/r/675137