Forum:MediaWiki updated to 1.31, and then 1.32 two weeks later because "what could go wrong?"

<<< Back to Logical Sector • <<< Back to Forum

So yeah, I forgot to actually mention this, but the site's been updated to MediaWiki 1.32. You might notice some changes, or not.

As usual, things might be (more) broken. Let me know, or stuff. -— Athyria 00:18, 15 Jeremy 2019 (UTC)

Is this why thumbs occasionally break? I was on the Dead Media Wiki a short while ago and some of its thumbnails are busted. This led me to believe it's a Mediawiki update thing and nothing to weep uncontrollably about (again). :D -- Hindleyak  Converse • ?blog • Click here! 22:12, 15 Jeremy 2019 (UTC)

No. It predates the latest series of updates. File:Icons-flag-ja.png is broken and was uploaded in August 2018, after 1.30 but before 1.31 and 1.32. File:81IzNO01E3L. SY606 .jpg was uploaded in 2017, when we were still running 1.23, and is broken. (Another file from 2017, File:Klingontarg.jpg, has only the 2018 reuploaded version broken, but that's not how it was before. Compare File:Bean-vat.jpg, both versions uploaded in April 2018, only the current one broken.) And no, it's not the 1.23 update either. Here are some more examples: File:Maxresdefault.jpg from 2016, File:Bill Cipher & pals setting to go to the world's corners!.gif (only broken on ListFiles), File:Bob guccione.jpg from 2014, File:John brown civil war.jpg from 2013, File:Dan03.png from 2012. Yes, it predates the move off Carlb's server (or, at least, some of the files do). That's the point where I stopped looking.

I incorrectly reported the inability to rasterize SVG files as a consequence of the 1.30 update. In fact, it dates back to 2015: see File:ILLOGICOPEDIA LOGO REMAKE.svg and File:AMBlogo.svg. There's evidence of it happening in 2014 as well, such as File:FeatArticle.svg, but it hadn't yet progressed to the current completely broken state because the image at the top of that page is displayed and the other SVGs uploaded that year, e.g. File:Swiss Flag.svg, have no problems.

I don't think any of this was caused by MediaWiki updates, and I don't think more updates will fix or break it. It would be nice to have it fixed, though. ❦ Flyingcat (meow?)fr: 00:24, 16 Jeremy 2019 (UTC)

...

I'm really digging my new Pentax. 17:42, 16 Jeremy 2019 (UTC)

Whoops, the thumbs thing should now be fixed. (Lack of) thumbs in the file history may not update, but you should be able to generate new ones now. -— Athyria 01:49, 18 Jeremy 2019 (UTC)

Actually, they are fixed in file histories. Awesome. While you're at it, any chance you could install Inkscape or set $wgSVGConverter to something that works? ❦ Flyingcat (meow?)fr: 02:36, 18 Jeremy 2019 (UTC)

Ah, whoops, missed that. Done. What else you got for me? -— Athyria 04:40, 18 Jeremy 2019 (UTC)

Yay! uh... well, there are these things on the 1.30 forum that don't seem to have been addressed, but I don't know what the solutions to them are. I also noticed that notifications are working again. This is good. ❦ Flyingcat (meow?)fr: 05:57, 18 Jeremy 2019 (UTC)

Right, I did sort of lose track of that. I think I need considerably more coffee before I can even begin to try parsing it all again, though. I miss having a working brain. Maybe sometime next week. Just make sure anything new winds up on these pages in the meantime, too. -— Athyria 16:21, 18 Jeremy 2019 (UTC)

Got any links to the misbehaving templates in question? I'd try to find them myself but I have no idea where to look or what the malfunctions look like. Bizzeebeever (talk) 16:58, 19 Jeremy 2019 (UTC)

You'd have to ask Snarglefoop. He mentioned the Obamacare page, so judging by its history I'd guess {{Obamacare}} is one of them. You can see it causing problems with headers here. ❦ Flyingcat (meow?)fr: 04:01, 20 Jeremy 2019 (UTC)

Looks like you fixed it. (For future reference, as per this note, the <choose> tag needs to be used with the uncached parameter to get it to show different values with every page load). Is every other report on that page resolved as well? I know about the missing SVG converter, the broken gadgets and the current JS errors, but I'd like to get last year's bug forum out of the way first >_<. Bizzeebeever (talk) 10:44, 20 Jeremy 2019 (UTC)

Yes, looks that way. I've used your {{bug-resolved}} template. You might want to reconsider putting it in headers, since it breaks links to the old section titles and makes it so you go to the top of the page when saving the section instead of directly to the section. The latter is a problem with templates in section headers in general; it would be nice if MediaWiki handled that differently.

FWIW there's another problem with VFF that wasn't reported on the forum, but I don't know if this is connected to updates, and it's evidently due to certain people's signatures. ❦ Flyingcat (meow?)fr: 05:24, 26 Jeremy 2019 (UTC)

I've disabled VisualEditor, as I'm not one of those who would benefit from it (probably new users). You do realize the VisualEditor tabs that appear when it's enabled and the source tabs when it's disabled use the same interface messages. I know this is awkward, but it would be better if you found a solution that doesn't put VisualEditor-specific language there. ❦ Flyingcat (meow?)fr: 23:20, 18 Jeremy 2019 (UTC)

Nobody benefits from VisualEditor. The Supreme Leader XY --- sacrifices and capitalism 02:50, 19 Jeremy 2019 (UTC)

Well... I'll say this much: I doubt it's as helpful here as on Wikipedia, since the wikicode used tends to be much less "intense". Ever tried to figure out where a ref begins and ends so you can fix the text around it? It's a pain. But because this is one of the WMF's projects, you have to weigh the costs (i.e. buggy mess, mostly) against the benefits. The last time I tried VE over there, my browser threw up, and I'm still not convinced it was a coincidence.

There's a checkbox to enable it, which I unchecked, and a different checkbox to "temporarily disable" it, which I left unchecked. I don't get it. This comment made more sense in my head. I'm going to get a snack. ❦ Flyingcat (meow?)fr: 10:08, 19 Jeremy 2019 (UTC)

Yeah, might as well revert the message changes. I was hoping they'd work better than they did, but the handling is very not smart. -— Athyria 14:38, 19 Jeremy 2019 (UTC)

I see we now have the "interface administrator" thing. I've been the one dealing with CSS and JS issues, and I was planning to continue in that role, so I don't care for this change. I suggest assigning editsitecss, editsitejs, editusercss and edituserjs to the sysop group rather than giving anyone this new user right or leaving this stuff entirely up to the few busy sysadmins. This isn't Wikipedia. We're not chronically getting attacked by hackers with advanced coding skills, or by any hackers for that matter, and the admin accounts aren't a large "attack surface" anyway. The other admins mostly don't touch this area, but it's not like there's any point in restricting them from it. Shame they put this in core. ❦ Flyingcat (meow?)fr: 22:22, 20 Jeremy 2019 (UTC)

Done. No reason not to, as sysops already had the rights and it's a small site anyway. Also, as per above, please let me know if the issues in last year's forum are resolved (the issues with headers, anyway, not Athyria's list). Bizzeebeever (talk) 03:11, 21 Jeremy 2019 (UTC)

Chemistry templates

This is unrelated to the MW updates, but could someone undelete the deleted templates listed at User_talk:XY007/Archive_lima#Deletion time? It's making the element pages pretty broken. CG098 (talk ₪‎ contribs) 22:58, 24 Jeremy 2019 (UTC)

The thing is, lol asked that they should be deleted. So I have deleted all of them (including broken redirects) under the criterion of 'author request'. The Supreme Leader XY --- sacrifices and capitalism 09:32, 26 Jeremy 2019 (UTC)

I won't intervene because I don't want to get into a wheel war, but there's another problem with this, which is that a number of them were actually created by Flyingidiot. "Author request" is invalid for those. I complained about this back in July. I think what should be done is restore those and remove the others from the pages where they're transcluded. This can be partly done by reverting lol's edits to preexisting pages, such as Random table of ailments and Googleplex (Element).

Should this be a different forum post? Should we have a vote? ❦ Flyingcat (meow?)fr: 22:44, 26 Jeremy 2019 (UTC)

Yes and possibly. The Supreme Leader XY --- sacrifices and capitalism 06:32, 27 Jeremy 2019 (UTC)

Also, your sig is being substed instead of transcluded. It's not really long and disruptive, but fixing it would still be good. ❦ Flyingcat (meow?)fr: 09:09, 28 Jeremy 2019 (UTC)

Internal error when moving page

I tried to move Time is Running Out and its subpages into the IllogiGames namespace and got an internal error. I thought making an edit to it might fix that (it's the same error I got when trying to move Flipped text, and it worked then), but it didn't. Related?

[a8c2ad5b5041a2e38fa6256c] /w/index.php?title=Special:MovePage&action=submit MediaWiki\Revision\IncompleteRevisionException from line 420 of /var/www/mediawiki/core/includes/Revision/RevisionStore.php: sha1 field must not be ''!

Backtrace:

#0 /var/www/mediawiki/core/includes/Revision/RevisionStore.php(473): MediaWiki\Revision\RevisionStore->failOnEmpty(string, string)
#1 /var/www/mediawiki/core/includes/Revision.php(1136): MediaWiki\Revision\RevisionStore->insertRevisionOn(MediaWiki\Revision\MutableRevisionRecord, Wikimedia\Rdbms\DatabaseMysqli)
#2 /var/www/mediawiki/core/includes/MovePage.php(543): Revision->insertOn(Wikimedia\Rdbms\DatabaseMysqli)
#3 /var/www/mediawiki/core/includes/MovePage.php(271): MovePage->moveToInternal(User, Title, string, boolean, array)
#4 /var/www/mediawiki/core/includes/Title.php(4067): MovePage->move(User, string, boolean, array)
#5 /var/www/mediawiki/core/includes/specials/SpecialMovepage.php(752): Title->moveTo(Title, boolean, string, boolean)
#6 /var/www/mediawiki/core/includes/specials/SpecialMovepage.php(128): MovePageForm->doSubmit()
#7 /var/www/mediawiki/core/includes/specialpage/SpecialPage.php(569): MovePageForm->execute(NULL)
#8 /var/www/mediawiki/core/includes/specialpage/SpecialPageFactory.php(568): SpecialPage->run(NULL)
#9 /var/www/mediawiki/core/includes/MediaWiki.php(288): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#10 /var/www/mediawiki/core/includes/MediaWiki.php(860): MediaWiki->performRequest()
#11 /var/www/mediawiki/core/includes/MediaWiki.php(517): MediaWiki->main()
#12 /var/www/mediawiki/core/index.php(42): MediaWiki->run()
#13 {main}

❦ Flyingcat (meow?)fr: 09:09, 28 Jeremy 2019 (UTC)

Might wanna ping Bizzeebeever or Athyria for this.

Oh, wait... 17:40, 28 Jeremy 2019 (UTC)

Does "pinging" work now? I didn't think it did before. ❦ Flyingcat (meow?)fr: 21:21, 28 Jeremy 2019 (UTC)

After making invisible whitespace edits to all the subpages, including the talk subpage, I was able to move them. (I called them dummy edits, but they're not really.) Makes sense, since I was trying to move them all at once. I still don't know what the underlying problem is or why this fixes it. I tried to roll back one of the edits and got the same internal error. ❦ Flyingcat (meow?)fr: 04:47, 31 Jeremy 2019 (UTC)

I ran a maintenance script that should have fixed the rest of it. If this happens again, hurl yaks at me. Also pinging doesn't actually work if you have a template signature, so... yeah. Yaks. -— Athyria 11:33, 4 Farbleum 2019 (UTC)

Rollback internal error

I got the same "sha1" error when trying to roll back some edits by Special:Contributions/The real blanker. Undo worked but not rollback. ❦ Flyingcat (meow?)fr: 05:33, 25 Farbleum 2019 (UTC)

I've been experiencing this issue as well, and it seems to affect random pages; that abominable red-and-pink "sha1" template pops up in about a third of all the edits that I've tried to rollback. I'm having this issue with the page "This." 01:20, 6 Arche 2019 (UTC)

Upon further inspection, I found that the "sha1" template differs slightly when it involves a broken rollback.

[81609182c6f32276545aa797] /w/index.php?title=This&action=rollback&from=204.126.11.221&token=fda667f795b730f5e94d74ff6136f7415c7f1ea4%2B%5C MediaWiki\Revision\IncompleteRevisionException from line 420 of /var/www/mediawiki/core/includes/Revision/RevisionStore.php: sha1 field must not be !
Backtrace:
#0 /var/www/mediawiki/core/includes/Revision/RevisionStore.php(473): MediaWiki\Revision\RevisionStore->failOnEmpty(string, string)
#1 /var/www/mediawiki/core/includes/Storage/PageUpdater.php(961): MediaWiki\Revision\RevisionStore->insertRevisionOn(MediaWiki\Revision\MutableRevisionRecord, Wikimedia\Rdbms\DBConnRef)
#2 /var/www/mediawiki/core/includes/Storage/PageUpdater.php(738): MediaWiki\Storage\PageUpdater->doModify(CommentStoreComment, User, integer)
#3 /var/www/mediawiki/core/includes/page/WikiPage.php(3254): MediaWiki\Storage\PageUpdater->saveRevision(CommentStoreComment, integer)
#4 /var/www/mediawiki/core/includes/page/WikiPage.php(3080): WikiPage->commitRollback(string, string, boolean, NULL, User, array)
#5 /var/www/mediawiki/core/includes/page/Article.php(2858): WikiPage->doRollback(string, string, string, boolean, NULL, User)
#6 /var/www/mediawiki/core/includes/actions/RollbackAction.php(79): Article->doRollback(string, string, string, boolean, NULL, User)
#7 /var/www/mediawiki/core/includes/actions/FormlessAction.php(43): RollbackAction->onView()
#8 /var/www/mediawiki/core/includes/MediaWiki.php(501): FormlessAction->show()
#9 /var/www/mediawiki/core/includes/MediaWiki.php(294): MediaWiki->performAction(Article, Title)
#10 /var/www/mediawiki/core/includes/MediaWiki.php(860): MediaWiki->performRequest()
#11 /var/www/mediawiki/core/includes/MediaWiki.php(517): MediaWiki->main()
#12 /var/www/mediawiki/core/index.php(42): MediaWiki->run()
#13 {main}

Obviously, the two messages appear identical at first glance, but I noticed that the numbers involved were different and the word Rollback was found instead of MovePage. 01:24, 6 Arche 2019 (UTC)

Autoconfirmed threshold

Did this wiki always have no threshold for autoconfirmed users? It does now. I don't know if you're aware that the default values for mw:$wgAutoConfirmAge and mw:$wgAutoConfirmCount are both 0. I wasn't. This means that all accounts are instantly autoconfirmed, so anything that is supposed to let in only autoconfirmed users -- such as semiprotection -- only locks out IP editors and lets in everyone with an account. I found this out the hard way when I modified Special:AbuseFilter/8 to only trip when the user was not autoconfirmed and The real blanker, which had been created less than four days ago, was still able to blank pages. This person always seems to come in with accounts, and we've had a number of other registered vandals and trouble makers, so it would be more convenient if "autoconfirmed" meant something more.

If you want to change this, it's easy. Just add this to LocalSettings.php:

$wgAutoConfirmAge = 345600;
$wgAutoConfirmCount = 10;

or fill in whichever numbers you would prefer (the age is in seconds, so 345600 = 4 days).

On the subject of user rights, it seems to be standard practice to make abuse filters private, so you might also consider adding this:

$wgGroupPermissions['*']['abusefilter-view'] = false;
$wgGroupPermissions['sysop']['abusefilter-view'] = true;

❦ Flyingcat (meow?)fr: 17:10, 25 Farbleum 2019 (UTC)

You seriously ought to be a Bureaucrat, Flyingcat; you certainly possess the skills needed for such an administrative role and I'm sure that the other 'Crats would love for you to do their dirty work for them. 17:27, 25 Farbleum 2019 (UTC)

Thanks, but I'm not sure what that has to do with modifying LocalSettings.php, which requires server-side access. I would have to be a sysadmin to do that. Also, my "skills" in this area mostly consist of knowing how to look stuff up on mediawiki.org. I'm like this. ❦ Flyingcat (meow?)fr: 17:32, 25 Farbleum 2019 (UTC)