OutputPage::transformFilePath creates wrong path for logo placed in image upload directory
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Moejoe1337
	Jan 12 2017, 12:20 AM

Description

Okay, this might be a bit of a special situation, as I am using a single MediaWiki installation to serve multiple wikis.
I have a directory containing all of MediaWiki's files /var/www/common, and a directory containing the uploaded files for the wikis, /var/www/wiki1 and /var/www/wiki2 (both containing a subfolder "images"). Those directories are then aliased into the common directory through the Apache configuration.
My logo is placed in the respective upload directories, i.e. its on-disk filenames are /var/www/wiki1/images/logo.png and /var/www/wiki2/images/logo.png respectively.

LocalSettings contains this:

$wgUploadPath = "{$wgScriptPath}/images";
switch ($_SERVER['SERVER_NAME'])
{
    case 'wiki1.example.org':
        $wgUploadDirectory = "/var/www/wiki1/images";
        break;

    case 'wiki2.example.org':
        $wgUploadDirectory = "/var/www/wiki2/images";
        break;
    
    default:
        die('Unknown wiki');
}
$wgLogo = "{$wgUploadPath}/logo.png";

This works - as in, the site displays correctly. However, MediaWiki seems to try to create an MD5 hash of the logo, I suppose for caching purposes. This ends up in my Apache error log:

PHP Warning:  md5_file(/var/www/common/images/logo.png): failed to open stream: No such file or directory in /var/www/common/includes/OutputPage.php on line 3660
PHP Warning:  OutputPage::transformFilePath: Failed to hash /var/www/common/images/logo.png [Called from OutputPage::transformFilePath in /var/www/common/includes/OutputPage.php at line 3662] in /var/www/common/includes/debug/MWDebug.php on line 311

It seems to me that transformFilePath is called incorrectly so that it does not resolve the image path correctly for the logo, while it does for other files (no error is written to the log). I realize that this might be difficult to fix since the logo does not necessarily have to be placed in the upload folder, but a simple fix might be to check if the logo is indeed placed there, and if so, resolve it the same way as uploaded images are.

Details

Related Changes in Gerrit:

	Subject	Repo	Branch	Lines +/-
	OutputPage: Support UploadPath in testTransformResourcePath()	mediawiki/core	master	+79 -13

Customize query in gerrit

Event Timeline

Moejoe1337 created this task.Jan 12 2017, 12:20 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 12 2017, 12:20 AM

Moejoe1337 updated the task description. (Show Details)Jan 12 2017, 12:25 AM

Paladox added projects: MediaWiki-ResourceLoader, MediaWiki-General.Jan 12 2017, 8:49 AM

Paladox subscribed.

Hi @Moejoe1337, thanks for taking the time to report this!
Which MediaWiki version is this about?

This is MediaWiki 1.28.0.

@Moejoe1337 What are the values of $wgResourceBasePath (default: $wgScript), $wgScript and $wgLogo?

$wgResourceBasePath and $wgScript are expected to be an absolute url (or url path) to where the $IP directory is exposed on the web server.

Krinkle triaged this task as Medium priority.Feb 9 2017, 10:21 PM

Krinkle moved this task from Inbox to Backlog on the MediaWiki-ResourceLoader board.

I observed the variable values at the end of LocalSettings.php. Would that be the correct point or is it too early?
$wgResourceBasePath and $wgScript are empty, $wgLogo is /images/logo.png (as can be deducted from the provided example config - $wgScriptPath is empty as I run the wiki at the root directory of the domain).

In T155146#3015133, @Moejoe1337 wrote:

I observed the variable values at the end of LocalSettings.php. Would that be the correct point or is it too early?
$wgResourceBasePath and $wgScript are empty, $wgLogo is /images/logo.png (as can be deducted from the provided example config - $wgScriptPath is empty as I run the wiki at the root directory of the domain).

