Extension talk:NSFileRepo

NSFileRepo compatible with MW 1.13 - Image/File Namespace
I was having trouble making NSFileRepo work correctly with MW 1.13 and then noticed that the "File" namespace is not included in the MediaWiki core code until MW 1.14. The following changes need to be made to NSFileRepo.php to make the extension work correctly with MW 1.13.

I hope this can help someone.

--Dgennaro 17:17, 12 March 2010 (UTC)

RE:NSFileRepo compatible with MW 1.13 - Image/File Namespace --jdpond 12:56, 3 April 2010 (UTC)
From the 1.14 release notes: "The constants NS_FILE and NS_FILE_TALK can now be used instead of NS_IMAGE and NS_IMAGE_TALK. The old constants are retained as aliases for compatibility, and should still be used in code meant to be compatible with v1.13 or older."

I see no reason not to use NS_IMAGE for compatibility and will change the trunk code with the next update. A word of caution - there may be some other significant security reasons NOT to use <1.13 which have nothing to do with this extension!

Using protected namespaces > 1000
The custom protected namespaces that we have implemented are assigned to NS numbers greater than 1000. In doing this we had to make a slight modification to the NSFileRepo.php file, lines 268 and 269. Is there any foreseeable issue in using namespaces greater than 999?

--Dgennaro 18:59, 2 April 2010 (UTC)

Using protected namespaces > 1000 --jdpond 12:43, 3 April 2010 (UTC)

 * Thanks! I hadn't considered using using NS > 1000, but I can think of no good reason why they shouldn't be.  The problem with the above approach is that it would not allow NS's from 100-999 and might cause backward compatibility issues.  Testing for a length of 3 was an efficient way of testing the hashed URI to see if NSFileRepo was being used.  I think the following would give roughly the same results with less performance impact and additionally allow even higher NS values:


 * If you think this will work, I'll test it and put it into SVN.

Using with Semantic Forms
When using NSFileRepo with Extension:Semantic Forms 1.8.3 (not sure about other versions) and I have noticed that a small modification is needed to Semantic Forms' SF_UploadWindow.php file on/around line 422.

If this is not done you will receive and warning message that says that the file was renamed when uploading a file via the upload window. I have found that this message could be confusing to users.

--Dgennaro 17:29, 8 April 2010 (UTC)

Re:Using with Semantic Forms --jdpond 18:02, 8 April 2010 (UTC)
This was a bug that Yoran and I discovered a while back. The current version of Semantic Forms has been corrected and the better patch is:

Issue: Installing NSFileRepo on MW1.16.0beta3
Hi there,

I just recently put together a MW1.16.0beta3 employing extensions particularly geared towards educational purposes. One of the issues I'm dealing with temporarily are authorization of files used throughout the wiki. So I came across extension NSFileRepo. Since extension Lockdown has been recommended it has been installed and works immaculatedly with custom name spaces. In addition, extension Lockdown has been enriched with suggested patches for hiding pages during search activities (special:search or special:allpages).

Although Lockdown by itself works wonderfully extension NSFileRepo does not react on the syntax. For example

define("NS_CUSTOM", 100); define("NS_CUSTOM_TALK", 101); $wgExtraNamespaces[NS_CUSTOM] = "Custom"; $wgExtraNamespaces[NS_CUSTOM_TALK] = "Custom Talk";
 * 1) Definition of Custom Namespaces

require_once( "$IP/extensions/Lockdown/Lockdown.php" ); $wgNamespacePermissionLockdown[NS_CUSTOM]['*'] = array('sysop'); $wgNamespacePermissionLockdown[NS_CUSTOM_TALK]['*'] = array('sysop');
 * 1) Lockdown Definition

require_once("$IP/extensions/NSFileRepo/NSFileRepo.php");
 * 1) NSFileRepo

Then a user with sysop rights tries to include in site Custom:Test Page a file that has been uploaded beforehand by typing  . The file doesn't show up. However, without mentioning name space Custom in between the file is displayed as expected.

Has something been overlooked?

Many thanks! --Stoettner 22:19, 22 June 2010 (UTC)

Back again, just wanted to get back to you and kindly ask if my extension realization is erroneous since I still couldn't manage to get it to work. Any advice? many thanks, --Stoettner 21:37, 8 July 2010 (UTC)

NSFileRepo with MediaWiki 1.14
I'm running MediaWiki 1.14 and encountered a problem with thumbnails when activating NSFileRepo because the thumbnails directory can not be resolved correctly. The reason is, that the 'thumb' zone has not been introduced in 1.14. To resolve this problem, you have to edit the

You have to replace the following line in the function - $path = $this->repo->getZoneUrl('thumb'). '/' . $this->getUrlRel; + $path = $this->repo->getZoneUrl('public'). '/thumb/'. $this->getUrlRel; and the following line in the function - $path = $this->repo->getZonePath('thumb'). '/' . $this->getRel; $path = $this->repo->getZonePath('public'). '/thumb/'. $this->getRel; Furthermore i noticed this change in the  function, but since this is a virtual url, it might not be necessary to change it: - $path = $this->repo->getVirtualUrl. '/thumb/'. $this->getUrlRel; + $path = $this->repo->getVirtualUrl. '/public/thumb/'. $this->getUrlRel;

After this changes NSFileRepo worked fine with 1.14.

- W.stoettinger 10:07, 13 July 2010 (UTC)

SVN locked up at the tame of writing
When trying to download a version, I got the following error:

--Toniher 17:04, 10 December 2010 (UTC)

NSFileRepo for NS_MAIN Files
I was having issues getting NSFileRepo to work for NS_MAIN in Special:Upload. It seemed to work for everything else just fine. What I had to do to fix it was the following:

in Function: NSFileRepolockdownUserCan I changed:

To:

Then all was well. Nothing else seems to have broken as a result.

"Wrong data type for second argument in extensions/NSFileRepo/NSFileRepo.php on line 92"
The following eror is rendered when using this extension in a certain MW/PHP/MySQL combination:


 * "Wrong data type for second argument in extensions/NSFileRepo/NSFileRepo.php on line 92"

The error has been tested in two independent installations having an identical setup, however, differ by the following points:

The extension version deployed is NSFileRepo (Version 1.4). As a result the extension will be deactivated henceforth. Pls inform about a fix to this issue. Many thanks, --Stoettner 12:29, 12 June 2011 (UTC)

