To be honest I did use an AI to assist, if you want to throw out for that reason I will not object. However, I did review the draft, so that it was in accordance with what I was requesting.

See also:
[[Page:Chiushingura, or, The loyal league - a Japanese romance (IA gri 000033125008684090).pdf/254]]
[[Page:Chiushingura, or, The loyal league - a Japanese romance (IA gri 000033125008684090).pdf/255]]

This now at least fails with a proper error -

becuase I hadn't had need to use the endpoints mentioned, I had not (yet).

(Aside: to be fair the entire tool needs an overhaul at some point, or conversion to an inwiki gadget.)

On discord it was mentioned that https://github.com/inductiveload/paginator/blob/master/src/mw_utils.js#L39 was what might needed to be migrated to a more compliant version.

Some further errors this morning:

There is also the consideration, that via a user script, I can utilise the original scanned images from IA/HT (via IIIF like endpoints) on the Wikisource side, but this isn't necessarily transferabble to the OCR engine (because for obvious reasons it's currently limited to WMF domains). By changing proofread page/OCR to use standard sizes, the userscript concerned could also be tweaked to utilise 'standard' sizes, which makes it much easier on external IIIF providers.
(ASIDE : It would be nice to have a defined IIIF endpoint, for scans held on Commons as well, so that there is a "documented" API for requesting scan images as opposed to the only semi stable upload.wikimedia.org one.) .

I'll log any issues below..

These are IIIF endpoints, so they are used to request image media, or JSON manifest.

(Aside: Ideally , IA-upload should be re-evaluted at some point, the current version is relatively old, and thus might need hardening.)

@EMill-WMF - Would you be willing to consider asking for community input on how to sensibly implement IIIF access, consistent with the revised CSP goals?

Another question : Can the CSP limit the requestable media-types, or reject 'incorrect' types, given in a response?

Can I make a polite request here that if the 'endpoint' concerned whitelisted, some kind of media-type limitation is considered? (such as limiting it to JSON and relevant media types.) - I am checking to see if IA-Upload is still working.

The other hope here is that this would enable other tools like IA-upload to be updated to only use the IIIF endpoints, rather than arbitary ones :). .

Abandoned due to CSP changes

Abandoned due to CSP changes.

This appears to have cleared eventually.

I've been "advised" that the CSP changes were being considered in any event, the recent incident merely accelerated the timeline.

@Jdforrester-WMF : Thanks for grouping.

I am not closing this ticket, I am trying to work within what was 'deemed' a necessary tightening of the CSP, given recent incidents.

I have my suspicions that this is down to a non-standard thumbnail size being requested.

Please note, any whitelisting, MUST only be for the very specific URL forms noted in the documentation. It is not proposed that there be any general whitelisting for archive.org as a whole. ~~~~

This change to standardised size has also broken the "Preview Pagelist" functionality for editing Index: pagelists at English Wikisource (It was suggested the code used 1024px images, which aren't supported any more.) Perhaps someone with more technical skill is able to find which lines of code are responsible? ( It may only be a single parmater that needs changing. ) Gerrit for some reason doesn't let me view repositories right now, so I;m not able to look deeper myself. ) The searches above also don't list external scripts/tools ( like those hosted on toll forge which will also need to be migrated, and in some cases usurped as the original maintainers no longer seem to be active).

Thanks for merging: Placing the contents of the duplicate bug below as a specifc use case for recursive tags in extensions.
Feature summary (what you would like to be able to do and where):

Or depending on context

"display :table; margin:0 auto;" -

margin:0 auto;

respectively.

That was unexpected. And this assumes the V2 API stays active: -
https://iiif.archive.org/iiif/documentation

I think, but as Inductive load is absent it would need someone to take over the toolforge side of the tool, something I can't do as I wouldn't qualify for dev access.

This is what the authors of spectral.js had to say:-
https://github.com/rvanwijnen/spectral.js/issues/20#issuecomment-2936400683

<center> can be implemented as a 'text-align:center" in CSS on an enclosing DIV, or a CSS class, which is the approach taken on a number of wikis.

Not reproducible , so closing as invalid.

Hmm. Intermittent, It didn't reproduce for me, when I re-examined. Checked the edits and found what appeared to be an unbroken list element. Therefore I am wondering if a 'list' item expansion size limit was hit.

Additionally , The edit page could give PROMINENT warnings about pages with deperecated HTML, "Do you really want to save this page?" ..etc..

Do you have a full list of properties that would need to 'discretised' ? If you have regexp for a potential linter style filter , even better :).

I'm not sure as to the viablity of that, given that there are perhaps many templates on Wikisource that presume the current behaviour.

It's not just the "-" use case, as there are plenty of other duplicates like "img" "plate" that are used in pagelists..

The most recent example of doLevels weirdness...

The idea is that rather than storing massive 1 GB scans on Commons, a mid quality 'readable' PDF/Djvu (of small file size- typically not more than 200MB ) could be for archival purposes, along with an IIIF path through which other projects (especially Wikisource) could obtain higher quality images for transcription purposes. Currently the script I use on English Wikisource (implented in https://en.wikisource.org/wiki/User:Inductiveload/jump_to_file if you wanted to review one approach used) , does something like the above but currently uses a file URL (or IA identfier over a direct IIIF resource path) and at present seems to use a tool-forge(?) hosted script to work out some of what to retrieve. Being able to have the same functionality as a drop in Gadget that could be more widely used would be advantageous for a number of projects. As would being able to give a suitable IIIF path directly so that an archive not currently supported by the current script could be added with minimal changes to the underlying gadget.

Seeing recoveries... No objection to merge on closed bugs.

Can confirm recovery occuring at English Wikisoruce on files mentioned previously, eslewhere.