Apr 16 2023
Jan 23 2023
Thanks so much! 🍺
Jan 22 2023
Reopening this, because at the time the MH skin version was downloaded, Wikimedia folks had renamed the skin folder, unknowingly causing several embedded skin assets to give 404s, which was reported and remedied here:
Nov 26 2022
No problem. Thanks for letting us know! :)
Oct 29 2022
This extension has been moved to Wikimedia Phabricator, is marked as maintained (now maintained by Wikimedia folks, as was kindly offered here once it was posted about), and is now marked compatible with 1.39+ on its extension page.
Jun 14 2022
Sorry, I'm not a programmer, just a MH user. I saw there was a fork by a Wikimedia developer, with one file different (which has 4 lines changed in it. isLoggedIn looks to have been changed to isRegistered in each). I didn't realize it was a problem to swap out that file or use fork at the bottom of the link, so again, sorry.
Jun 13 2022
A patch has been submitted for this skin and confirmed as working (though not yet merged), can it please be retested for those wikis that use it?
Mar 21 2022
Also, I can't re-create the tables via interface, I asked if someone could or would please try that via SSH, but received no response to that ask, so diabled cargo instead.
Mar 19 2022
Thanks for this!
Mar 18 2022
Okay, thanks. I've just unsubscribed and muted since I can't take myself off this, and I can't close it.
I'm guessing this problem is related to T8876, rendering cargo unusable for us. I'm mark as stalled (apologies if that's not correct, please feel free to mark as closed because we're not moving forward with MH at this time, will re-test for migration at a later date).
Thanks for confirming, (and yep, using Cargo and DPL3 together on pages sounds a little insane lol). We've entirely disabled Cargo, and we'll just stick where our production wiki is at for now, and finish thoroughly testing the last LTS against Cargo and DPL3 before we do an upgrade. We'll edit once a month or something on MH to keep alive for a future migration re-test.
Only one or the other is used on individual pages, not both. Or are you referring to simply having both extensions enabled on a single wiki at the same time (and not using them together on pages)? When we tested their use together on a standalone MW install (1.34 and 1.35 LTS), they were fine.
Just as an update to this, one table is still not populating fully:
Thanks very much for the performance improvements. I'll test, but first I'm going to test with DPL3 disabled to see if our 502/503s continue on other pages, and on pages that use Cargo, which is having weird problems of its own, per T8828 (related or unrelated, no idea).
Mar 7 2022
Here's some interesting info to add now that I'm testing. I waited until job queue was empty then set a table to re-create... initially the correct number of jobs are created that match the number of entries that should populate in the Cargo table (854 jobs, for 854 rows needing to be populated? Is that how it even works?):
For the short term, re-creating the tables via cargoRecreateData.php would be very helpful yes, thank you. Then I can see if they populate at all or if the same occurs (the interface method supposedly runs the same, but perhaps some limit or other issue is interrupting its ability to complete or not time out? I think long-term, it might be worthwhile finding out why the tables are not populating, and why job queue reports as having only 3 jobs.
Mar 4 2022
I see others have been reporting in Discord too.
The tables that won't populate, and can't be swapped, are the ones that trigger the errors. Seems like we may be stuck between a rock and a hard place unless table regeneration is done via SSH.
Mar 3 2022
Unfortunately, no. While some tables have populated via job queue, and can be swapped in (the ones with 9k and 14k rows), the old tables remain active until they can be swapped, so I can't test against the new ones. For some reason, the others have gotten stuck repeatedly and refused to populate with all results, so I'm having to redo them one by one, repeatedly after they are stuck for significant lengths of time.
Mar 1 2022
Thanks for adding the details!
Feb 24 2022
Dec 11 2021
All works now, thank you!
Dec 9 2021
Thanks for checking, strange he noted it was a MW 1.37 bug (though just glad he added a workaround in Cargo). I'll have to wander blindly around mediawiki phab to see if I can find where the bug is mentioned.
Ah, I also just found this, potentially the extension may need to be updated if the copy tested was tested before Nov 25th?
Apologies, took me some time to get that typed out. I was in the process of installing MW 1.36.2 on my VPS, so I could try reproducing the problem there, then remembered the 1.37 upgrade, re-tested and stumbled on this.
I partially figured out what's going wrong in the initial table, with added columns not generated. After MW upgrade to 1.37, which now allows _pageData table to be regenerated via user interface, doing a replacement table (hitting refresh here is equivilent to php setCargoPageData.php --replacement). Unfortunately, this always fails part way through with the error "creating jobs to populate _pageData failed" possibly because of the number of records or run time since not done via command line?
Dec 2 2021
To clarify, I'd just do it on the cargo tables page, however one of the tables is generated by an extra mediawiki Cargo config and cannot be regenerated via the interface, it can only be regenrated by maintenance script.
Nov 24 2021
Or perhaps php cargoRecreateData.php --table _pageData might work? I'm not familiar with this table creation or functioning, didn't use it before.
Hmm, I'm not sure what's going on then. For some reason it is not creating or populating all columns, only one column as can be seen on our private wiki here:
I see that the needed table (entitled _pageData) was indeed created by Cargo; however, it is missing columns (not able to be set via the interface only via maintenance script). I think php setCargoPageData.php needs to be run from Cargo /maintenance in order to populate the _pageData table with the columns set in that config. Found it finally in the cargo docs:
Nov 11 2021
Ah, I didn't find that one, sorry. Probably had a typo in my search. The only change since T4442 is the part about "many other batch upload extensions already installed" --I think it's just MSUpload now, since the others fell unmaintained, and if folks need protected categories with that they're out of luck.
Nov 10 2021
Nov 9 2021
Thank you both, much appreciated!
Nov 2 2021
Thanks for confirming.
Nov 1 2021
Our images are not importing after a couple of days. Any chance this can be stuck? I've disabled InstantCommons (per Agent) to prevent random Instant Commons image from showing up in their place.
Oct 29 2021
Have I mentioned that you guys rock? Well, you guys rock! Thanks :)
Email checked and sent. Thanks, and my apologies.
Thanks. Ah, I somehow missed the link target in the settings, thank you! I will fix that one tomorrow also. Thanks for confirming that first namespace will be 3000, I thought that might be the case but wasn't sure.