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)

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:

    function move( $target ) {
        wfDebugLog( 'imagemove', "Got request to move {$this->name} to " . $target->getText() );
        $this->lock(); // begin

        $batch = new NSLocalFileMoveBatch( $this, $target );
        $batch->addCurrent();
        $batch->addOlds();

        $status = $batch->execute();
        wfDebugLog( 'imagemove', "Finished moving {$this->name}" );

        $this->purgeEverything();
        $this->unlock(); // done

        if ( $status->isOk() ) {
            // Now switch the object
            $this->title = $target;
            // Force regeneration of the name and hashpath
            unset( $this->name );
            unset( $this->hashPath );
            // Purge the new image
            $this->purgeEverything();
        }

        return $status;
    }

And add the class NSLocalFileMoveBatch:

class NSLocalFileMoveBatch extends LocalFileMoveBatch{
	
   function __construct( File $file, Title $target ) {
        $this->file = $file;
        $this->target = $target;
        $this->oldHash = $this->file->repo->getHashPath( $this->file->getName() );
        $this->newHash = $this->file->repo->getHashPath( $this->target->getDBkey() );
        $this->oldName = $this->file->getName();
        $this->newName = $this->file->repo->getNameFromTitle( $this->target );
        $this->oldRel = $this->oldHash . $this->getOldName();
        $this->newRel = $this->newHash . $this->getNewName();
        $this->db = $file->repo->getMasterDb();
    }
    
    function getOldName(){
    	
        return $this->getFileNameStripped( $this->oldName );
    }
    
    function getNewName(){
        
        return $this->getFileNameStripped( $this->newName );
    }
    
    /** Strip namespace (if any) from file name */
    function getFileNameStripped($suffix) {
    	
        $bits = explode( ':', $suffix );
        return $bits[ count( $bits ) -1 ];
    }
    
    
}

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

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)

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

private function checkPermissionHooks( $action, $user, $errors, $doExpensiveQueries, $short ) {
		// Use getUserPermissionsErrors instead
		$result = '';
		if ( !wfRunHooks( 'userCan', array( &$this, &$user, $action, &$result ) ) ) {
			return $result ? array() : array( array( 'badaccess-group0' ) );
		}
		
                .
                .
                .

		return $errors;
	}

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:

function NSFileRepolockdownUserCan( $title, $user, $action, &$result) {
	global $wgWhitelistRead;
	if ( in_array( $title->getPrefixedText(), $wgWhitelistRead ) ) {
		return true;
	} elseif( function_exists( 'lockdownUserPermissionsErrors' ) ) {
		if( $title->getNamespace() == NS_FILE ) {
			$ntitle = Title::newFromText( $title->mDbkeyform );
			$ret_val = ( $ntitle->getNamespace() < 100 ) ?
				true : lockdownUserPermissionsErrors( $ntitle, $user, $action, $result );
			$result = null;
			return $ret_val;
		}
	}
	return true;
}

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)

I installed 1.23.9, 1.24.2 and 1.25.1 to see where the problem starts. 1.23.9 seems to be the last version working correctly. --C holtermann (talk) 14:21, 5 August 2015 (UTC)

I created a task about this on phabricator: https://phabricator.wikimedia.org/T108038 --C holtermann (talk) 16:28, 5 August 2015 (UTC)

img_auth.php authorization doesn't work: easy patch

NSFileRepo's current version doesn't properly set the $title back in img_auth.php, at least on MW 1.23.4. This is because it takes the $title parameter by value, not by reference, so the file name mangling done by NSFileRepoImgAuthCheck never makes it back to img_auth.php and so never makes it into the userCan hook. The fix is simple: add an ampersand to $title in NSFileRepoImgAuthCheck's definition so it takes $title by reference.

function NSFileRepoImgAuthCheck( $title, $path, $name, $result )

becomes

function NSFileRepoImgAuthCheck( &$title, $path, $name, $result )

--66.162.23.2 22:51, 9 November 2015 (UTC)

This should be fixed in current verions --Osnard (talk) 11:10, 21 December 2015 (UTC)

Internal Error UserHooks::handle

I have downloaded the extension into the correct folder and put wfLoadExtension( 'NSFileRepo' ); at the end of LocalSettings.php.

