Page MenuHomePhabricator

InstantCommons no longer working in MediaWiki-Vagrant multimedia role
Closed, ResolvedPublic

Description

InstantCommons does not work on Vagrant if you enable the 404 handler for images (the thumb_on_404 role does that and most multimedia roles include it). The problem is related to thumbnail caching; similar to T101565, but the default wiki (127.0.0.1) is also affected.

As a workaround, caching can be disabled by creating /vagrant/settings.d/10-DisableThumbnailCaching.php with

<?php
$wgUseInstantCommons = false;
$wgForeignFileRepos[] = array(
	'class' => 'ForeignAPIRepo',
	'name' => 'wikimediacommons',
	'apibase' => 'http://commons.wikimedia.org/w/api.php',
	'fetchDescription' => true,
	'descriptionCacheExpiry' => 0,
	'apiThumbCacheExpiry' => 0,
);

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:53 AM
bzimport set Reference to bz54202.
bzimport added a subscriber: Unknown Object (MLST).

Oddly, if I insert an image from Commons through VisualEditor it appears to work ok inline.

If I insert one in source, I get "Error creating thumbnail: Invalid thumbnail parameters".

whaaaaaat?

This is a known issue of using thumb.php directly instead of from a 404 handler. (Not sure how "known" in any case, not new)

Workaround:

<?php
$wgUseInstantCommons = false;
$wgForeignFileRepos[] = array(

'class' => 'ForeignAPIRepo',
'name' => 'wikimediacommons',
'apibase' => 'http://commons.wikimedia.org/w/api.php',
'fetchDescription' => true,
'descriptionCacheExpiry' => 0,
'apiThumbCacheExpiry' => 0,

);

I started to track this down some weeks ago but ran out of time and had to give up. The issue was MediaWiki getting confused about which local directory to use for the thumb cache IIRC.

Bawolff: I could reproduce this with the multimedia vagrant role enabled, which in theory should enable 404-based image handling.

I can confirm that Gergo's workaround does the trick, even for a Vagrant newbie like me.

So even if we can't fix this in code right away, at least we have a solution for making this work temporarily.

Thanks for this!

In the latest MediaWiki Vagrant with the multimedia role enabled, InstantCommons does not successfully generate thumbnails for me. The issue goes away if I comment out the thumb-php-on-404 handler, so I suspect it's an issue with the rewrite rule. CCing Bryan since he wrote that template.

Bulk unassigning bugs from Ori.

bd808 changed the task status from Open to Stalled.Dec 30 2014, 2:00 AM
bd808 triaged this task as Low priority.

Enabling the multimedia role on a fresh MW-Vagrant box still produces broken thumbnails for me. ("Error generating thumbnail: The source file 'XXX' does not exist.")

Same for me. This is actually impacting my ability to code review certain changes... :-/

Jdlrobson renamed this task from InstantCommons no longer working in MediaWiki-Vagrant multimedia role to InstantCommons no longer working in MediaWiki-Vagrant multimedia role or wikidata/wikigrok role.Jun 23 2015, 7:29 PM
Jdlrobson awarded a token.
Jdlrobson set Security to None.
Jdlrobson added subscribers: gerritbot, Sumit.
Tgr renamed this task from InstantCommons no longer working in MediaWiki-Vagrant multimedia role or wikidata/wikigrok role to InstantCommons no longer working in MediaWiki-Vagrant multimedia role.Jun 23 2015, 8:14 PM
Tgr updated the task description. (Show Details)
Tgr updated the task description. (Show Details)
Tgr claimed this task.

Can't reproduce this anymore. https://gerrit.wikimedia.org/r/217769 might have fixed it.

