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)