@OwenBlacker Yep, I removed the banner earlier today.

Here's the tracking ticket in the GitHub repo for reference.

Here's the tracking ticket in the GitHub repo for reference.

I have no objections to moving the scripts to pages on Meta; we'll just need to decide if they'd be gadgets or regular user scripts. It does seem weird to me that the cutting edge of production scripting is still saving scripts on wiki pages instead of using the tools-static Wikimedia CDN though.

This seems to be solved; I haven't seen any reported issues in the two years since the last comment.

Fixed via GitHub issue #148 and deployed. Thanks for reporting it!

@Billinghurst I have some preliminary work done to enable --canonical for meta. The project uses a lot of URL rewriting that needs to be redone though, so it's not quite ready yet.

I don't change scripts on Toolforge much anymore, but I don't see any recent reports/comments about the issue so it's probably safe to close this.

The current workaround is to import scripts from global-mobile.css/js on Meta into each local minerva.css/js page using Synchbot. When global CSS/JS becomes available on mobile, you'll need another Synchbot run to remove the manual imports.

I reversed the update temporarily. That should solve the high CPU usage if it's due to the query changes (rather than some other change on Toolforge), but the tools will break with the upcoming comment change.

Thanks! Could it be related to the comment view?

• The old query performs a simple select on all ipblocks rows. It's not ideal, but I don't know of a more optimal way and it didn't cause issues before. The WHERE can be simplified to ipb_range_start = ? AND ipb_range_end = ? in this case, but it doesn't affect the query plan.
• The new query is identical, but adds a left join on comment. Besides the expected eq_ref join, this also adds ten dependent subqueries on tables like revision and image. This version apparently causes high CPU.

I asked about this in #wikimedia-cloud, but unfortunately never got an answer. The only recent change is updating queries for T166732. The above query had two changes: (a) changed ipb_reason to comment_text AS ipb_reason, and (b) added LEFT JOIN comment ON ipb_reason_id = comment_id. I'm not sure why that makes the query so much slower, and it's hard to experiment without EXPLAIN access. Suggestions are welcome! I'd rather not revert the update entirely, since the ipb_reason column will be removed soon.

@Urbanecm Yep, it's there now. Thanks!

It doesn't seem to be added yet:

MariaDB [metawiki_p]> SELECT * FROM meta_p.wiki WHERE dbname = 'shnwiki' OR url = 'https://shn.wikipedia.org';
Empty set (0.01 sec)

Thanks!

The wiki isn't available in the Toolforge database yet; is that expected?

Can we enable this or add a separate global-mobile.js? I got a request to create a user's minerva.js on all wikis with Synchbot, but it feels like a step backward after all the work to migrate to global.js in the first place.

@bd808 I don't get an error with userpages/Evolution+and+evolvability. It may have been a cache issue; can you retry and post the error text if it still happens?

Global user #99 was me, until I accidentally deleted my global account. I'd love to get that ID back, if you want to fix it that way. ;)

I switched to a different service. Thanks for pointing that out!

Nope, the tool just caches wiki metadata temporarily. I purged the cache, so the error should be gone. :)

This happened for tools.meta today.

This seems to be resolved.

Sample affected page: en:User:Fæ/monobook.js contains rmflinks, but en:Special:Search/rmflinks doesn't show the page. This makes script maintenance difficult.

This would be useful for on-wiki user scripts. While we can do it with jQuery alone, it's not pretty:

$.ajax('//tools-static.wmflabs.org/meta/scripts/pathoschild.templatescript.js', { dataType:'script', cache:true }).then(function() {
    ...
});

This also breaks Synchbot, which has been disabled until this is fixed.

That too! Though we'll still need it for a while yet to clean up local pages for the transition to global accounts and user pages.

Great! It sounds like we can close this ticket. Synchbot is running fine on mwclient, but I'll look into pywikibot again as a possible future change. :)

@jayvdb This patch addressed an issue which affects crosswiki bots like Synchbot. Since the family files aren't always up to date, the bot would sometimes add user pages to the main namespace (because pywikibot replaced "User:" with an outdated namespace translation not recognised by MediaWiki). This didn't happen often, but it was difficult to notice because the bot edits so many wikis. The patch let you optionally use the canonical namespace which MediaWiki automatically translates, eliminating the possibility of outdated translations.

This is an issue in core too as @jayvdb mentioned above. However I've moved away from using pywikibot, so I don't personally need this anymore.