In T331138#8676812, @thcipriani wrote:

I checked maintainer's page on MediaWiki to find a good team tag and came up empty

In T331138#8675245, @Joe wrote:

Also: if pre-generation of thumbs makes sense (does it? do we have any numbers on this stuff?) …

Could we add to the checks for this epic:

At least one of these $parser->addTrackingCategory("lst-invalid-section-category"); calls is bogus. s:Category:Pages transcluding nonexistent sections is filling up with entries for pages that are quite correctly transcluding a named section. My guess is the last one, but I haven't traced it.

So... still no news?

In T200704#8440436, @Tgr wrote:

I guess one way to fix this is to just wait for parser unification.

In T324740#8453497, @Soda wrote:

I think we can use the pattern="/regex/" to bypass the default URL checking ?

In T324740#8453450, @Samwilson wrote:

There's still an issue (with Firefox at any rate) of the form field (which is of type url) not accepting protocol-relative URLs.

Checked on the web interface (ocr.wmclod) by manually adding "https:" to the URL and it worked fine, so it does indeed seem to be just a dumb regex match problem. Easy bugs are the bestest bugs! :-)

@Soda I think you're touching code related to this for other reasons, so you may want to be aware of this task. In addition to $prpImage being undefined, pages such as this also trigger an error notification from OSD that there's no image.

This is really annoying for the Wikisourcen since their formatting needs follow whatever the text they are reproducing used, rather than a project-specific manual of style. It is very common to have typical linkable phrases (names of authors, say) formatted with multiple styles (i.e. multiple formatting templates) such that the template(s) cannot be moved outside the link.

Transclusion with PRP does not show the page image, but rather the wikitext of the associated Page:-namespace page. Does this wikipage have any contents? And if so, what is it? If you check the mainspace page in your web browser’s Web Inspector, do you find a node with #prp-pages-output?

Ok, I can confirm that all the pages in the query results above are "naked" pages (not connected to a scan).

For sanity-checking you can use Phe-tools' statistics, where the "w/o scans" column for a given language Wikisource should show a number roughly the same as the (COUNT) number of results of your query. I can also probably dig up the exact query Phe's tool is using if interesting, but it'll be several years since it was tweaked (I think Phe went inactive around 2015/2016 or so).

Possibly related: T311901, T317992, T310648

Oh, indeed. Normal TableStyles are scoped to .mw-parser-output, but Index:-styles are scoped additionally to .prp-pages-output in mainspace and .pagetext in the Page: namespace. In Page: namespace the whole content (including header/footer) is contained within .pagetext and so it works fine. But in mainspace the rendered references are not mediated through Proofread Page (it uses Cite directly) and so are not contained within .prp-pages-output and the selectors cannot match.

In T296847#8361513, @Jdlrobson wrote:

… I'm not sure why gadget security would not fall into security team's purview, at least on the high level of where code can be loaded from..?

@Umherirrender: Thank you! Will this default to the main slot like other API calls, or will the slot need to always be specified explicitly?

@Candalua Do you have a page exhibiting this problem? And do you mean .prp-pages-output or .mw-parser-output (to which TemplateStyles are normally scoped)?

In T285173#7164334, @Tgr wrote:

… Still it seems like a lot of effort for something that can already be handled by normal template transclusion mechanics (use separate stylesheets and an intermediary template to group them together).

In T311901#8242486, @Soda wrote:

Given there weren't reports of duplicated scans for a bit, marking this as resolved. Feel free to re-open if I'm wrong :)

In T204201#7607036, @Jack_who_built_the_house wrote:

[…] Namespaces could be less urgent/relevant.

Gah. I'm religiously in favour of trimming away unneeded stuff in the UI (cf. T163098), but as I read the above comments I realise I rely on that behaviour too: for lots of pages I use the tab to get a "clean" (or just specific or predictable) version of the page, or a related page (i.e. talk vs. main vs. history etc.). And perhaps key here, not just on special pages. That is, if just special pages change (no tab but grow a reset button in the page-specific UI) I can't just retrain muscle memory, it'll end up being a constant impedance.

Note that only the following are documented targets of mw.util.addPortletLink():

In T311647#8093099, @Tgr wrote:

