Can't update more than 1 plugin [automatically] at-a-time.

Scenario: Go either to the Updates section or the Plugins page, select more than one plugin to update (or just select all), and try to update.

Result: The maintenance file will be added to the project root, some files will be downloaded, but not all, and nothing will seemingly complete. In addition, the upgrade progress will not be displayed, and as a grande finale, you'll end up with a white screen of death when you try to click on any links.

+1. Can reproduce when manually installing older plugins, then attempting to upgrade a few.

I'm also receiving the white screen of death when attempting to install certain plugins.
Some install via Plugins > Add New, then they download and I see the normal "Activate" screen. Others, such as Jetpack, merely display the white screen of death almost immediately after hitting "OK" to install.

I'm using every version specified in the install instructions (Yeoman v1, Bower v1.2, Node v0.10, Vagrant v1.2.7).

Have tried this numerous times with clean, test directories and have also reinstalled Vagrant - no luck.
Doing research, this white screen of death appears to be a result of PHP memory or permissions, usually. None of the recommended courses of action on the WP.org forums helped.

I assume you are both talking about the local vagrant? I believe this is related to issue 12. My experience so far shows it is a permissions/ownership issue and the way WP handles updates by testing the directory by writing a small file and then testing to make sure the owner of the file is the same as the one it is running as.

Try to add a direct management of files by placing
define('FS_METHOD', 'direct');
in wp-config.php and see if plugin install/update issues are still there.

If yes, try and turn off nfs and add permissions. Modify the local Vagrantfile line:
box.vm.synced_folder ".", "/vagrant", :nfs => true

And change it to:

box.vm.synced_folder ".", "/vagrant"
vagrant_version = Vagrant::VERSION.sub(/^v/, '')
if vagrant_version >= "1.3.0"
    box.vm.synced_folder "./web", "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/vagrant/web/", :owner => "www-data", :mount_options => [ "dmode=775", "fmode=774" ]
else
  box.vm.synced_folder "./web", "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/vagrant/web/", :owner => "www-data", :extra => [ "dmode=775", "fmode=774" ]
end

I assume you are both talking about the local vagrant? I believe this is related to issue 12. My experience so far shows it is a permissions/ownership issue and the way WP handles updates by testing the directory by writing a small file and then testing to make sure the owner of the file is the same as the one it is running as.

Tried out everything you suggested: still getting the white screen of death when attempting to install Jetpack. I'm going to just continue using Jetpack as the plugin to test an install on until it works as expected.

No amount of starting anew with your suggested changes did anything, sadly.

@mcheck

Here's one sucky thing about WP in general: PHP errors are usually disabled, and hidden in 99% of most installs/envs because of the sorry quality of plugins (and other code).

So, if you're getting a white screen, it is almost always because of an startup error or an error before any output has been sent to the browser.

Running cap local genesis:logs will show you the error logs on that particular server for easier debugging. Most of the time, it comes down to permissions, which were just updated today (and can be corrected via cap staging genesis:permissions).

Oddly enough, everything works great on local, and I only had issues upon deployment. I think @mcheck's VM options may come in handy, as well as some of the tips here:

http://www.viper007bond.com/2009/05/07/wordpress-how-to-force-direct-filewrites-for-upgrades/

@mcheck

For the sake of trying to get to the bottom of this, I'll state I haven't run any PHP on this system outside of running WordPress locally via VirtualHostX.app and Mamp.app. Looking to avoid using that system (because pow continually interferes with VHX/Mamp, I decided to embrace Genesis WordPress; it feels like a natural way of developing for a big platform like WP, so I definitely want to get it working.

I'm running the following:

VirtualBox 4.2.18 r88780
npm 1.3.11
Vagrant 1.2.7
Yeoman 1.0.4
Bower 1.2.7
Capistrano 3.0.0
Ansible 1.3.3
pip 1.4.1
Python 2.7.5

Looking through the above, is there anything I need to upgrade/downgrade? I've tried @mcheck's tips, but no luck so far. Being new to Vagrant and Genesis, I'm feeling a bit unsure of how to proceed/debug. I'd love to use the local+remote features of Genesis Wordpress, but obviously my primary concern is getting local working as per usual first.

Wait! Capistrano 3!? Dang it! gem install capistrano used to do 2.14.x!

http://rubygems.org/gems/capistrano/versions/2.15.5

Try that bad boy out. Otherwise, give me the weekend to clear out these 22+ (!!!) issues and let's go from there.

I have to say, you've got some moxy, kid! :D

Capistrano should be version 2. I haven't gotten it to work with version 3.

And for the record, my local does not work fine. Jetpack fails on
install, other plugins work as expected.

It is sporadic and I think the bottom line comes down to permissions,
ownership and the apache user running the process.

I have successfully got a staging server vagrant to install all
plugins via the GUI by setting the correct permissions and ownership
of the files. But local is running a shared folder and I'm not sure
how vagrant's nfs share is affecting the web server operations.

@ggamel

@ggamel In your project directory

gem uninstall capistrano
gem install capistrano --version '~-2.15'

If you are not running rvm or rbenv, you may have to run sudo if installing with system ruby.

But that is not the issue with local you are having. I have the same issue sporadically. Sorry the other changes did not work for you. If I find the magic formula, I'll pass it on.

@ericclemmons

But that is not the issue with local you are having. I have the same issue sporadically. Sorry the other changes did not work for you. If I find the magic formula, I'll pass it on.

Not a problem — you (and @ericclemmons) are trying to help, and I appreciate it a lot. Hopefully, if we can find the root cause, this slight bump in the road will help improve the docs/wiki/howto/setup for others.

I disabled varnish on local, and the plugin/upgrade/theme installations work as expected, no permissions modified, still using nfs: => true. I think if varnish were disabled for the local development machine (or if we figure out the varnish config that allows for plugins and upgrades) it will work as expected. Anyone else tried this?

I'll test this out personally (again, as I couldn't replicate before). I want to make sure every environment works exactly the same with the same stack. So far, we've had great success with it, but obviously there are many more users now with different envs to work with :D

@mcheck

Hey, @mcheck & @ericclemmons, Responded in #34 that I'll help with testing whatever changes might help smooth this out for the maximum number of users.

Pipe all requests for wp-login or wp-admin

Navigation Menu

Repository navigation

Can't update more than 1 plugin [automatically] at-a-time. #30

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Can't update more than 1 plugin [automatically] at-a-time. #30

Description

Activity

ggamel commented on Oct 25, 2013

mcheck commented on Oct 25, 2013

ggamel commented on Oct 25, 2013

ericclemmons commented on Oct 25, 2013

ggamel commented on Oct 26, 2013

ericclemmons commented on Oct 26, 2013

mcheck commented on Oct 26, 2013

mcheck commented on Oct 26, 2013

ggamel commented on Oct 27, 2013

mcheck commented on Oct 28, 2013

ericclemmons commented on Oct 28, 2013

ggamel commented on Oct 29, 2013

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions