Extension talk:LocalS3Repo

Hi there, Im Getting an Parse error: syntax error, unexpected T_CLASS in MY-PATH line number.

It's complaining about this part 'class' => 'LocalS3Repo',

How can I fix this?

What version of Mediawiki, Linux/Windows, etc, do you have? Where exactly does the error show up? --Ejcaputo 09:52, 9 December 2010 (UTC)

Hello, I'm getting the following error:
 * CURLOPT_FOLLOWLOCATION cannot be activated when safe_mode is enabled or an open_basedir is set in /f5/blah/public/extensions/LocalS3Repo/S3.php on line 1256

My host runs in safe mode, is there any way I can edit the script to make it work? A possible solution is provided here, but I'm not really sure what to do with that code to make this work. The file still seems to be uploaded to S3 but a bunch of errors come when uploading the file. Running Mediawiki 1.16.1. Thanks. ~d

Hmmm. That (S3.php) is a standard library... there is a comment about that problem here: http://drupal.org/node/665256

Posted by mike dodd on February 2, 2010 at 9:57am I can confirm with this line commented out everything works fine. not sure if will still work with the line in though? There are various versions of S3.php around, here's one which doesn't use that option: http://www.coreysconsulting.com/projects/s3scripts/asHtml/S3.php - but I didn't try it....

--Ejcaputo 10:30, 25 January 2011 (UTC)

I just tried using that S3.php file you linked to but now I am unable to reach the upload page. I get the following error:
 * Fatal error: Call to undefined method S3::setAuth in /f5/blah/public/extensions/LocalS3Repo/FSs3Repo.php on line 26

I then tried commenting out the FOLLOWLOCATION line as mentioned above and that seems to get rid of the one error, but now I have another error:
 * SAFE MODE Restriction in effect. The script whose uid/gid is ####/#### is not allowed to access /var/tmp/ owned by uid/gid 0/0 in /f5/blah/public/extensions/LocalS3Repo/LocalS3File.php on line 612

Any ideas on this? ~d

Realized that I forgot to mention that the script seems to work (images are uploaded and can be embedded), it just happens to display those errors as well. Is it possible to just comment out the code that is generating those errors or otherwise hide them? ~d

This extension seems to be broken when using MediaWiki 1.17. Any thoughts on how it might be updated to work with that version?

When 1.17 is stable, I'll look at making it work. --Ejcaputo 17:12, 29 March 2011 (UTC)

Now that 1.17 is stable (and 1.17.1 is out), any chance you can update this extension? --cmoo92 17:32, 01 December 2011 (UTC)

Temp files
I just noticed that my /tmp directory is full of s3file-* and s3thumb-* files dating back to when I started using this extension. Can those be deleted? Is this something that the extension should be taking care of but is failing? &mdash;184.106.130.93 13:20, 31 March 2011 (UTC)

I see this too (Im on MW 1.15). It is caused by the extension calling S3::putObject but NOT deleting the file on-disk after the put. In some calls, the code does delete the file in /tmp but in many cases it does not. As well, the extension calls transform which creates the thumbnail - this leaves a bunch of files (0 bytes in length) in /tmp as well. I addressed the problem with this hook code:

function uploadCompleteHook(&$image) { $mask = wfTempDir. "/s3*"; // wfTempDir is '/tmp' on the Mac and Heroku Logger::debug("uploadCompleteHook called, removing files with mask $mask"); array_map('unlink', glob( $mask ) ); return true; } $wgHooks['UploadComplete'][]='uploadCompleteHook';

NOTE: this is called after the file is uploaded to the server but BEFORE the file is created in /tmp (and before its transferred to S3 by the extension). Thus, this hook will just delete temp files from a previous upload. This is likely A-OK since 1 set of files isnt going to fill /tmp.

Another note: the actual uploaded http files are put in the http upload directory (as defined by the upload_tmp_dir setting in php.ini - which defaults to /var/tmp on my Mac) and has nothing to do with this extension. Note though, the http upload code does delete its temp files.

Integration with 1.17, 1.18
This is such an important extension to be left alone. Any integration for >1.17 and 1.18 to make it use resourceloader?