• A lot of gadgets add menu items (which are essentially launch buttons) to the sidebar, but it might have sense to have a dedicated gadgets menu (consider e.g. the plugins dropdown menu in Chrome).

The "Source" tab is a proper peer to "Page" and "Discussion" on Proofread page-based wikis (like the Wikisourcen), so mw.util.addPortletLink() is not an appropriate fix for this problem.

@He7d3r Is this task still relevant? It seems to refer to a specific bug in a specific on-wiki/community maintained script on mulWS (possibly cross-loaded on ptWS, but not on e.g. enWS where Easy LST is a local Gadget),and one that has either been fixed or mooted by subsequent changes. Perhaps this task can be closed as (now) Invalid?

@Nemo_bis @Samwilson @8ohit.dua If BUB is dead can't this task be closed as Invalid? Or did it get resurrected somewhere and where this task is still relevant?

In T71445#6496321, @DannyS712 wrote:

Quick idea version 2 for an extension + workflow

Ok, since the Vue.js decision announcement I've been looking for some kind of status or guidance or roadmap for client-side UI for Gadget and User script developers. That used to be jQuery UI, but upstream put that in maintenance-only mode in 2018 and it was deprecated in MW 1.29. The new hotness was OOUI, but it was never very suitable for this use case and realistically now will never be. Where the puck is going is, from all appearances, Codex; but try as I might I can't find more than incidental mentions of User scripts and Gadgets as a use case (and mostly in the "select a framework" Phab task). There's all of one open task on the Codex workboard (T311099) related to this, and that's just the icons.

@egardner wrote:

• Archive, delete, or prune old Vue Migration Team pages as necessary (may need help from someone with admin privileges to delete pages).

Absent further comments let me be a bit more direct: looking at T304303 I see no upside that to me justifies breaking this long-standing and core end-user-visible functionality. Page-spanning constructs (e.g. tables, like the tables of contents in just about every book) are now literally impossible to work with when live previews are on, and it is in practice impossible for a user (even experienced users) to tell what's going on or how to work around it. IMO, if this cannot be fixed some other way relatively soon the triggering change will have to be rolled back.

In T312513#8061249, @Aklapper wrote:

Is there a way or is it even planned to remove the old non-working OCR buttons from the toolbar?

https://de.wikisource.org/wiki/Spezial:Einstellungen#mw-prefsection-gadgets lists an item "OCR Buttons deaktivieren". Per https://de.wikisource.org/wiki/MediaWiki:Gadgets-definition its code is at https://de.wikisource.org/wiki/MediaWiki:Gadget-PR-ocr.js . That one line of code implies that it comes from ProofreadPage maybe? I guess that something (ProofreadPage?) loads https://wikisource.org/w/index.php?title=MediaWiki:OCR.js which loads phetools.

In T312513#8060564, @Samwilson wrote:

Those two buttons use the phetools OCR system, which is no longer maintained.

In T309490#8051246, @Soda wrote:

… For the Page: namespace, prpIndexTitle is the variable you want to use to get the Index: page …

This bug affects not just the proofread status, which is more cosmetic than anything, but also all other uses of the header and footer, which is a lot more troublesome. Most obviously it means you can't preview any changes to the content in the header/footer (a running header, for example); but it also breaks the use of any page-spanning templates. For example, on enWS Template:TOCstyle generates a table and relies on having {{TOCstyle|header=yes}} in the header so that when invoked in the body with {{TOCstyle|continues=yes}} it can output only a markup fragment. Since the preview doesn't have the header the body ends up being parsed as generic unordered list markup. enWS has a number of templates that operate on this model. And without testing I imagine it also will affect any other page-spanning constructs such as basic table wikimarkup (multipage tables are common in all sorts of works).

In T309490#8050892, @Soda wrote:

I don't think this change will affect the Translation: namespace at all, since we filter only main namespace pages before we add these variables/information.

Ok, I've checked all usages on enWS (and noWS, incidentally) and apart from user scripts for inactive users, there is only one remaining instance. I've notified the user, but I suspect the script isn't actually in use currently (it hasn't been modified since 2011). In other words, enWS should be fine when the train rolls around tomorrow. But I'm still a little worried about the other projects.

