47 replies to this topic

[threadhead]

Can anyone give me any pointers as to why all Wordpress automatic updates, both the main app and plugins, always fail?

Typically the message is along these lines:

Could not copy file: /public_html/mywp/wp-content/upgrade/wordpress-34.tmp/wordpress/wp-activate.php
Installation Failed

Permissions on /public_html/mywp/wp-content/upgrade are 777.

WP was installed by hand (not through Fantastico).

Just getting annoyed having to SFTP up everything for simple updates.

Edited by threadhead, 09 August 2010 - 07:54 PM.

[djbaxter]

1. Which version of WordPress are youi running? Earlier versions with auto updates were buggy. After about 2.8 or 2.9 the feature worked more reliably.

2. What type of hosting do you have? You may be running out of memory if it's shared hosting. If it's a VPS, try boosting the amount of RAM allocated to PHP.

[threadhead]

djbaxter, on 09 August 2010 - 08:52 PM, said:

1. Which version of WordPress are youi running? Earlier versions with auto updates were buggy. After about 2.8 or 2.9 the feature worked more reliably.

2.9.2 and 3.0

I admit that when I was using the 2.8.X version, updates were more successful, but never 100%.

Quote

2. What type of hosting do you have? You may be running out of memory if it's shared hosting. If it's a VPS, try boosting the amount of RAM allocated to PHP.

Shared.

Hmm... running out of memory... hadn't thought of that. Seem a bit unlikely considering most plugins are only 20k-50k zipped and less than 10 files. But with full WP upgrade that makes more sense.

Someone for ASO have any ideas?

[MacManX]

Try deactivating all plugins before initiating the upgrade.

[tranceandy]

I would be suprised if you are running out of memory space. Should easily fit in the 64MB of acceptable usage.

-ASO- Frank, on 20 May 2010 - 10:34 PM, said:

Its mostly common sense. If you're needing to set the memory limit to 128MB+ and you run a heavy traffic site, you can bet that its going to cause problems, and we will certainly let you know about it.

For the most part, setting it to 64MB is acceptable.

[djbaxter]

tranceandy, on 10 August 2010 - 02:43 PM, said:

I would be suprised if you are running out of memory space. Should easily fit in the 64MB of acceptable usage.

-ASO- Frank, on 20 May 2010 - 10:34 PM, said:

Its mostly common sense. If you're needing to set the memory limit to 128MB+ and you run a heavy traffic site, you can bet that its going to cause problems, and we will certainly let you know about it.

For the most part, setting it to 64MB is acceptable.

Depends what else you have running at the time of the upgrade.

[threadhead]

MacManX, on 10 August 2010 - 02:20 PM, said:

Try deactivating all plugins before initiating the upgrade.

I'll give that a try, but I'm pretty sure the automatic update process deactivates plugins before it attempts the upgrade.

[MacManX]

threadhead, on 11 August 2010 - 09:25 AM, said:

MacManX, on 10 August 2010 - 02:20 PM, said:

Try deactivating all plugins before initiating the upgrade.

I'll give that a try, but I'm pretty sure the automatic update process deactivates plugins before it attempts the upgrade.

I can guarantee you that the automated upgrader does not deactivate plugins before the upgrade. The plugins will remain active unless manually deactivated prior to the upgrade.

[threadhead]

Tried deactivating all plugins... attempted automatic update of Wordpress Stats plugin...

Downloading update from http://downloads.wordpress.org/plugin/stats.1.7.3.zip…

Unpacking the update…

Could not create directory. /public_html

MacManX, on 11 August 2010 - 05:28 PM, said:

I can guarantee you that the automated upgrader does not deactivate plugins before the upgrade. The plugins will remain active unless manually deactivated prior to the upgrade.

I was referring to the Wordpress Automatic Upgrade plugin, which does disable plugins, that worked well in the past but does not work currently. I have tried upgrading using this plugin and using the built-in upgrade function with no success.

The new, built-in automatic upgrade function does not deactivate plugins... you are correct.

Just tried upgrading another blog (3.0 -> 3.0.1) using the built-in upgrader, all plugins disabled:

Downloading update from http://wordpress.org/wordpress-3.0.1.zip.
Unpacking the update.
Verifying the unpacked files…
Installing the latest version…
Could not copy file: /public_html/blog/wp-admin/css/colors-classic.dev.css
Installation Failed

