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.

- $title = Title::makeTitle( NS_FILE, $row->img_name );
+ $title = Title::makeTitle( NS_IMAGE, $row->img_name );

- $title = Title::makeTitle( NS_FILE, $row->oi_name );
+ $title = Title::makeTitle( NS_IMAGE, $row->oi_name );

- if($title->getNamespace() == NS_FILE) {
+ if($title->getNamespace() == NS_IMAGE) {

- $title = Title::makeTitleSafe( NS_FILE, $wgContLang->getNsText($subdirs[$x]).":".$name );
+ $title = Title::makeTitleSafe( NS_IMAGE, $wgContLang->getNsText($subdirs[$x]).":".$name );

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?

- $x = (strlen($subdirs[1]) <> 3 && ($subdirs[1] == "archive" || $subdirs[1] == "deleted" || $subdirs[1] == "thumb")) ? 2 : 1;
+ $x = (strlen($subdirs[1]) <> 4 && ($subdirs[1] == "archive" || $subdirs[1] == "deleted" || $subdirs[1] == "thumb")) ? 2 : 1;

- if (strlen($subdirs[$x]) == 3 && is_numeric($subdirs[$x]) && $subdirs[$x] >= 100)  {
+ if (strlen($subdirs[$x]) == 4 && is_numeric($subdirs[$x]) && $subdirs[$x] >= 100)  {

--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:

- $x = (strlen($subdirs[1]) <> 3 && ($subdirs[1] == "archive" || $subdirs[1] == "deleted" || $subdirs[1] == "thumb")) ? 2 : 1;
+ $x = (!is_numeric($subdirs[1]) && ($subdirs[1] == "archive" || $subdirs[1] == "deleted" || $subdirs[1] == "thumb")) ? 2 : 1;

- if (strlen($subdirs[$x]) == 3 && is_numeric($subdirs[$x]) && $subdirs[$x] >= 100)  {
+ if (strlen($subdirs[$x]) >= 3 && is_numeric($subdirs[$x]) && $subdirs[$x] >= 100)  {

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.

- $filtered = preg_replace ( "/[^".Title::legalChars()."]|:/", '-', $filtered );
+ $filtered = preg_replace ( "/[^".Title::legalChars()."]/", '-', $filtered );

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:

- $filtered = preg_replace ( "/[^".Title::legalChars()."]|:/", '-', $filtered );
+ $filtered = wfStripIllegalFilenameChars ( $filtered );

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

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

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

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

Then a user with sysop rights tries to include in site Custom:Test Page a file that has been uploaded beforehand by typing [[File:Custom:sun.jpg]]. 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 NSFileRepo.php

You have to replace the following line in the function getThumbUrl

- $path = $this->repo->getZoneUrl('thumb') . '/' . $this->getUrlRel();
+ $path = $this->repo->getZoneUrl('public') . '/thumb/' . $this->getUrlRel();

and the following line in the function getThumbPath

- $path = $this->repo->getZonePath('thumb') . '/' . $this->getRel();
$path = $this->repo->getZonePath('public') . '/thumb/' . $this->getRel();

Furthermore i noticed this change in the getThumbVirtualUrl 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:

svn: Working copy '/mnt/upload6/private/ExtensionDistributor/mw-snapshot/branches/REL1_16/extensions/NSFileRepo/REL1_14_0/phase3/includes' locked

svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) --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:

               if($title->getNamespace() == NS_FILE) {
                       $ntitle = Title::newFromText($title->mDbkeyform);
                       return ($ntitle->mNamespace < 100) ? true : lockdownUserCan($ntitle, $user, $action, $result);
               }

To:

               if($title->getNamespace() == NS_FILE) {
                       $ntitle = Title::newFromText($title->mDbkeyform);
                       return (($ntitle->mNamespace < 100) && ($ntitle->mNamespace > 0)) ? true : lockdownUserCan($ntitle, $user, $action, $result);
               }

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

"Wrong data type for second argument in <server path>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 <server path>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:

component	no error	error
MW version	1.16.2	1.16.2
PHP version	5.2.14 (litespeed)	5.2.17 (apache2handler)
MySQL version	5.0.91-community	5.1.49-3~bpo50+1-log

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.

line	original	change
92	if ( in_array( $title->getPrefixedText(), $wgWhitelistRead ) ) {	if ( @in_array( $title->getPrefixedText(), $wgWhitelistRead ) ) {

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)

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.

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:

line 25
- if (!function_exists('lockdownUserCan'))...
+ if (!function_exists('lockdownUserPermissionsErrors'))...

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