Page MenuHomePhabricator

[SMW] 1.6.1 to 1.7 regressions break image queries, image query functionality degrading to be inadequate, and (1.7) make raw image file data inaccessible
Closed, ResolvedPublic

Description

In 1.5.6, queries for images would return the image thumbnail, in the standard mediawiki size. In 1.6, image queries would return the thumbnail and the file name. In 1.6.1, image queries return the two copies of the thumbnails and the file names, as well as wrapping them in a table.

The two result copies is clearly a bug. The other extraneous info such as the filename and tabulated results should be optional. SMW 1.6.1 does not give sufficient control over image query results to make them useful, and indeed, regressively breaks the functionality that used to exist to the point that it may not be useful at all anymore.

I cannot obtain a single specific image thumbnail result anymore.


Version: unspecified
Severity: normal

Details

Reference
bz30494

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:49 PM
bzimport set Reference to bz30494.

Confirmed.

Change was made here: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticMediaWiki/includes/datavalues/SMW_DV_WikiPage.php?r1=88572&r2=88864

What's your usecase? The change seems valid to me, so it's a wontfix unless there are usecases where the new behavior is not acceptable.

Just had some discussion w/ Markus. Current behavior is indeed not what we want. Will have a look at this soonish.

The use case is there are images that belong to some particular page. When uploading, users select from various attributes to specify what the image shows. Then, on the page where they belong, queries produce the correct images for whatever area of the page the image is supposed to appear. For example, images can be of the front, back, or a close up detail. Some images are designated as the "main" images for whatever type they are, and are shown at the top of pages.

Basically, since images aren't integral to a page per se (they have their own pages), I'm using SMW to assemble the images in their relevant topic pages.

In queries of those topic pages, a single "main" image may be shown to allow quick visual skimming of results.

I'm making use of SMW with files. Most of what I'm trying to do would be straightforward with anything but files, but for files, it requires a lot of workarounds. I think files in general need a bit more attention. Here's another bug about files:

https://bugzilla.wikimedia.org/show_bug.cgi?id=30034

Although there is a workaround for that bug, and it was closed because it was doable, I think workarounds out to become goals for improvement such that they're no longer necessary. Most of the shortcomings that are immediately fixable are in files.

The other shortcomings are in queries, which seem to be limited by the capabilities of MySQL, and so need a SPARQL database to resolve.

Being fairly straightforward to improve, I think files/images should get a bit more development priority than they normally do. They're very useful for making lots of query results easy to navigate quickly just by looking at them, in addition to other uses like automatically populating page sections with relevant images in one step (the file upload step).

I have now fixed the image display behaviour in SVN. Image: values will now appear as in 1.5.6 again (as images without any additional text) and Media: values will always appear as links. In either case, one can use the format "-" to get the plain target page name only, as in

{{#ask: [[Category:Person]]

?profile picture#-

}}

Also, image annotations will now preserve image formatting. For example, you can do something like

[[profile picture::Image:mypic.jpg|text-top|120px]]

on a page. Earlier, image annotations would always display as links, so some pages may need adjustments now. But it is much more consistent if MediaWiki links with property annotations display like MediaWiki links without the property in such cases.

It could be possible to provide output formats like "text-top|120px" as part of the printout in queries as well, but we cannot use | there since it already has a meaning. If there was some syntax to use, then it would be possible to allow more image formatting in query printouts. But this would be another feature request. Closing this now.

This has regressed further in SMW 1.7, in a different way:

It is no longer possible to get just the file name data output from a query, so the image data can be processed further.

No additional processing of images is reliably possible as far as I can tell, because SMW forcibly does presentation of the image data as a display of the image file, thereby making it inaccessible for any other use besides SMW's display.

Other newly introduced bugs have made it impossible to reliably workaround using the list format:

https://bugzilla.wikimedia.org/show_bug.cgi?id=32863

and the array format:

https://bugzilla.wikimedia.org/show_bug.cgi?id=32977

I renamed this bug to accommodate the new degradations in 1.7

Actually, it looks like there was an undocumented change in the output format of query results. I'm marking this fixed again, while I do more testing.

Here's some info about the change that I posted to the mailing list, for anybody that runs across this bug report while looking for answers:

http://wikimedia.7.n6.nabble.com/Semantic-Result-Formats-1-7-released-td2799845.html#a3504612