This is very typical of my failures, but with differing file copy failures.

[MacManX]

That's definitely a server configuration or permissions issue, and there are a variety of suggested work-arounds. If you have the time, I recommend doing the upgrade manually. Yes, it'll take a few extra minutes, bit it'll work and I think it'll save time as opposed to trying several of the suggested work-arounds.

[threadhead]

MacManX, on 11 August 2010 - 07:56 PM, said:

That's definitely a server configuration or permissions issue, and there are a variety of suggested work-arounds. If you have the time, I recommend doing the upgrade manually. Yes, it'll take a few extra minutes, bit it'll work and I think it'll save time as opposed to trying several of the suggested work-arounds.

Yes, manual upgrade works. But I have around 8 client sites with WP installs and it gets to be quite a pain to do each manually.

Maybe I'll drop a support ticket on this one.

Thanks.

[NyteOwl]

I wouldn't call it a server configuration problem.

It looks like the update script tries to create /public_html, which already exists in your account as the default public web site directory so you can't create another one, hence the error.

[threadhead]

NyteOwl, on 12 August 2010 - 04:56 PM, said:

I wouldn't call it a server configuration problem.

It looks like the update script tries to create /public_html, which already exists in your account as the default public web site directory so you can't create another one, hence the error.

That was the case when updating a script, but not when doing a full WP upgrade. See above... updated WP resulted in an error when copying a .css file.

The errors are never exactly the same each time (different files, different directories, etc.).

[MacManX]

NyteOwl, on 12 August 2010 - 04:56 PM, said:

It looks like the update script tries to create /public_html, which already exists in your account as the default public web site directory so you can't create another one, hence the error.

If that were the case, then there'd be a lot more users having the same problem, like millions more.  

A few of my fellow mods on the WP forums have a better explanation for why this is happening.

[threadhead]

MacManX, on 12 August 2010 - 05:18 PM, said:

NyteOwl, on 12 August 2010 - 04:56 PM, said:

It looks like the update script tries to create /public_html, which already exists in your account as the default public web site directory so you can't create another one, hence the error.

If that were the case, then there'd be a lot more users having the same problem, like millions more.  

A few of my fellow mods on the WP forums have a better explanation for why this is happening.

Could you enlighten me (us)?

[MacManX]

threadhead, on 12 August 2010 - 05:23 PM, said:

Could you enlighten me (us)?

I could, but it'll take a while for me to find the necessary info.  I guess what I'm trying to get at is that you should post your question on the WordPress Support Forums, and one of my colleagues will help you.

[emory @ clickfire]

I have the same issue as threadhead and haven't found a solution to upgrade 3.0 -> 3.01 on the WordPress Support Forums.  Before upgrading 10 installations manually, has anyone here found a solution that works? So much for Saturday afternoon

[bits-Jim]

Hi, I'm adding a reply here because I have a client who is using 'a small orange' hosting, and having the same issue with WordPress auto-updates failing. I have other WP blogs, on other hosting providers, which are not having this issue. To be fair, I do not know the history of how his WordPress blog was originally installed and set up over time...however it seems that many people are having the same issue on this host, and no support was forthcoming when a ticket was entered, other than the suggestion of trying the 'manual install' and a link to the WP site. Huh? For many of us in IT support, the manual reinstall is not exactly an elegant solution, more like using a sledgehammer, and could cause additional problems...I would much rather use the automated function which *should* work. If this is an issue on a macro level, the hosting provider should put some skin in the game. I've noticed that permissions on this existing install are botched, and essentially the account holder  (under ssh mind you) would not even have proper access rights to change permissions of certain files and folders (which would require root access on the server to change) to have the ability to run the suggested manual install. The result? A half-baked manual install, somewhere in the middle between somewhat screwed up and totally fubar. Personally, that's not how I want to spend my days or nights. I'm going to push this further with 'a small orange' support, but in all honesty I'm a little disappointed at support's initial response. If you are listening, how about jumping into the fray? Thanks for listening. -Jim

[lesture]

Well Jim, to be fair it's not as if the automatic updater is known for its supreme reliability. Even Wordpress' codex says that if the automatic updater doesn't work to go for a manual update.

Really this just comes with the territory of the software you choose to use, I've run into this issue on SEVERAL 'properly' configured servers.