Temporary Fix Found: Suppress PHP Warning Message
A simple suppression of this warning in the code of NSFileRepo.php found in folder extensions/NSFileRepo temporarily resolves this ugly warning. To do so add in line 92 an @ sign in front of the function in_array( $title->getPrefixedText. This suppresses the warning message specifically for that function; warnings rendered by other functions remain untouched.

This is the code section including the fix.

* If Extension:Lockdown has been activated (recommend), check individual namespace protection */ function NSFileRepolockdownUserCan( $title, $user, $action, &$result) { global $wgWhitelistRead; if ( @in_array( $title->getPrefixedText, $wgWhitelistRead ) ) { return true; } elseif( function_exists( 'lockdownUserCan' ) ) { if( $title->getNamespace == NS_FILE ) { $ntitle = Title::newFromText( $title->mDbkeyform ); return ( $ntitle->getNamespace < 100 ) ? true : lockdownUserCan( $ntitle, $user, $action, $result ); } } return true; } Although this mitigates the problems I'd like nevertheless to ask for a complete fix. Thanks, --Stoettner 15:18, 12 June 2011 (UTC)


 * If $wgWhitelistRead is not set it is not an array which makes in_array fail (maybe also other situations). There should be a check if it is an array at all. --C holtermann (talk) 00:04, 6 October 2012 (UTC)

Moving / renaming files does not work
When I move respectively rename the page which contains the attachements to another namespace, the files are not moved successfully.

For instance I try to copy the page: File:Example.png to File:Protected_Namespace:Example.png I get the warning:

Warning: rename(C:\inetpub\wwwroot\w\images\/8/8a/Hugo14.png,C:\inetpub\wwwroot\w\images\/103/8/8a/Protected_Namespace:Hugo14.png): The filename, directory name, or volume label syntax is incorrect. (code: 123) in C:\inetpub\wwwroot\w\includes\filerepo\FSRepo.php on line 217

I'm obviously using a IIS Server (Windows NT 6.1 build 7601 (Windows Server 2008 R2 Datacenter Edition Service Pack 1) and PHP 5.3.8.

Mediawiki 1.17 and NSFileRepo 1.4 (latest trunk: r108492)

Am I the only one experiencing this error? Might it be a bug?

Thanks for answers! Tschuliaen (talk) 21:54, 21 March 2012 (UTC)

Re: Moving / renaming files does not work --jdpond (talk) 17:15, 14 May 2012 (UTC)
My apologies, I missed this when it was posted. I can see the syntax problem and will look at trying to correct it in the next couple of days.

Re: Moving / renaming files does not work --jdpond
I'm sorry it took so long for me to take a look at this. I just updated the extension and Chad moved it to GIT for me. I can't replicate this issue after making a couple of minor changes to adapt to the new lockdown in the Trunk version - could you contact me directly?

I've got the same problem. Is a solution existing? --Andreastroeger (talk) 06:36, 18 June 2012 (UTC)

Re: Moving / renaming files does not work --C holtermann (talk) 15:26, 6 October 2012 (UTC)
When I move a file to a protected namespace it's correctly moved to a subdirectory but the filename contains the protected path. For example file abc.png changes to namespace:abc.png. Mediawiki complains that it doesn't find the file anymore. When i manually remove the leading namespace via ftp it works again. Can someone help ?

RE: I found a solution
Add the function move to the class NSLocalFile:

And add the class NSLocalFileMoveBatch:

--Andreastroeger (talk) 10:08, 2 November 2012 (UTC)

Error - Lockdown not installed, but Lockdown is installed
In the newer releases of the Lockdown extension the lockdownUserCan function was removed. In the NSFileRepo.php file it checks to see if the Lockdown extension is installed by looking for the lockdownUserCan function. To fix this error make the following modification to NSFileRepo.php:

This will fix the issue and also check for the lockdown extension. --Dgennaro 21:14, 22 May 2012 (UTC)

You MUST load Extension Lockdown before NSFileRepo
You MUST load Extension Lockdown before NSFileRepo (http://www.mediawiki.org/wiki/Extension:Lockdown).

I write like this：

require_once( "$IP/extensions/Lockdown/Lockdown.php" ); $wgNamespacePermissionLockdown[8]['read'] = array('sysop'); require_once("$IP/extensions/NSFileRepo/NSFileRepo.php");

But it still do not work at all. --Zoglun (talk) 23:38, 12 June 2012 (UTC)

Mediawiki 1.19, Lockdown function lockdownUserCan has changed to lockdownUserPermissionsErrors
The Test for this functions existence has to be changed as mentioned before but it is also being called. So the calls have to be changed, too.

Another thing i changed was nulling the result. In Title.php the checks for userCan hook looks like lockdownUserPermissionsErrors returns some results. So this function turns it to an empty array. Why ? I have no clue. Letting lockdownUserPermissionsErrors return array works on disabling image pages but it leaves normal user pages in protected areas visible. Letting NSFileRepolockdownUserCan empty the result protects both - as far as I can tell.

Finally: C holtermann (talk) 00:01, 6 October 2012 (UTC)

Next Version 1.5 --jdpond (talk) 23:45, 27 February 2013 (UTC)
This started with trying to fix bug 45364, but rapidly grew. This is a major release and I'm trying to make it backward compatible for 1.18, 1.19, 1.20

First, I would like to thank C holtermann and Andreastroeger for the work that they've done and beg them to join this project. I'll help set you up and get started!!!

I'm in final testing now, so if anyone would like to see additional changes/updates, this would be a good time.

(bug 45364)Fixed Moving/rename, synched with core code filerepo updates

This is a major update to incorporate several past changes to the core filerepo modules into the extension and to bring the extension up to current coding and core standards. Specifically:


 * Fixed Move/Relocate issue
 * Updated to use Mediawiki core updates to File and LocalFile repo classes
 * Updated for Documentation (doxygen)
 * Cleared result array for userCan hook (NSFileRepolockdownUserCan) since Title now takes anything in that array to be an affirmative (user can)

Bug: 45364

If anyone has any other suggestions, now's the time!

Re: Next Version 1.5
Thank you very much ! It works very well !

Though I only got it working with the 1.20 branch. In debugging mode I get this message:

Strict‌·StandardsDeclaration‌·of‌·NSOldLocalFile::thumbName‌·should‌·be‌·compatible‌·with‌·that‌·of‌·File::thumbName‌·in‌ /home/www/web344/html/mediawiki-1.20.3/extensions/NSFileRepo/NSFileRepo_body.php‌·on‌·line‌·354

In 1.19.4 I got the message

Fatal error: Undefined class constant 'THUMB_FULL_NAME' in /home/www/web344/html/mediawiki-1.19.4/extensions/NSFileRepo/NSFileRepo_body.php on line 125

C holtermann (talk) 22:09, 7 April 2013 (UTC)

Mediawiki 1.25.1 Images shown only in resized versions
When trying to show/include a whole image that is inside a namespace I get a file not found error. Resized images are being shown without problems. --C holtermann (talk) 10:54, 19 July 2015 (UTC)
 * I went into this a bit. What I find is:
 * The links on the image page to the full size view miss the namespace (I don't know if that's intended). For example on the preview picture there's a link http://wiki.jungmedizinerforum.org/img_auth.php/108/4/41/Waldorfressourcen1.png when I access that I get the error that the file is missing (when in the directory the file 108/4/41/Waldorfressourcen1.png is present). I assume that the link should be to http://wiki.jungmedizinerforum.org/img_auth.php/108/4/41/Akademie:Waldorfressourcen1.png, so that the namespace is include. When I call that URL manually I get a different error message: "

File not found

Although this PHP script (/img_auth.php) exists, the file requested for output (mwstore://local-backend/local-public/108/4 /41/Akademie:Waldorfressourcen1.png) does not.
 * The original error message was produced by in unsuccessful call to LocalFile->loadFromDB. The 2nd one by StreamFile->prepareForStream.
 * It seems like something has changed in the internal file handling structure. --C holtermann (talk) 11:48, 19 July 2015 (UTC)