Still (or again) broken. Commons API is used without a problem, the image is thumbnailed, but Apache redirects the request to thumb.php even though the thumbnail exists and seems to be in the right place. (thumb.php cannot handle remote images, that's T27958.)

Contents of /etc/apache2/site-confs/devwiki/50-thumb-php-on-404.conf:

RewriteEngine On

# call thumb.php for thumb images not on disk
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/[^/]*([0-9]+)px-.*$ /w/thumb_handler.php [PT,QSA,B]


# call thumb.php for thumb archive images not on disk
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/[^/]*([0-9]+)px-.*$ /w/thumb_handler.php [PT,QSA,B]

Contents of /etc/apache2/site-confs/devwiki/50-devwiki-images.conf:

# vim: filetype=apache sts=4 sw=4 autoindent
#
# This file is managed by Puppet.
#
<Directory /srv/images>
    Require all granted
    Header set Access-Control-Allow-Origin "*"
</Directory>

Alias /images /srv/images

Apache log with LogLevel alert rewrite:trace6:

Jul  7 23:56:57 mediawiki-vagrant apache2[6545]: [rewrite:trace2] [pid 6545] mod_rewrite.c(468): [client 10.0.2.2:56986] 10.0.2.2 - - [127.0.0.1/sid#7f720dfb0bb8][rid#7f720decc0a0/initial] init rewrite engine with requested uri /images/thumb/b/b0/Sunrise_over_fishing_boats_in_Kerala.jpg/800px-Sunrise_over_fishing_boats_in_Kerala.jpg, referer: http://127.0.0.1:10000/wiki/File:Sunrise_over_fishing_boats_in_Kerala.jpg
Jul  7 23:56:57 mediawiki-vagrant apache2[6545]: [rewrite:trace3] [pid 6545] mod_rewrite.c(468): [client 10.0.2.2:56986] 10.0.2.2 - - [127.0.0.1/sid#7f720dfb0bb8][rid#7f720decc0a0/initial] applying pattern '^/$' to uri '/images/thumb/b/b0/Sunrise_over_fishing_boats_in_Kerala.jpg/800px-Sunrise_over_fishing_boats_in_Kerala.jpg', referer: http://127.0.0.1:10000/wiki/File:Sunrise_over_fishing_boats_in_Kerala.jpg
Jul  7 23:56:57 mediawiki-vagrant apache2[6545]: [rewrite:trace3] [pid 6545] mod_rewrite.c(468): [client 10.0.2.2:56986] 10.0.2.2 - - [127.0.0.1/sid#7f720dfb0bb8][rid#7f720decc0a0/initial] applying pattern '^/images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/[^/]*([0-9]+)px-.*$' to uri '/images/thumb/b/b0/Sunrise_over_fishing_boats_in_Kerala.jpg/800px-Sunrise_over_fishing_boats_in_Kerala.jpg', referer: http://127.0.0.1:10000/wiki/File:Sunrise_over_fishing_boats_in_Kerala.jpg
Jul  7 23:56:57 mediawiki-vagrant apache2[6545]: [rewrite:trace4] [pid 6545] mod_rewrite.c(468): [client 10.0.2.2:56986] 10.0.2.2 - - [127.0.0.1/sid#7f720dfb0bb8][rid#7f720decc0a0/initial] RewriteCond: input='/images/thumb/b/b0/Sunrise_over_fishing_boats_in_Kerala.jpg/800px-Sunrise_over_fishing_boats_in_Kerala.jpg' pattern='!-f' => matched, referer: http://127.0.0.1:10000/wiki/File:Sunrise_over_fishing_boats_in_Kerala.jpg
Jul  7 23:56:57 mediawiki-vagrant apache2[6545]: [rewrite:trace4] [pid 6545] mod_rewrite.c(468): [client 10.0.2.2:56986] 10.0.2.2 - - [127.0.0.1/sid#7f720dfb0bb8][rid#7f720decc0a0/initial] RewriteCond: input='/images/thumb/b/b0/Sunrise_over_fishing_boats_in_Kerala.jpg/800px-Sunrise_over_fishing_boats_in_Kerala.jpg' pattern='!-d' => matched, referer: http://127.0.0.1:10000/wiki/File:Sunrise_over_fishing_boats_in_Kerala.jpg
Jul  7 23:56:57 mediawiki-vagrant apache2[6545]: [rewrite:trace2] [pid 6545] mod_rewrite.c(468): [client 10.0.2.2:56986] 10.0.2.2 - - [127.0.0.1/sid#7f720dfb0bb8][rid#7f720decc0a0/initial] rewrite '/images/thumb/b/b0/Sunrise_over_fishing_boats_in_Kerala.jpg/800px-Sunrise_over_fishing_boats_in_Kerala.jpg' -> '/w/thumb_handler.php', referer: http://127.0.0.1:10000/wiki/File:Sunrise_over_fishing_boats_in_Kerala.jpg
Jul  7 23:56:57 mediawiki-vagrant apache2[6545]: [rewrite:trace2] [pid 6545] mod_rewrite.c(468): [client 10.0.2.2:56986] 10.0.2.2 - - [127.0.0.1/sid#7f720dfb0bb8][rid#7f720decc0a0/initial] forcing '/w/thumb_handler.php' to get passed through to next API URI-to-filename handler, referer: http://127.0.0.1:10000/wiki/File:Sunrise_over_fishing_boats_in_Kerala.jpg

The thumbnail is at /srv/images/thumb/b/b0/Sunrise_over_fishing_boats_in_Kerala.jpg/800px-Sunrise_over_fishing_boats_in_Kerala.jpg. I don't get why the !-f rule matches, somehow the alias does not get applied?

Probably even more broken on other wikis since the 404 handler config rule seems to only be applied to the default wiki (and the one created by the commonswiki role which has its own apache rules).

From the Apache docs:

REQUEST_FILENAME
The full local filesystem path to the file or script matching the request, if this has already been determined by the server at the time REQUEST_FILENAME is referenced. Otherwise, such as when used in virtual host context, the same value as REQUEST_URI. Depending on the value of AcceptPathInfo, the server may have only used some leading components of the REQUEST_URI to map the request to a file.

So apparently the problem is that Apache does not map the URI to the filesystem path before checking whether the file exists. If I disable the rewrite rule, the thumbnail appears correctly.

Change 223477 had a related patch set uploaded (by Gergő Tisza):
Fix thumb rewrite rules

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

Change 223480 had a related patch set uploaded (by Gergő Tisza):
Use 404 handler for all wikis when the role is enabled

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

Change 223493 had a related patch set uploaded (by BryanDavis):
Fix thumb on 404 role for multiwiki reality

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

Change 223477 merged by jenkins-bot:
Fix thumb rewrite rules

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

Change 223493 merged by jenkins-bot:
Fix thumb on 404 role for multiwiki reality

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

Change 223480 abandoned by Gergő Tisza:
Use 404 handler for all wikis when the role is enabled

Reason:
There doesn't seem to be a way to do this correctly.

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

@Tgr is this still an ongoing problem?

IIRC yes but much harder to trigger than it used to be. But I'm may be wrong - I only vaguely remember what this was about.

Please reopen or file a new bug if you can reproduce.