Page MenuHomePhabricator

"wikitext" content is not allowed on page … in slot "Main"
Closed, ResolvedPublic

Related Objects

Event Timeline

MB-one created this task.Mar 27 2019, 8:53 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 27 2019, 8:54 PM
Clpo13 added a subscriber: Clpo13.Mar 27 2019, 8:56 PM
MB-one updated the task description. (Show Details)Mar 28 2019, 9:47 AM
Fae awarded a token.Mar 28 2019, 9:51 AM
Fae added a subscriber: Fae.
Yann added a subscriber: Yann.Mar 28 2019, 11:26 AM

This is a very serious bug. Now Main Namespace pages are now locked for everybody, including admins. Please fix ASAP.

Lucas_Werkmeister_WMDE triaged this task as Unbreak Now! priority.Mar 28 2019, 11:34 AM

With VisualEditor’s new Wikitext mode:


Probably related to Structured Data on Commons – it looks like MediaWiki now things the main namespace is an entity namespace (like it is on Wikidata).

Restricted Application added subscribers: Liuxinyu970226, TerraCodes. · View Herald TranscriptMar 28 2019, 11:34 AM

RecentChanges shows no edits in the main (gallery) namespace after 16:44 UTC yesterday, which is shortly before this SAL entry by @Jdforrester-WMF:

Synchronized wmf-config/InitialiseSettings.php: T214075 SDC: Enable Wikidata federation on Commons (duration: 00m 57s)

Change 499752 had a related patch set uploaded (by Reedy; owner: Reedy):
[operations/mediawiki-config@master] Revert commonswiki to .22

https://gerrit.wikimedia.org/r/499752

Change 499752 abandoned by Reedy:
Revert commonswiki to .22

https://gerrit.wikimedia.org/r/499752

Change 499756 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[operations/mediawiki-config@master] Revert "SDC: Enable both new-style and old-style Wikibase federation on Commons"

https://gerrit.wikimedia.org/r/499756

Change 499756 merged by jenkins-bot:
[operations/mediawiki-config@master] Revert "SDC: Enable both new-style and old-style Wikibase federation on Commons"

https://gerrit.wikimedia.org/r/499756

Mentioned in SAL (#wikimedia-operations) [2019-03-28T12:02:02Z] <lucaswerkmeister-wmde@deploy1001> Synchronized wmf-config/InitialiseSettings.php: [[gerrit:499756|Revert "SDC: Enable both new-style and old-style Wikibase federation on Commons" (T219450)]] (duration: 00m 57s)

I was able to make this edit with the above config revert applied on the debug server, and have now pushed it to all the other servers as well. Please try it out!

We have several confirmations this is working now.

Lucas_Werkmeister_WMDE lowered the priority of this task from Unbreak Now! to High.EditedMar 28 2019, 12:32 PM

Okay, lowering priority. Left to do:

  • unbreak testcommonswiki
  • fix whatever bug caused this and then try to enable federation again
  • presumably the federation which we now disabled was used for something (“depicts” statements, right?), so the Structured Data on Commons team might need to communicate that it’s currently unavailable
  • …?
  • unbreak testcommonswiki
  • presumably the federation which we now disabled was used for something (“depicts” statements, right?), so the Structured Data on Commons team might need to communicate that it’s currently unavailable

If I understand correctly, depicts testing currently only happens on test-commons anyways, so the config revert on the real commons shouldn’t have affected that. And as there are no gallery pages on test-commons, let’s leave that wiki as it is for now, so that depicts testing can continue.

Reproducible on testcommons

and beta

presumably the federation which we now disabled was used for something (“depicts” statements, right?), so the Structured Data on Commons team might need to communicate that it’s currently unavailable

Everything on commons will continue working as it should after the revert.
Nothing was using this federation yet, it was just turned on as an initial step before depicts would be turned on later down the line.

@Yann That is known, it has been on purpose left like that so an actual fix can be tested there first.

On testcommons, the WikibaseRepo’s entity namespace lookup thinks there are items and properites in namespaces 0 and 120:

> var_export( Wikibase\Repo\WikibaseRepo::getDefaultInstance()->getEntityNamespaceLookup() );
Wikibase\Lib\Store\EntityNamespaceLookup::__set_state(array(
  'entityNamespaces' => 
  array (
    'mediainfo' => 6,
    'item' => 0,
    'property' => 120,
  ),
  'entitySlots' => 
  array (
    'mediainfo' => 'mediainfo',
    'item' => 'main',
    'property' => 'main',
  ),
))

This causes the ContentModelCanBeUsedOn hook handler to reject wikitext content for titles in those namespaces. I’m not familiar enough with Wikibase federation to say what part of this is wrong.

Change 499812 had a related patch set uploaded (by Addshore; owner: Addshore):
[mediawiki/extensions/Wikibase@master] Account for entities from other sources in ContentModelCanBeUsedOn

https://gerrit.wikimedia.org/r/499812

Change 499812 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Account for entities from other sources in ContentModelCanBeUsedOn

https://gerrit.wikimedia.org/r/499812

Testing the new train on testCommons, this fix works for EditPage edits but still blocks API edits with wikibase-no-direct-editing ("Direct editing is disabled in namespace").

Change 500856 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/Wikibase@master] Hooks::onApiCheckCanExecute: Account for entities from other sources

https://gerrit.wikimedia.org/r/500856

Change 500856 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Hooks::onApiCheckCanExecute: Account for entities from other sources

https://gerrit.wikimedia.org/r/500856

Tested on Beta Cluster and now fully working. Will re-test after next week's train.

Lucas_Werkmeister_WMDE closed this task as Resolved.Apr 16 2019, 2:24 PM

API editing in the main namespace seems to work again (test edit) – I think we can close this task now.

4nn1l2 added a subscriber: 4nn1l2.May 24 2019, 5:30 AM
mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:07 PM