Page MenuHomeMiraheze

Upgrade to MediaWiki 1.29
Closed, ResolvedPublic

Description

MediaWiki version 1.29 should be coming out on the 25th (2 days), so just making this task now.

Event Timeline

Reception123 renamed this task from Upgrade to 1.29 to Upgrade to MediaWiki 1.29.May 23 2017, 05:57
John removed John as the assignee of this task.May 23 2017, 06:50
John subscribed.

Just dropping assign for now.

Last update on this is it apparently will be released after the 1st of June.

Reception123 lowered the priority of this task from High to Normal.May 31 2017, 18:42

Release date not looking good. https://lists.wikimedia.org/pipermail/wikitech-l/2017-May/088238.html

Since the release is not possible yet, I am moving this back to "Normal" until 1.29 is actually released.

Reception123 lowered the priority of this task from Normal to Low.Jun 8 2017, 17:43

would be "Stalled" on WMF Phabricator. There's nothing we can do but wait

Reception123 raised the priority of this task from Low to High.Jul 14 2017, 10:25

1.29 was released yesterday. We should upgrade ASAP.

FYI MediaWiki 1.29 is working (https://test1.miraheze.org/wiki/Special:Version) without any extensions enabled. The next steps are to check/add SQL files to wmgCreateWikiSQLfiles and then test the upgrade with extensions on extloadwiki (or test1wiki).

SQL changes (patches):

Flow:
/srv/mediawiki/w/extensions/Flow/db_patches/patch-add-wiki.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-addindex_flow_ext_ref_idx_v3.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-drop-flow_subscription.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-dropindex-flow_ext_ref_idx_v2.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-increase_width_wiki_fields.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-ref_target_not_null.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-primary-keys.sql
/srv/mediawiki/w/extensions/Flow/db_patches/patch-increase_width_wiki_fields.sql

Newsletter:
/srv/mediawiki/w/extensions/Newsletter/sql/nl_newsletters-add-unique.sql
/srv/mediawiki/w/extensions/Newsletter/sql/nl_main_page_id-drop-index.sql
/srv/mediawiki/w/extensions/Newsletter/sql/nl_newsletters.sql

PageTriage:
/srv/mediawiki/w/extensions/PageTriage/sql/PageTriageLog.sql
/srv/mediawiki/w/extensions/PageTriage/sql/PageTriageLogPatch_Drop_ptrl_comment.sql

SocialProfile
/srv/mediawiki/w/extensions/SocialProfile/UserStats/user_points_archive.sql
/srv/mediawiki/w/extensions/SocialProfile/UserStats/user_points_monthly.postgres.sql
/srv/mediawiki/w/extensions/SocialProfile/UserStats/user_points_monthly.sql
/srv/mediawiki/w/extensions/SocialProfile/UserStats/user_points_weekly.sql

WikiBase:

/srv/mediawiki/w/extensions/WikiBase/repo/sql/AddEntityPerPage.sql
/srv/mediawiki/w/extensions/WikiBase/repo/sql/AddTermsFullEntityId.sql

Re. ContentTranskation: we've never had any SQL for it. So these definitely aren't patches if they're required. Check upstream for database config please.

Also you don't want any that aren't for MySQL. See the ones you've listed for SP.

In the meantime, there are issues with two extensions while upgrading to 1.29: AccessControl and ArticleFeedbackV5.
ArticleFeedbackV5 could be (as we did with others in the past) disabled until we figure it out.

AccessControl is a larger problem, as it is used to protect private information, so disabling it would not be a good idea. I'm not sure what we can do about it.

Since the issues are likely upstream I have opened two tasks but in the meantime we need to decide what we'll do with AccessControl unless we figure something out
https://phabricator.wikimedia.org/T172718
https://phabricator.wikimedia.org/T172771

Even though we prefer REL branches, the only fix for ArticleFeedbackV5 seems to be switching to the master branch.

If upstream say use master, use master. Our preference isn't using RELs, its a standard of versioning we use.

Will do but AccessControl is still a blocker, and with it not working for the reasons mentioned above we can't upgrade.

I think our best option is to temporarily disable AccessControl until the upstream issue is resolved. Wikis where AccessControl is currently enabled are below. @NDKilla Since there might be private information I propose that unless they already are we make all the wikis private:

bmedwiki - Closed | No apparent use of AccessControl
claneuphoriawiki - Open | Errors with AccessControl was discussed on Phabricator; not sure they were ever resolved
extloadwiki - N/A
test1wiki - N/A
metaautonomywiki - Deleted
mindgearwiki - Closed | Cannot confirm if AccessControl is/was being used PRIVATE
ndnwiki - Deleted
westmarcheswiki - Open | Cannot confirm if AccessControl is being used PRIVATE
wimawiki - Closed | Cannot confirm if AccessControl is/was being used
wisdomwikiwiki - Closed | Requester gave me permission to disable if needed
wisdomsandboxwiki - Closed | Requester gave me permission to disable if needed

The issue with AC is they use it to segregate people. Whether a wiki is public or private is irrelevant as User A shouldn't be able to read page B under any circumstance.

Attempt to confirm usage and discuss. If there's no usage, kill it.

But the people would automatically be out, since when the wiki is made private they aren't members. Since the wikis are closed I doubt I'll get answers from those.

But what if the wiki is private?

@John Two of the wikis in question are private. I guess I could just manually check every page and find if AccessControl is being used. In the case that it is, what should be done (assuming that the bureacurats are not active, hence why the wikis are closed and that they will not respond)?

If they're closed they're unmaintained. Fast track delete if close to deletion date otherwise remove from cw_wikis and make a calendar note for yourself,

One of them is closed, and I'm in luck, 6 months from closure is in 2 days! The other one is open, but no edits since the first of June so that one might be a problem (I'll search to make sure if it's actually being used)

There is only one page which I assume uses AC, https://westmarches.miraheze.org/wiki/Information_for_Game_Masters. It currently gives a 500 HTTP error, but I'm sure if AC is disabled that will not be the case. I think the solution is to delete that page, maybe oversight it and if the bureaucrats need it, they can request it back.

There's no greater teacher than expierence apparently.

I'll document the entire process since my role is no longer "do it" but rather "teach it".

mw2 is waiting to be deployed but mw1 is in action on 1.29.

This upgrade took 3x longer than the past ones and than I expected, no learning points though really. Maybe less wikis? Who knows.

It's done and this makes me 3/4 on MediaWiki upgrades now (3/3 on the last 3!)