Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy. This forum is not for asking programming related questions.
“banner_toptenxmas.jpg” has failed to upload due to an error
Unable to create directory wp-content/uploads/2015/07. Is its parent directory writable by the server?
We are trying to upload images to a Word Pres web site. We have done it before as the site has lots on there already.
But when we try it now, it won't work.
If I delete the /07 folder, I still get the error.
If I set the folder permissions to something silly like 777, it still get the error.
So I am lost.
Love PHP. Love CSS. Love learning new tricks too.
All the best from the United Kingdom.
wp-content/uploads/2015/07 needs to be writable by the server. If the directory does not exist, its parent needs to be writable by the server. Additionally, it and all its parent directories need to be executable by the server (ls requires execute permissions). With WordPress creating new directories each month, you'll generally need to give the uploads directory itself 777, its subdirectories 777, and the files in those directories 666. The easiest way to handle this is to navigate to the uploads directory and run the following commands:
[text]$ find . -type d -exec chmod 777 {} \;
$ find . -type f -exec chmod 666 {} \;[/text] NB: These commands must be run from within the wp-content/uploads directory. Note also that the leading $ represents the shell prompt and is not part of the actual command.
But why has it changed?
The site has images that were updated via wordpress - it's only in the last week this error has happened.
Also, it won't allow us to update it to 4.2.3. IT churns and then says something about the root directory.
Love PHP. Love CSS. Love learning new tricks too.
All the best from the United Kingdom.
I haven't a clue. It didn't just change itself, that much is certain. Getting it sorted is one thing, working backwards and determining what was changed when and by whom is something else altogether.
simonmlewis wrote:Also, it won't allow us to update it to 4.2.3. IT churns and then says something about the root directory.
Might need to do that manually. It needs write access to anywhere that it's going to copy new files, which is probably not a good idea. Copying your wp-config, .htaccess, and your wp-content directories to a temporary location, dropping in the latest WP, and then copying back should do the trick with the least trouble. Backing up beforehand is always a good idea.
Well we are considering dumping and starting over, as they want to change most of the images anyway. I can copy the CSS to rebuilding shouldn't be too much hassle.
Love PHP. Love CSS. Love learning new tricks too.
All the best from the United Kingdom.
I think it's a FTP problem.
When I go to Update a Plugin, it asks for the FTP. I know the details to be correct, but it still hangs... then fails.
[text]Unable to locate WordPress Content directory (wp-content).[/text]
Love PHP. Love CSS. Love learning new tricks too.
All the best from the United Kingdom.
No, we had a similar issue with auto updates failing on one of our WordPress installs. If the Apache package on the machine hosting your site was updated, some server-wide configurations may have changed the user Apache runs as, thereby introducing permissions issues. The simplest solution is to temporarily give Apache write access to all the files it needs. Recursively set directory permissions to 777 and file permissions to 666 on wp-admin, wp-include, and your plugins directory. You'll also need to set the files in the WP root (ie. directory containing wp-admin, etc) to 666. Updated WordPress itself, your plugins, and then revoke these new pernissions, setting them back to whatever they were previously. If you're not comfortable doing that, I'd back up wp-config.php, your wp-content directory, and do a clean install.
I did a rebuild to find the same problem existied.
In the end, the solution was found by the hosts.
It was changed somehow to Apache Module in Plesk, and that killed permissions.
Changing it to FastCGI fixed it Wish I had known that before rebuilding, but you live and learn.
Love PHP. Love CSS. Love learning new tricks too.
All the best from the United Kingdom.