Page MenuHomePhabricator

PropertyDataTypeLookupException in Files with a deleted property
Closed, ResolvedPublic

Description

All files that have a statement with deleted (from wikidata) property P727 fail to display, and show an error msg instead.

See https://commons.wikimedia.org/w/index.php?search=haswbstatement%3AP727&title=Special:Search&go=Go&ns0=1&ns6=1&ns12=1&ns14=1&ns100=1&ns106=1

MediaWiki internal error.

Original exception: [Xo137QpAEKIAAIaUscAAAADY] 2020-04-08 07:06:21: Fatal exception of type "Wikibase\DataModel\Services\Lookup\PropertyDataTypeLookupException"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

Removing statements with the deleted property seems to fix the problem, see https://commons.wikimedia.org/wiki/File:Dr_Hjortons_Pulver,_Huskvarna.jpg (you can see from looking back through the revisions that it used to have statements with the deleted property)

Event Timeline

This may be because of this file uses P727, which is a deleted property. I have removed the statement using it.

Old versions does not break however: https://commons.wikimedia.org/w/index.php?title=File:Dr_Hjortons_Pulver,_Huskvarna.jpg&oldid=400895266

Cparle renamed this task from PropertyDataTypeLookupException in a file on Commons to PropertyDataTypeLookupException in Files with a deleted property.Apr 8 2020, 3:35 PM
Cparle updated the task description. (Show Details)

Change 587604 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Improve handling of deleted properties

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

The WikibaseMediaInfo extension attempts to determine the data type of every property that's referenced on a given file page. This is done in PHP so that we don't have to make a bunch of API requests in the user's browser. Trying to look up a deleted property causes things to blow up here.

I put a quick patch together to handle this situation a little better.

  1. If the server-side property type lookup fails (i.e. if a property is referenced in statements on a given file page, and later deleted) then set the type to "unsupported"
  2. When the JS on the page first initializes, don't bother replacing server-generated statement panels that correspond to deleted properties with interactive JS widgets; this means the user will at least see some messages about a deleted property and any values that had been attached to it. The user will not be able to edit or delete this panel for the time being, but we can figure out the best way to allow for that in a follow-up.
  3. At the qualifier level, show some kind of "unsupported property" message and don't allow users to edit the values that previously had been set. Currently, removing these qualifiers does not count as a valid "change" from the panel's perspective. But if the user makes other changes and clicks "publish", the qualifiers associated with the deleted property will be removed. This could be improved, obviously.

Here are some screenshots of what the user would see in such a scenario.

Screen Shot 2020-04-08 at 3.26.13 PM.png (856×1 px, 120 KB)

Screen Shot 2020-04-08 at 3.26.24 PM.png (796×1 px, 92 KB)

Change 587736 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/WikibaseMediaInfo@master] Allow deleted properties

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

Change 587604 abandoned by Eric Gardner:
Improve handling of deleted properties

Reason:
abandoning in favor of this fix: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/ /587736

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

Change 587736 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Allow deleted properties

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

CCing @Multichill, who deleted the property in question. Even if the error is handled better in WikibaseMediaInfo in the future, I figure the property deletion process should have included a haswbstatement search on Commons, not only checking that it wasn’t used anymore on Wikidata.

CCing @Multichill, who deleted the property in question. Even if the error is handled better in WikibaseMediaInfo in the future, I figure the property deletion process should have included a haswbstatement search on Commons, not only checking that it wasn’t used anymore on Wikidata.

Thanks for tagging, but this is something the software should just be able to handle. The software should assume things get deleted and should have tests to confirm it works when something is deleted. So no, any wiki using data from Wikidata should right their software in a way that it can handle the fact that stuff gets deleted. We probably need to be doing a round of checking and awareness. Having exceptions like this in production is not really my preferred way of raising awareness, but it's probably quite effective.

Note in the future Wikidata property may be used in non-Wikimedia Wikibase installations.

Ramsey-WMF claimed this task.
Ramsey-WMF subscribed.

Works on production as Eric described