then i get this error message: (... is my wikis starting directory) MWException from line 176 of ...\includes\Hooks.php: Invalid callback NSFileRepo\Hooks\UserCan::handle in hooks for userCan

Backtrace:

1. 0 ...\includes\Title.php(2049): Hooks::run(string, array)
2. 1 ...\includes\Title.php(2492): Title->checkPermissionHooks(string, User, array, string, boolean)
3. 2 ...\includes\Title.php(1896): Title->getUserPermissionsErrorsInternal(string, User, string, boolean)
4. 3 ...\extensions\BlueSpiceExtensions\SaferEdit\SaferEdit.class.php(315): Title->userCan(string)
5. 4 [internal function]: SaferEdit->onBeforeInitialize(Title, NULL, OutputPage, User, WebRequest, MediaWiki)
6. 5 ...\includes\Hooks.php(195): call_user_func_array(array, array)
7. 6 ...\includes\MediaWiki.php(181): Hooks::run(string, array)
8. 7 ...\includes\MediaWiki.php(745): MediaWiki->performRequest()
9. 8 ...\includes\MediaWiki.php(519): MediaWiki->main()
10. 9 ...\index.php(43): MediaWiki->run()
11. 10 {main}

Help?

Restrict File upload/edit to only the creator of a page - Use mediawiki as a file repository

Hi, I would like to have the original creators of a page (not just their user page, but any page they create) to also own and be the only ones who can upload and edit files that are associated with that page. Essentially I would like to have pages in mediawiki have a tab at the top (similar to the page, discussion tab) that will also have a 'files' tab, similar to a repository, with read/write access only to the owner of the page, and the ability for that owner to assign edit rights to others. Would that be possible with this extension? Thank you MavropaliasG (talk) 09:33, 4 December 2019 (UTC)

upgrade to 1.34?

I love this extension - super useful.

Is anyone interested in upgrading it to work with 1.34 (or helping me to do it)? At present there are some deprecated function calls in the plugin, hence the question. Apologies, this isn't true. It does work in 1.34, although I'm having trouble with the 'set file namespace' action on a file. I just use the 'move' action now.

Some NS not available when uploading but can move files to them

That is interesting, I am also having a maybe related problem. I have wgExtraNamespaces 100~155 defined with various settings and permissions, all are working as expected. For some unknown reason which escapes me, only 104,106,108 do not show up in the available target namespaces when uploading a file. So I uploaded it to a different namespace, and then move it to the one which was not available during the upload, and it seems to work fine there. I'm sort of at loss and do not see any difference between the ones which do and those that do not show up in that upload NS Selection drop down. Though maybe there was a limit and it dropped a few or something. Anyway, don't really have any better troubleshooting information. I'm wondering if the "Target file name in namespace" field can be editable, and then it might work if I just manually enter the name of the Namespace which is not listed in the menu drop down? Maybe someone will have an idea? --D0li0 (talk) 04:46, 28 May 2021 (UTC)

Does this work with AWS S3?

Does this play nice with the S3 extension? MyWikis-JeffreyWang (talk) 20:10, 24 April 2021 (UTC)

After Installing NSFileRepo facing issues with opening Images

Hi ,

I have installed NSFileRepo-REL1_35-22b6bf0.tar.gz extension in the mediawiki 1.35.3 and after installation i can save the file with Private Namespace and i can link that image in a page. But the issue is whenever i try to open those images from document page, those images is coming as a broken image with the error message "Sorry, the file cannot be displayed". And, when i tried to open those image by disabling the NSFileRepo extension the issue is not occurred.

When we tries to open the image(from a document page), the image URL is coming without the Namespace. Can anyone help on this issue ? Boopalag (talk) 14:07, 17 August 2022 (UTC)

Issue with MP4 File Preview and Thumbnail Generation

I'm encountering an issue with the NSFileRepo extension on MediaWiki 1.39.4 using NSFileRepo version 2.0.8 and the nsfr_img_auth.php script. MP4 files uploaded after installing the extension can't be previewed, and no thumbnails are generated. Files uploaded before installing NSFileRepo work fine, with previews and thumbnails displaying correctly. The files are not in any special file namespace.

Is this a known issue, or is there a configuration step that I missed? Any advice would be appreciated. --Gzombiejun (talk) 11:57, 8 September 2024 (UTC)