In T362473#9711646, @Novem_Linguae wrote:

Has this worked in the past?

If so, let's 1) add a regression tag and 2) git bisect to figure out the patch that introduced the bug. This patch looks like it might have touched some code related to this.

@Jdlrobson Could you take a look at the patch if the cherry pick/backport was setup correctly ?

In T348078#9720758, @Jdlrobson wrote:

@Soda let me know if you need any help reviewing or documenting these APIs and preparing backports. Happy to help!

Unrelated to this, there is a bunch of scripts on wikisource that use $( '.prp-page-image img' ).attr( 'src' ) which would probably go against the stable interface policy :( These should probably be asked to change over to the mw.proofreadpage.openseadragon API.

This is probably OSD being weird :(

Taking a look at the rest:

• ext.proofreadpage.osd-no-image-found should be fine to have around. That code path does get exercised (Thumbor is notoriously unstable for Wikisource).
• ext.proofreadpage.page-selection-register-filter is part of a beta feature, but is mostly stable, no issues there
• ext.proofreadpage.osd-controller-available is very stable no issues there

Regarding mw.proofreadpage:

• mw.proofreadpage.PagelistInputWidget most of this is supposed to be internal and probably needs to be removed unless somebody legitimately uses this (I do not know if anyone does)
• mw.proofreadpage.viewer is deprecated and has been for a while
• mw.proofreadpage.openseadragon is stable and has been for a while
• mw.proofreadpage.PageQualityInputWidget is internal and probably should not be exposed. (I'm pretty sure nobody uses this since it was introduced fairly recently in T344928)

Similarly proofreadpage-openseadragon-no-image-found is not a API that is provided by ProofreadPage. I'm super confused where these are showing up.

@Jdlrobson What/where is mw.ext.proofreadPage being created ?

@Novem_Linguae How does twinkle handle this case ?

Merged :)

Wsstats just subtracts one from the totals we get :)

Noting that the last time I checked, this worked on safemode as well.

Looks good to me overall, I'd suggest explicitly mentioning the project size. If you are planning for a large project, you do have time until early November.

Boldly un-closing. The workaround identified here is wiki specific. I would assume a code change in the WS Export tool would be required.

My hypothesis here is that the options module ext.pageTriage.externalTagsOptions for PageTriage is being considered a user-generated javascript bundle somehow. The class that loads the options, PageTriageExternalTagsOptions extends from the WikiModule class which is also appears to be used to load userjs and sitecss. I wonder if it might be setting some kind of variable flagging the module as a user-generated module.

@Maunikashekar I would suggest:

• Expanding on how you plan on implement some of the deliverables mentioned in the original project task
• Clearly specifying the project size.
• Potentially spacing out the tasks if you are going for a large sized project, since you do get time until November to complete all the deliverables (for example you mention that you plan on implementing "keyword search for New Pages Feed" in a week, imo, that might be a bit optimistic, since such a task will require filing a database modification request which takes time to be actioned).

@Prati28 What project size are you aiming for ? I would suggest spacing out your timelines to account for delays and back-and-forth. Also, note that for large projects, you should be able to plan out your timeline early November (In case you need more time).

I think this has already been resolved by the VueJS migration

In T319965#9633459, @Tpt wrote:

@Soda Amazing! Thank you! A user request from French Wikisource: Would it be possible to add to the website plots for all the wikisources (a line per wiki)? And the data in a table format instead of charts (I guess just allowing to download a csv is fine)?

In T357337#9633256, @Prati28 wrote:

Hi @Soda, I'm working on the first pre-GSoC task. Due to CORS restrictions, I'm unable to receive responses from the URL. Should I consider implementing a backend solution using PHP or Node.js, or should I use a CORS proxy?

I've been able to fork off the statistics stuff to https://wsstats.toolforge.org (mostly). (I did look into migrating it, but had difficulty even identifying which files reference what)

Boldly changing this to open. While the grid engine might have shut down, there still a need to migrate usable functionality off phetools. (For example, the statistics component is actively being migrated (by me), see the wsstats toolforge tool account). I am not sure what tool this should be categorised under, but I don't think Declined correctly reflects the current state.

In T357337#9618296, @Rockingpenny4 wrote:

@Soda , I already have mediawiki setup and will proceed with the PageTriage Extension installation . I have previously contributed to WikiEduDashboard and InlineComments Extension under Wikimedia, that being said , will my previous contributions help my proposal being selected?

In T357770#9615192, @Sgurrdearg wrote:

This still is not resolved? The font size is still way too big, and it is noticeably bigger than before all the changes. You’ve done absolutely nothing to fix it. As I stated, I have checked this on other devices and confirmed that this is persistent and not linked to my phone settings at all, despite @Jdlrobson’s incorrect assumption.

@AhmedSobhyOfficial Take a look at Special:NewPagesFeed on the English Wikipedia to see the current extension and how it works :)

