Insert Flickr Image > Forbidden

Could you parse the whole message here please? Never heard of that. Are you using the new 1.0 release of WP Inject uploaded yesterday?

Also can you try disabling “Save images to server” in the Settings page and see if it works then?

Sure! ?? Well, the whole message is really just: Forbidden. See that screenshot

When I disable the “Save Images to Server” option, inserting an image to the post WORKS!

But when I try to use a selected image as featured image (which is my main purpose to use your plugin), I still do get the “Forbidden” message.

Looks like some kinda rights issue, what do you think?

Usdy,

Look at your server error logs. They can be found in cPanel by using the File Browser. Look in the root directory, the wp-uploads directory and the wp-admin directory. The error log titles will look like ‘error_log’ or similar.

There might be a directory permissions issue to fix (directories are usually 755) or a server config that needs to be changed. The error log will tell you if there is.

If the error logs are huge files, delete the error logs (do not delete any other files) then try to add an image using WP Inject then refresh the file browser then look for the error logs again.

Hope that helps.

That means it is a problem with image upload on your blog (which is always used for featured images). Most likely you will need to change your “uploads” folder file permissions to fix this. See here for a thread discussing the issue with details on how to solve: https://www.ads-software.com/support/topic/403-forbidden-error-on-all-media-uploads?replies=7

Let me know if that helped.

@ leehodson: The error log unfortunately doesn’t show a new entry after receiving the message “Forbidden”.

@ Thomas Hoefter: I followed the link you’ve attached and found out that your plugin saves all images in the uploads folder under wp-content. I’ve checked permission to that directory (and also the subs) and found out that all permissions are set to 755. As far as I could find out, that should be good, right?

755 is the typical permission setting. some host environments require odd settings like 700 but as the Media Library generally works fine with the current permissions and as the WP Inject images are being saved in the Media Library then I’d say your fonlder permissions are correct.

The files themselves, the images uploaded by WP Inject, do they have different permissions to those of non WP Inject images? They should be set to 644, typically.

What happens when you save the editor screen, exit the screen then reopen the post/page for editing: are you able to select the image from the media library at this point?

I’m wondering whether you have a security plugin installed or another plugin installed that affects the Media Library and the way WP Inject works with the Media Library.

Does the “normal” image upload inside your WordPress editor actually work? I did not see you mention that. If it does then this is no permission problem as leehodson also wrote.

In that case temporarily deactivating all other plugins to rule out any conflicts would be worth a try.

@ leehodson: At least in the wp-content/uploads folder, there are no images being dropped by WP inject. So I have no possibility to compare persmissions against other uploaded images.

Saving and reopening the post in the backend editor doesn’t change the situation, unfortunately.

Regarding your question about any other plugins, I’ve created a brandnew WP installation with only stock settings and all the actual versions. No change… ??

@ Thomas Hoefter: Interesting question and yes, I am able to set a featured image using the regular procedure. After doing that, WP creates folders inside the wp-content/uploads folder (2014 rwxr-xr-x / 05 rwxr-xr-x) and there I find the uploaded original image and the processed images with different resolutions. Files have rw-r–r– permission.

I bet you’re on a server that has SuHosin installed on it.

You might need to ask your host whether there is a server setting that is affecting WP Inject’s ability to add content to the server. Before asking your host…

I apologise for the questions but the answers may help solve this:

1. What type of server are you on e.g. Apache, Nginx, IIS (Windows) etc..?
2. Who is your web host?
3. Are you using WP Multisite?
4. Do you have unusual rules in .htaccess?
5. Which version of WordPress are you using?
6. Have you tried with a different web browser?

Rename your .htaccess file to something like x.htaccess. Do not delete it. Then try to add an image with WP Inject. Let us know what happens. Once you’ve run the test, restore x.htaccess to just .htaccess.

Thomas, which method does WP Inject use to fetch files and write files to the server?

usdy, when Thomas replies and if using a clean .htaccess file didn’t help, ask your host if that method is blocked or restricted by your server’s settings.

I have the plugin installed on a home server and on a commercially provided server. No issues with either installations – the plugin works for me.

Never heard about SuHosin. Whatever it is, is there a way to find that out and verify if that causes my issues?

Regarding your questions:
1. My host tells me they are using CentOS (V4.2) + BlueQuartz (V4.8) as management interface. Services as Apache, MySQL, PHP, Mail, FTP, SSH are preinstalled (see that).
2. My web host is called world4you, which you’ll find here.
3. No WP multisite function in use
4. The WP site is in a subdirectory. The root contains a .htaccess file with the following content:

# W4Y Redirect
RewriteEngine on
RewriteRule ^(/)?$ https://reise.dextroid.at [R=301,L]

The folder containing the WP Inject test installation does not contain any other htaccess file.
5. WP version is 3.9.1
6. Tried with Firefox and IE

Disabling the htaccess file doesn’t change the situation.

So well, that’s really a pitty, the plugin seems so be great work. Hope we can figure out where’s the bug.

Lee, WP Inject uses the WordPress function download_url (https://codex.www.ads-software.com/Function_Reference/download_url) to save a temp file of the image and then the fuction media_handle_sideload (https://codex.www.ads-software.com/Function_Reference/media_handle_sideload) to attach it to the post. Thats pretty much standard procedure for this kind of thing as far as I know.

I am glad you are chiming in here by the way since I have to admit there is not too much more advice I can give on a topic like that.

Hi Thomas, I’m almost out of ideas too.

usdy, if this doesn’t work then I’m not sure what will. I suspect that either the script is timing out before the image is placed on your server or the image download sizes are too big for your server’s current max_upload_size.

Open php.ini in your site’s root directory and add these lines to end of the file:

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

max_execution_time = 60
max_input_time = 90
memory_limit = 198M
upload_max_filesize = 128M
post_max_size = 64M
max_input_vars = 3000

suhosin.memory_limit = 0
suhosin.request.max_vars = 3000
suhosin.request.max_value_length = 1000000
suhosin.request.max_array_index_length = 256
suhosin.request.max_totalname_length = 8192
suhosin.post.max_vars = 3000
suhosin.post.max_array_index_length = 256
suhosin.post.max_totalname_length = 8192
suhosin.post.max_value_length = 1000000
suhosin.get.max_vars = 3000
suhosin.get.max_array_index_length = 256
suhosin.get.max_totalname_length = 8192
suhosin.get.max_value_length = 1000000
suhosin.sql.bailout_on_error = Off

If the site fails to load with those PHPO directives, remove the lines that being ‘suhosin’. Might even be the case that your regular (non suhosin) PHP settings need to be adjusted.

I would have answered sooner but had intended to write a blog post about Suhosin and WordPress PHP script failures. Been meaning to write it for the past couple of months but needed a push.

Hope that helps. If not, I or Thomas would need to look at your server settings and test for possible causes.

PHP configuration is being done via a web interface setup page provided by my host. The configuration panel lools like this.

So there’s no php.ini in my root dir. Creating one doesn’t affect the ‘Forbidden’ behavior.

Maybe on the screenshot you find some setting to change?

I’m wondering there is no debug messages or so to investigate in… Any idea?

Increase the max_execution_time to 60.

You can create php.ini in the root directory but then you might also need to tell your server where to look for that php.ini file. You would do this with an .htaccess file in the topmost directory you have access to (above your public space e.g. above /public_html or above /www).

Longshot but you could also try lowering your PHP version to PHP 5.4.