While root directory installations are discouraged, if you do, at the very least I'd recommend placing the MediaWiki installation in a sub directory. You can still keep permalinks and pretty article path rewritten from the root directory (e.g. example.org/Main_Page but example.org/w/index.php). This will help you reduce and avoid a large class of potential bugs and compatibility problems. https://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory. See also the various warnings on https://www.mediawiki.org/wiki/Manual:Short_URL.

It's also discouraged to place additional files or directories in the MediaWiki installation directory (except in designated locations such as extensions/, skins/, and images/). I suppose in this case the physical files are in fact in the images/ directory, which is supported. I suppose there is a consistency argument for having the same upload path across the various wikis. On the other hand, the urls are fairly hidden and all uses of those directories should use the API or wgUploadPath to discover the paths, which makes it mostly invisible. Your configuration already accommodates for easily making wgUploadPath varying the same way as wgUploadDirectory. That would be my recommendation for the immediate future until the next MediaWiki release.

Given images/ is one of the three directories we do support and have filesystem and url paths registered for, I'll make the fix to try that before falling back to $IP and wgResourceBasePath.

I'm aware of 1., though these wikis have been running for almost a decade without any trouble.
I don't quite understand the second point though. Do you mean that having $wgUploadPath set to e.g. {$wgScriptPath}/images-wiki1/ and {$wgScriptPath}/images-wiki2/ respectively would help here, because the path is no longer named images/?

In T155146#3015253, @Moejoe1337 wrote:

I'm aware of 1., though these wikis have been running for almost a decade without any trouble.
I don't quite understand the second point though. Do you mean that having $wgUploadPath set to e.g. {$wgScriptPath}/images-wiki1/ and {$wgScriptPath}/images-wiki2/ respectively would help here, because the path is no longer named images/?

@Moejoe1337 Kind of. I assumed your original upload base directory would also be exposed over the web, but I see now that that is probably not true. E.g. images/wiki1/ and images/wiki2/ inside your /var/www/common/.

The upload directory is actually exposed to the web as (wiki1|wiki2).example.org/images. Depending on the host, one of the two source directories is aliased by Apache (e.g. Alias /images /var/www/wiki1/images)

Change 336941 had a related patch set uploaded (by Krinkle):
OutputPage: Support UploadPath in testTransformResourcePath()

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

gerritbot added a project: Patch-For-Review.Feb 10 2017, 12:03 AM

Krinkle moved this task from Backlog to Confirmed Problem on the MediaWiki-ResourceLoader board.Feb 10 2017, 12:03 AM

In T155146#3015351, @Moejoe1337 wrote:

The upload directory is actually exposed to the web as (wiki1|wiki2).example.org/images. Depending on the host, one of the two source directories is aliased by Apache (e.g. Alias /images /var/www/wiki1/images)

Yeah, but I assume the base directory in common between the different upload directories (/var/www/) is not exposed currently. Otherwise one could have example.org/images/wiki1/ or elsewhere like uploads.example.org/images/wiki1/. Grouping things per-wiki on the hard drive (wiki1/config, wiki1/images, etc.) instead of per-purpose (config/wiki1, images/wiki1) are both common approaches. Though for larger wiki farms the latter (per-purpose) tends to be more common as it allows for shared infrastructure and security restrictions (e.g. user uploads could be on a dedicated disk, and may be served to the web from a separate sub domain for performance and security reasons as being cookie-less).

Anyhow, per-wiki is just as valid and a patch is now pending review!

Thanks for taking care of it! :)

Change 336941 merged by jenkins-bot:
OutputPage: Support UploadPath in testTransformResourcePath()

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

ReleaseTaggerBot added projects: MW-1.29-release-notes, MW-1.29-release (WMF-deploy-2017-02-14_(1.29.0-wmf.12)).Feb 11 2017, 6:00 AM

Krinkle closed this task as Resolved.Feb 25 2017, 12:32 AM

Krinkle claimed this task.

Krinkle edited projects, added Performance-Team; removed Patch-For-Review.