So today I was trying to set up a wordpress site for a client on my server. I noticed that uploading of images and updating plugins didn’t work.
The images part was similar to several posts I saw on the web, but none of the solutions worked for me.
For reference, the suggestions for fixing the image uploading issue were:
- Make sure the image is RBG not CMYK
- Make sure the file is actually uploading
- Make sure the permissions on the file are 755 or 777
- Make sure that php5-gd (or for fedora php-gd) is installed on the server
From here: http://wordpress.org/support/topic/image-could-not-be-processed and here: http://h3x.no/2011/03/06/wordpress-image-could-not-be-processed-please-go-back-and-try-again
In troubleshooting this, I came to the following conclusions:
- The image type was not an issue. It wouldn’t accept any image, including one I’d installed on the other site I’d created at the same time, for Storm’s Eye’s own site. The one you’re reading right now.
- The file was not actually uploading, so there were no permissions to check.
- The permissions and ownership on the folders were correct; however, WordPress had not created them, so I’d done it manually. This is a clue that there’s a bigger problem than just the images not uploading. The same thing was reported in this post that was never resolved: http://wordpress.org/support/topic/header-image-and-media-files. I suspect that his webhost had the same issue that I did.
- php(5)-gd was installed on the server, it had to be, the other 2 wordpress sites on the same webserver were working.
Interestingly, the updating of plugins got me even less to troubleshoot with.
The other 2 sites I’ve set up have never asked for any ftp information to update. This one asked for it immediately, and putting it in did not work. (Turns out that was because my client appears to have changed his password (from what he’d initially requested I set it to) for his ftp. Good boy! 🙂 )
A quick google showed me only ways to “hardcode” the ftp information in the wp-config.php file.
Here’s why I don’t like that:
- The more places you hardcode it, the more places you have to remember to change it, when it changes. As you see above, more than one person can change this information. This leaves a lot of room to break things.
- None of the other sites have asked for this information, in fact, I couldn’t even find a place to enter it in the admin panel of wordpress.
So it looks like a permissions problem of some sort, right?
Not so in this case. Even changing the folder permissions to 777 as suggested in the one link for testing purposes didn’t fix the issue. So where to go from here…
I mentioned above that I have 2 other wordpress sites on the same server. The next step is to determine what the difference is between the working sites and the non-working site.
On the webserver I use a piece of software called ISPConfig. It helps me keep the sites I host separate from each other, and to manage quotas, etc. I poked around in ISPConfig and compared the setups of both of the clients (SE is set up as a client in this software,) While this information would have been something I could find in the operating system, using ISPConfig let me find the information visually, in seconds.
The working WordPress sites used fastCGI as their php rendering engines. The non-working site was using mod-php.
This information can also be created by getting the phpinfo from your site. This is useful if you don’t have full configuration control of your hosted website, like when you have a shared hosting plan. Incidentally, this is what my client pays for, so he could have created this file to find out this information, if he’d known what to look for. In this case, I found the problem before he knew about it.
To create a phpinfo page, paste the following into a text document:
// Show all information, defaults to INFO_ALL
save it with an extension of .php. Now upload it to the root of your webspace via ftp.
Browse to this page on your website: http://yoursite.com/index3.php
I call mine index3.php, so I know I can browse to http://www.stormi.ca/index3.php to get the information.
On the third line down, you’ll see that it says that the Server API is CGI/FastCGI
His would have said something about mod-php here.
On a Linux server at least, WordPress appears to require fastCGI to be used in order to work fully. mod-php (which is a default for many hosts) will not let WordPress create the directories, or upload correctly.