Incidentally, this change seems to have some sort of bearing on T53980 (from 2013!), though I'm not sure of in what way yet (makes it easier? harder? fixes it as an incidental effect? makes on-wiki workarounds easier?).

In T309490#8040690, @Soda wrote:

This change removes the proofreadpage_source_href JS variable from mw.configand replaces it with a new variable prpSourceIndexPage.

@BBlack The last status update on this bug was ~18 months ago, and indicated the issue was an upstream bug and you were following up there, with a fallback to a WMF-specific patch if upstream got stuck. I see no indication there is any question this behaviour is a bug (cf. eg. Krinkle's comment above). It's also a problem that makes certain pages inaccessible on all projects, breaks contribution histories and other core features for certain users, and necessitates manually prohibiting a character in page and user names that is intended to be permitted.

Hmm. Then I think the problem statement is a little bit the wrong way around: it reads as if the aim is to lock down a currently reigning "Wild West" state of affairs, but in light of your clarification it sounds like the focus is more to enable a use of third-party resources that are difficult or impossible to (legally) do today but which would be of benefit to the Movement. And, obviously, when enabling such use it is desirable to do so in a controlled way that prioritises privacy, is sustainable, does not negatively impact performance, and so forth; but this then is not the focus so much as the consequence.

I'm confused by this problem statement. The Privacy Policy already forbids anything on Wikimedia projects that causes the UA to contact any third-party website, including Toolforge and WMCS, for any purpose (any HTTP header and the client IP are covered by the definition of "Personal information"). So regardless of whether it's executable code, an image, a webfont, JSON/JSONP data, etc. it is currently bright-line forbidden. What, then, would this "clear Wikimedia policy on the use of third-party resources" cover?

In T277267#7737079, @DorianWinty wrote:

is it possible to have the link of the page please ?

In T277267#7735738, @Dereckson wrote:

in addition each label is now inline rather than block

That was already the case before, but there were hidden 0 to fill the space you highlighted as empty.

In T277267#7735901, @DorianWinty wrote:

what do you prefer ?

The layout changes for the pagelist in this task are kinda suboptimal. There seems to be significantly increased margins around each page label, and in addition each label is now inline rather than block so the containers (on which the background is applied) collapse down to essentially just the character boxes. See the before—after screenshots below:

Dollars to dimes they're just scraping works for some ebook site based on the OPML.

In T299124#7625200, @Ladsgroup wrote:

Then it can make a request to the thumbnail instead of the page. I think this at least reduces the pressure on the appservers.

It is probably worth revisiting, yes, but note that interactive performance here depends on dynamically generated "thumbnail" images, where the generation involves shelling out to ghostscript (for PDFs) and ddjvu (for DjVu) to extract a given page from a possibly ~1GB multi-page document and rendering it to a JPEG. Ghostscript, in particular, can (anecdotally) take ~20 seconds to do this.

Last I heard (I could be wrong), MediaWiki-extensions-PdfHandler (ping @Tgr) uses Ghostscript to render PDFs to JPEG thumbnails, meaning this is most likely an upstream bug affecting certain born-digital PDFs. Best case for fixing it is probably using a newer version of ghostscript, which I'm guessing would be blocked on T289228. If it can be reproduced in base latest-version ghostscript it should probably reported upstream, and a fix here would then also depend on when upstream makes a release with a fix. Alternately, there is T38594; but I suspect it'd be fairly resource-intensive on the MediaWiki side, and I have no idea what the relative merits of Ghostscript and MuPDF are. A switch might conceivably have a positive effect on the problem described in T242169 (or it might not; or it might make it worse).

The user that first reported this issue on enWS has tested and confirmed that it is now fixed for them. And my own testing concurs.

Crap, I notice we don't have any regular backport windows until Monday. While this wasn't train-blocking/rollback when noticed, it's probably UBL-y enough that it needs to go out as an emergency backport. It doesn't break the primary workflow in that the Wikisourcen can still edit pages, it does break the zoom/pan for the reference page image (which is highly-used functionality) and partially breaks (blocks) the UI for setting page status (particularly for people with page zoom on in the browser, which is a major accessibility issue and primary workflow).

Updated patch looks good to me, but I'm not sufficiently familiar with the context there for that to mean much.

Patchdemo looks good to me: no console errors, all the OSD stuff (zoom, rotate, etc.) looks like it works, and it even seems to fix the unresponsive radio buttons that were reported on-wiki.

In T298694#7601710, @Zabe wrote:

How big is the impact? Should this be a train blocker?

Ah, oh, yes, I see. When we start, $imgContHorizontal is initialized to null (what's the point of that long chain of vars getting set to null at the top? They should either be set to something useful or their initialization might as well be deferred until first used.). It doesn't actually get assigned any value until toggleLayout() is called, and there it's wrapped inside a conditional such that it is only initialized if the layout is already horizontal (if (!isLayoutHorizontal)). When we start in vertical mode the var is never initialized, until something actually triggers toggleLayout(); but then a few lines later $imgContHorizontal.add() is called regardless of which branch was picked in the preceding conditional.

But why is $imgContHorizontal undefined here?

@santhosh You're listed as the maintainer for jQuery.WebFonts so I tagged you on this. If this isn't your bailiwick I'd appreciate a pointer in the right direction.

In T298417#7593376, @Ladsgroup wrote:

… I found only 100 deleted djvu files in the db …

@Agabi10 Did you give up on this patch? It looks really useful to me, and from the review comments it didn't look like there were any insurmountable problems (just maybe some documentable limitations due to the architecture context).

There's no obvious reason Scribunto should unconditionally enforce this when Lua as such doesn't, but that's an issue of defaults and somewhat orthogonal, IMO.

@RoySmith I've updated the task description to point at the relevant thread in the archives. But perhaps you (or perhaps @Pppery) could summarise the information learned in that thread for the benefits of others stumbling across similar issues and searches Phabricator?

This sounds really cool, but I am having trouble seeing what the use case for it is. What kind of data would one put in a "derived slot"? And since it is programatically generated, why not handle it in the parser and its cache?

Based on that error message it smells like a namespace collision. deWS has a lot of site-local JS that uses (and defines) a "SetCookie" function. That's a pretty generic name for such a function, so it may well be clashing with a name from elsewhere (e.g. the recent OSD stuff).

@Satirdan_kahraman The cover image (page 1) just needed a null edit, so there was apparently some kind of caching issue. I checked a few of the pages that have not yet been proofread and they appeared to load correctly.

@bd808 I still can't find any mention of Toolforge on mw:GitLab or its subpages, so do we need a separate task to set policy for access/groups/directory layout in GitLab? What's currently documented only deals with WMF and WMDE components, and I am not immediately convinced that the assumptions for those hold in the context of Toolforge.

@Tpt As best I can tell, the automatic next link on the main page was the existing behaviour. When the work's title was in $indexLinks[0], the if test inside the for loop would get a hit and set $current. The prev link test then explicitly excluded it by skipping index 0, but the next test just checked that it wasn't the last entry in the array ($i + 1 < $indexLinksCount) and so would add a next link on the page corresponding to the work's title.

Hmm. I may be insufficiently caffeinated just now, but…

In T288141#7525761, @Ruthven wrote:

@Xover Can you suggest a place (can be phabricator as well) where users can interact with more expert ones to discuss such technical issues? I reckon that this is a specific case where such help is needed and requires a longer discussion.

@Alex_brollo I don't think reversing a change that brings big improvements is the way to go (and this cannot function as a gadget), but your use case is interesting. Instead of trying to manually undo the changes I would suggest you try to find ways to use the new facilities to do what you're after. A lot of it I would expect to already be possible (OSD has an API exposed that can be used), and what's missing are probably good candidates for adding. If you explain your needs it might be possible to suggest alternate approaches for them.

Hmm. No smoking gun there that I can find.

Dollars to dimes it's choking on c:File:Cyclopaedia of English Literature 1844 Volume 1 page 548.djvu which is in that category and is currently showing up with 0x0 dimensions and 0 pages. The djvudump structure for this files is:

Possibly triggered by the changes from T275268. Ping @Ladsgroup.

In T215558#7510911, @Legoktm wrote:

That said...the real problem is clearly that MediaWiki or Thumbor or Varnish is not able to purge all the thumbnails. If someone has an example from the past 7 days it might be possible to look through the logs to get an idea of where the failure is happening (or at least rule out some stuff).