WordPress and plugins updates in production server after deployment

I am a newbie to this Capistrano deployment concept. Few questions:

  1. Since Capistrano is based on Ruby, does the production server need to have Ruby installed as well?

  2. “Deploying WordPress with Capistrano” article has warning on Capistrano can’t deploy to a shared host server. So I have to get a dedicated server or VPS to make this deployment approach works?

  3. WP has auto update feature after V 3.9. I understand that Capistrano will modify default WP file structure. When auto updates triggered in production server, does it still work?

  4. Similar question to 3 - when I update a plugin directly in production server via WP admin plugin updates, does it gonna work? Or it needs a different plugin update approach?

Thanks!

T

1 Like

.

  1. Since Capistrano is based on Ruby, does the production server need to have Ruby installed as well?
    No (but I might be wrong).
  2. “Deploying WordPress with Capistrano” article has warning on Capistrano can’t deploy to a shared host server. So I have to get a dedicated server or VPS to make this deployment approach works?
    No, you can deploy WordPress with Capistrano to a shared host but it’s not as easy and you may experience hiccups.
  3. WP has auto update feature after V 3.9. I understand that Capistrano will modify default WP file structure. When auto updates triggered in production server, does it still work?
    Yes. (Technically Capistrano does not modify the WP directory structure, that is done by Composer.)
  4. Similar question to 3 - when I update a plugin directly in production server via WP admin plugin updates, does it gonna work? Or it needs a different plugin update approach?
    Yes, but heads up: you will need to update the plugin version numbers in your composer.json file otherwise future deployments may install outdated plugin versions. You don’t need to do this, but if you don’t then after a deploy you will need to update the plugins through the WP admin.
1 Like

@cfx is mostly correct with the above with some clarification:

  1. Ditto (Ruby is only required locally).

  2. Ditto

  3. Capistrano doesn’t modify anything by default. Only if you want to use a non-standard setup like Bedrock.

  4. Using Capistrano doesn’t mean you have to use Bedrock or Composer. But Capistrano ALWAYS (by default) deploys from a Git repository. If you update a plugin on production it’s just a local modification and won’t be reflected in your repo. Unless you commit things on production but that’s insane.

So if you use Capistrano to deploy: never change anything in production that results in local modifications and that includes installing plugins from WP admin.

1 Like

@swalkinshaw speaks the truth. Thanks for clarifying!

Thanks for clarifications, @cfx and @swalkinshaw!

Since you mentioned Bedrock, if I use Composer to set up WP initially, which will modify the default WP file structure, does that mean auto update of WP will break it?

I understand that Composer uses WordPress Packagist to install plugins and themes. What the plugins or themes that not in the repo? (like commercial plugins or themes)

Bedrock uses a modified folder structure but WP core is completely intact. We just disable auto-updates since you update WP itself through Composer. Even if you enabled auto-update I don’t think it would break anything. The update just wouldn’t be reflected in your Git repository since it only happened on the production server.

Do you mean plugins/themes that aren’t in WP plugin directory? Composer can pull from WPackagist, normal Packagist, any custom Git/SVN repository, zip file, etc. I suggest searching this forum for other Composer topics like Best way to install private/paid plugins with Composer?.

There’s this post as well: http://roots.io/wordpress-plugins-with-composer/

1 Like

Just to add another way of thinking about it: Bedrock allows you to update WordPress from the dashboard as usual.

If you do this in your production environment without changing the WP version number in composer.json then any Capistrano deploy you perform to the production environment will install the (potentially outdated) WP version specified in that file. You will, of course, be able to update from the production dashboard, but simply updating the version number in composer.json will save you this step.

Likewise, if you update your local WP version from within your WP dashboard and find yourself running Composer in your local environment, you may end up needing to update WP again if you did not update the version number in composer.json.

As @swalkinshaw said, the latest WP version won’t be “in” your Git repo unless it’s specified in composer.json and then committed to your repo. So, if someone clones your Git repo and runs Composer to install WP and plugins they will start out with an outdated WP version unless you change the version number in composer.json and commit the change to your repo. However, they should have no problem updating it from the WP dashboard if you forget to update composer.json.

3 Likes