User Details
- User Since
- Oct 25 2014, 1:13 AM (476 w, 2 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Pathoschild [ Global Accounts ]
Apr 9 2023
May 6 2022
@OwenBlacker Yep, I removed the banner earlier today.
Apr 11 2022
Here's the tracking ticket in the GitHub repo for reference.
Here's the tracking ticket in the GitHub repo for reference.
Mar 21 2022
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.
Sep 25 2021
Sep 23 2021
May 26 2021
This seems to be solved; I haven't seen any reported issues in the two years since the last comment.
May 15 2021
Fixed via GitHub issue #148 and deployed. Thanks for reporting it!
May 26 2020
@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.
Feb 25 2020
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.
Sep 7 2019
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.
Aug 21 2019
Mar 8 2019
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.
Dec 3 2018
@Urbanecm Yep, it's there now. Thanks!
Nov 28 2018
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?
Oct 8 2018
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.
Feb 15 2018
Jan 8 2018
@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?
Nov 23 2017
Nov 14 2017
Jul 6 2017
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!
Jul 4 2017
Nope, the tool just caches wiki metadata temporarily. I purged the cache, so the error should be gone. :)
Feb 15 2017
Jul 16 2016
Apr 2 2016
Feb 6 2016
Jan 10 2016
This happened for tools.meta today.
Nov 22 2015
Sep 12 2015
Aug 30 2015
Aug 22 2015
Aug 18 2015
This seems to be resolved.
Aug 9 2015
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() { ... });
Jul 27 2015
This also breaks Synchbot, which has been disabled until this is fixed.
Jun 5 2015
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.