Everything is back to working. My permissions, as I suspected, were never the issue. My images uploaded some, but not all, times. A permission issue would have prevented them all times. Additionally, I had one out of 40 sites that worked perfectly. A permissions issue, I felt, would have affected all sites since they are on the same server -- all which were upgraded at the same time. I also duplicated the one working site and then restored the database from a backup of the site I was replacing...also to no avail. The four extensions are for fastPHP 4.x and fastPHP 5.x.
[resolved] [closed] File Upload Error After Upgrading to 3.3 (42 posts)
-
cshaffstall
Posted 1 year ago #
-
KarenWallace
Posted 1 year ago #
I had this problem after the 3.3 upgrade as well, and cshaffstall's posts led me to the solution. If you're using a cPanel host, go to the "PHP Configuration" section. There is a dropdown at the top of the page labeled "The .php file extension will be processed by". The selected value was "System Default". I changed it to "PHP 5", and that fixed the bug in WordPress' bonnet.
-
RTK
Posted 1 year ago #
@RTK - are you able to write to the Plugins folder now? That is, have you attempted to place or replace/update plugins to that folder yet? I was given a denied error even login as administrator...
Had to give the folder write privileges to all again to correct the error...
I did not have to give write permissions to the folder, however I do all of my updates manually as opposed to automatically since FTP is blocked at the firewall level where I have my server hosted.
Unfortunately none of the solutions described above that involve changing cPanel settings or changing PHP extensions to run under PHP 5.x only help me. I host a Windows Server 2008 R2 server using the latest PHP 5 myself, not through a hosting company, so unless the new WordPress doesn't like some of the default PHP extensions enabled in my PHP.ini (HIHGLY doubtful seeing as how I'm sure they QA their changes against a fairly defualt PHP installation), then those suggestions don't resolve this issue.
The only true workaround I've found is to do as I described earlier and give the IUSR user write permissions on my wp-content directory. This is the only solution (and I hesitate to even call it a solution) I've found for my setup.
-
Posted 1 year ago #
Not to be contrary, but my caution: I began upgrading my sites as a function of removing a malware virus from my 40 sites. Viruses such as this take advantage of sites with lax permissions (which I had). I would not recommend granting permissions beyond those described by WordPress (http://codex.wordpress.org/Changing_File_Permissions)
While you don't think your default system could be the issue, it would only take a moment to get a closer look at your default PHP extensions. Testing doesn't cover every possible scenario and my system *was* a default system. It just turned out that default wasn't what I needed...for 39 of the 40 sites. This may well be due to plug-ins that I am running at those sites, but I don't run the same plug-ins at even a majority of the sites.
If you're unsure about your PHP extensions, call your hosting provider and ask for help. If you're your own host, check the extensions...just for the sake of ticking it off the list.
-
Posted 1 year ago #
Nobody has actually listed the extentions that they disabled...
-
rsgrone
Posted 1 year ago #
@RTK - are you running Windows Server 2008 R2, or just the Web Server version of 2008?
I operate a Windows 2008 R2 dedicated and I utilize remote desktop not, C-Panel...
My issue is, 3.2.1 rund just fine with the recommended security settings and as you, am very hesitant to stray for the sake of making a newer version of WP operational at this time..
-
Posted 1 year ago #
@rsgrone - Windows Server 2008 R2 Standard Edition
-
username required
Posted 1 year ago #
Same problem of not being able to upload on a BSD server.
3.3.1 upgrade does not fix it.
Not even 777 permissions change it.
It is not a problem related to themes or plugins.
Do the development team have no idea what they changed to do this?
-
dolbex
Posted 1 year ago #
We just had to set up a WordPress 3.3 install on a Windows Server 2008 R2 box (w/ PHP running in FastCGI) for a client and had a lot of trouble with this issue as well.
Changing permissions on the uploads directory didn't seem to solve it; WordPress was capable of creating new directories, eg "/uploads/2012/01", but we would still get the message about it being unable to move the file into the uploads directory.
What worked for us was this post - http://www.ithubs.info/2011/11/30/wordpress-image-upload-problem-using-iis-on-windows-server-2008/. We changed the Anonymous Authentication for the site from the IUSR to the application pool identity as the author describes.
Also, be sure to uncomment and/or enable the line in your php.ini file regarding fastcgi impersonation. That bit wasn't mentioned in the post above.
fastcgi.impersonate = 1 -
casca
Posted 1 year ago #
This works. The problem is not permissions or Authentication for most it is completely related to PHP basedir settings and the new changes made in WordPress to prevent cross site scripting.
Follow the step by steps and you will be up and running in no time.
-
gettiwilliams
Posted 1 year ago #
Hi guys,
I tried reading through posted responses hear but i couldnt find responses that fit my problem. i just bout a classipress theme and i tried uploading images but i get this error anytime i do so:“logo.jpg” has failed to upload due to an error
Unable to create directory D:\Hosting\8806749\html/wp-content/uploads/2012/03. Is its parent directory writable by the server?I need help on how to fix this. Thank you very much.
Gbenga
-
Try changing the permissions on the wp-content directory to 766. If you still have problems, try 767, 775 or 777. Once your uploads are working, change the permissions on wp-content back to 755 again and check that everything still works OK.
http://codex.wordpress.org/Changing_File_PermissionsAnd next time, please post your own topic.
Topic Closed
This topic has been closed to new replies.
