Scripto getimagesize error

Hi all,

Can someone decipher this for me - I can see the image isn’t displaying for the transcription and the warning says:

Warning: getimagesize([localurl]/omeka/files/original/f26ebbc1ff8b627ce708a5ab24a82427.jpg): failed to open stream: HTTP request failed! HTTP/1.1 401 Unauthorized in /var/www/vhosts/[localurl]/httpdocs/omeka/plugins/Scripto/ScriptoPlugin.php on line 402

What should I change in the URLs and where should I change it?

It looks like your server isn’t configured to allow the http scheme for getimagesize. Has OpenLayers worked for you before?

Does your site have Apache-level password checking? That 401 error suggests that it does. Disable that and it may work.

Hi Jim,

Thanks - I’m looking into this right now, but not sure I know what to look for in the conf file. (Also, I run our server through a plesk panel right now, so I rarely go in at command line unless necessary these days, but this seems like I would need to do that.)

I also found the obvious thing I should have looked for before on Wikipedia:

“401 Unauthorized (RFC 7235)
Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication.[33] 401 semantically means “unauthenticated”,[34] i.e. the user does not have the necessary credentials.
Note: Some sites issue HTTP 401 when an IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.”

So, am I looking for an allow_url_fopen setting or something else? I should mention that I have the Omeka directory password-protected via htaccess. I wonder if that’s causing the issue? I can’t really take that down. Maybe there’s a way I could add the username and password to the Scripto file though.

I’ll keep poking around in the meantime, thanks for the suggestions.

Hi Amanda!

Yes, that’s the reason. Since you can’t remove password protection the only way I can figure is to temporarily modify ScriptoPlugin::getImageSize() to use an absolute path to the file instead of the URI. There’s no way to get the abs path from storage, so you’ll need to decompose the URI and hardcode the path to the image dir.

1 Like

This would mean changing the $filename in the main ScriptoPlugin.php file? Or where is $filename set? I didn’t see it in the ini file.

Or perhaps you mean changing
$imageSize = ScriptoPlugin::getImageSize($imageUrl, 250);


Modify the method itself:

That method takes a $filename, which is the file’s web path. You’ll need to transform that URI to an absolute path to the local file. For example, change



Thanks - I presume you mean the reverse based on example, i.e. changing the absolute to a relative path. (Right now it seems to default to the absolute given the error.)

In any case, I’ll work on trying to parse the $filename into a relative path.

I do mean an absolute (full) path from your server’s root directory. Omeka identifies the location of files with URLs, which is why it can’t bypass authentication when getimagesize tries to access the file.

Hi Jim - I finally got around to implementing this (yes it took a while), and although I did what you said, I am getting another error now, e.g.:

“Warning: getimagesize(/omeka/files/original/a04eb5f30c57a8e1a8ac6fae08663cd7.jpg): failed to open stream: No such file or directory in /[localurl]/omeka/plugins/Scripto/ScriptoPlugin.php on line 404”

When I navigate to /omeka/files/original/a04eb5f30c57a8e1a8ac6fae08663cd7.jpg I can see the file without a problem. So it’s definitely just a getimagesize() issue. What does this error mean? I still have the htaccess password up, and would prefer not taking it down just yet.

Curious. Either Apache doesn’t understand that path or it doesn’t have permission to read from that file. Can you see the corresponding item for that file without any problem?

1 Like

Yep. No problems on seeing the file or item for it. It’s only when I click on “Transcribe” that suddenly that error is thrown.

I got it to work, hooray! It was a path issue. The issue was that it required the entire path from the server root, not just the local path (if that makes sense). The way I solved this was by appending the getImageSize function with the following lines:

$filename  = parse_url($filename, PHP_URL_PATH);
$size = getimagesize($_SERVER['DOCUMENT_ROOT'] .$filename);

The key part was this:


Hope this helps someone else!

Fantastic! Thanks for posting your solution. It will be helpful.