Noting that this article appears to have been "patrolled" as opposed to "reviewed" see this query

@Bicolino34 Can you take a screenshot of the page in this state ?

The line height is indeed harder to read than the original. I would be in favour of keeping the original line heights.

https://phabricator.wikimedia.org/P56878 is the timeout error in case that is interesting :)

I'm having/had similar issues with Redis on qpqtool it seems like provisioning a fresh connection per request help, but that does not seem to be the recommended method of using redis-py.

https://discord.com/channels/221049808784326656/221060705078476801/1207769970696519710 would be the start of the messages in question. The major criticism is that the paragraphs are too dense and the line spacing is too small.

Based on some initial tests, it seems like the problem here is that people who had previous intentionally set the font to "Regular" (renamed "Standard" now) are now getting a bigger font instead of the "Small" font (which is now the default font).

There has been some feedback on the Wikimedia Discord community that this particular change makes the text very hard to read.

This should be done based on the merged PR and the lack of jobs at https://grid-deprecation.toolforge.org/t/croptool. There are still a few issues (namely with the magic border locator and some issues with persistent sessions) that need to be looked into/fixed. However, those can be dealt with followup patches.

In T319965#9536707, @Xover wrote:

In T319965#9534722, @Soda wrote:

I'm looking into migrating some of the usable aspects (statistics and match + split) of phetools into seperate standalone tools. This might take a while however, so I'd like to request that the tool be kept running after the Feb 14th shutdown deadline.

If all you're doing is forking bits and pieces of it into separate tools you should be able to do that without having phetools running on Grid Engine. I presume "shutting down the tool" means preventing it from spawning Grid Engine jobs, not deleting or making inaccessible the tool's account or code.

However, I still plan to try to port phetools entire to the Jobs Framework++ when I can find the time to sit down with it, so having an extension for that purpose would be appreciated.

I'm looking into migrating some of the usable aspects (statistics and match + split) of phetools into seperate standalone tools. This might take a while however, so I'd like to request that the tool be kept running after the Feb 14th shutdown deadline.

In T356759#9519308, @egardner wrote:

Hey @taavi, I posted a patch to PageTriage that fixes this issue. I resorted to a "brute force" solution where I simply scrapped the old package-lock.json, updated the dependencies manually, and then ran npm install to re-create it. If that's not an approach that you want to take, hopefully the patch (and it's accompanying package-lock.json file) will be useful in further debugging here.

After updating Vue and Codex for this project, I found that npm run test was throwing errors; ESLint was failing to parse the Vue files. I've remedied this by adding ESLint Plugin Vue to package.json as a dev dependency as well.

I didn't run this code or inspect it deeply, so I'd recommend spinning this up in a properly-provisioned local environment; all I did was confirm that npm install and npm run test could execute without errors. Several Codex components have changed between v0.14 and v1.3.1 (you can see the full changelog here) so there may be visual changes even if no functionality you rely on has broken.

This link is called "Mute preferences" in non en-wiki instances.

Tentatively tagging anti-harrasment, not sure which component this belongs to.

This is not a Opeseadragon issue, this is probably a issue with commons rendering of thumbnails

In T325607#9440813, @SCherukuwada wrote:

Here is a summary of our discussions with Google (they proofread this summary):

The web is really large and the search index can simply not include every single page. A page that otherwise has no problems may not be indexed for a myriad of complex reasons, for instance if the indexing process determines that the page is unlikely to be requested in search. This is in line with the Search Central documentation that states: "Google doesn't guarantee that it will crawl, index, or serve your page, even if your page follows the Google Search Essentials."

Google also shared a document containing resource links.

They encouraged using SEO Office Hours hosted by Google. And it comes with a disclaimer saying that they might not be able to answer all questions in a given instance.

Resources on Google Search.pdf33 KBDownload

@Danmichaelo I've raised a PR at https://github.com/danmichaelo/croptool/pull/192 to merge my changes into the croptool tree. Everything except the tests should work (will try and work on them once I'm confident everything else works).

I'm still working on this off and on, but migrating the app is a bit more involved since php7.4 is not availiable when building with buildpacks.

In T355575#9480311, @dcaro wrote:

Had a quick look at the code, I see also that there's a lot going on on the start script, you should try to move as much as you can to the build steps instead, otherwise they will run every time you start/stop the process.

For example, nodejs/npm installation is done already by the nodejs buildpack, composer installation+deps also, you are probably able to move the pecl scripts as part of nodejs or composer build scripts.

In T355575#9480266, @dcaro wrote:

If this is in order to compile jpetrans on the fly, you can try using the ubuntu package instead: https://launchpad.net/ubuntu/trusty/+package/libjpeg-turbo-progs

C/C++ are not supported langs, so we don't have a nice way of compiling those yet.

Possibly the fix for T353847 isn’t handling virtual packages correctly yet?

Yep, it is probably not, will look into it eventually, we don't want though to support a fully debian installation system, using the Apt buildpack is a workaround for edge-case scenarios where you are not using the lang's package management, so many edgecases that are not supported are to be expected.

Btw @nskaggs would it be possible to keep the tool's services running for now, since this is a widely used tool ?

I did take a look at this, but I'm currently blocked on T355575: [apt-buildpack] Does not handle virtual packages correctly

In T355519#9476166, @Peachey88 wrote:

I was able to do it on Tool-link-dispenser, I don't have anything other than Trusted-Contributors similar to @Soda.

@Soda what project did you attempt this one?

@Frostly, @HouseBlaster's recent config change already allows anyone to thank any bot on any Wikimedia wiki. (See this log action by me thanking your bot on enwiki).

Based on a few tests wrt to EranBot this appears to work.

Few points that probably need to be resolved:

• Adding a rest API that allows pinging arbitrary editors is not a great idea (Fixed by @Vikipolimer in this patch)
• Loading configuration via this method isn't going to do wonders for page startup times, I'd suggest using packageFiles to load the config instead.

In T334549#9439146, @Novem_Linguae wrote:

1. How does the pagetriagetagcopyvio API work? On a page with multiple revisions, I tried tagging the top revision and bottom revision as copyright violations, and I could not get PageTriage to display the "copyvio" tag. Then I figured out to set $wgPageTriageEnableCopyvio = true; but was getting inconsistent results. I will probably have to go read the code to figure out how this works. There may be a bug here.

Huh, I do see this as well, I will poke at this sleeping dragon, hopefully, if thing go well, it will not transfigure into a can of worms.

@Izno I wonder if we can use a div/span implementation and use role=progressbar and a aria-describedby ?

In T354267#9433291, @Izno wrote:

I have done something like this in the progression rainbow module, for anyone who looks into this.

In T352716#9427959, @MPGuy2824 wrote:

In T352716#9427217, @Soda wrote:

Turns out we were not passing in the Title when parsing the wikitext :(

Does this also explain why a null edit (i.e. recompiling the snippet) fixes the problem?

Turns out we were not passing in the Title when parsing the wikitext :(

Basically yes, that, the mediawikiId was null in certain unexplainable cases.

In T325607#9218609, @SCherukuwada wrote:

The important takeaway from this (as per our discussion) was this bit:

Google doesn't guarantee that it will crawl, index, or serve your page, even if your page follows the Google Search Essentials.

They'll share more details shortly. We've given them some URLs to debug on their end to see if the behaviour is intended.

In T353954#9424284, @Samwilson wrote:

Oh right! Good point, could be! I was testing with the following, which failed on current main and succeeds (i.e includes the cover image) with the above patch:

$ ./bin/console a:e -l en -t 'An African Millionaire' --nocache --nocredits

I guess this is about single-image TIFFs rather than multipage ones?

@Samwilson I don't think the underlying problem is the omission of the iurlwidth parameter, but rather the omission of the page number in iurlparam ?