Roots Discourse

How to Update WordPress + Bedrock after Deployment

By running composer install from my applications main directory will it update to the latest version of WordPress + Bedrock?

If not, what’s the best way to update to the latest version of WordPress + Bedrock using Composer?

You would use composer update https://getcomposer.org/doc/03-cli.md#update

composer install is good for production where you will always install what is in composer.lock, which should be thoroughly tested in development/staging.

Unfortunately I haven’t found any way to update to the latest version of Bedrock (because its Composer package type is “project”, i.e. a project template). This seems to be a common problem (look at the Symfony Standard distribution for example). Any changes/improvements that you desire from the latest version of Bedrock has to be applied manually…

1 Like

Thanks @kalenjohnson. Just to confirm, for production sites, you are recommending using composer install to create a build a new bedrock directory. Then migrate the theme and data for development/staging. Test everything. Then move into production when ready.

This approach is much more professional and eliminates the risks associated with live updates.

However, for low profile sites or dev sites, does composer update actually update the latest version of Bedrock (and WordPress core)? You and @teohhanhui seem to have different responses…

composer update will update WordPress when you specifically tell composer.json what version of WordPress to update to.

Right now it is "johnpbloch/wordpress": "4.2.2", and if 4.2.3 would come out, I would update my composer.json file to "johnpbloch/wordpress": "4.2.3"

It will not update Bedrock.

4 Likes

Ok, sorry to warm this up after a few months, but after playing around with bedrock a bit I would like to be absolutely sure that I understand the details regarding updates. From what I see now the bedrock stack leaves me with this situation:

  • Automatic updates are disabled.
  • I need to manually change a version number to a file (composer.json) for anything I want to update (core, plugins), except things that are on a ‘trunk-dev’ or a similar ‘rolling tag’.
  • Only after this I can update things manually with ‘composer update’.
  • There is no rollback out of the box (at least not with bedrock, trellis might have a solution for this or I can build my own solution).
  • There is still the additional problem that not all plugins are to be found on the experimental packagist site, so I might be left with some outdated plugins when not caring for this (whatever care might be good).
  • If I (or anybody else with legitimate access to the site) decides to update core or install any plugin via the admin GUI, there will be a nice desynchronization between what is written down in composer.json and the_reality().

I hope the slightly provocative tone does not hurt anybody, I am just trying to understand the involvements regarding updates and an explicit sceptical approach helps me to see all the possibly negative aspects I need to be prepared for (and need to find a remedy for).

Please falsify me when I am wrong. I understand what the benefits of bedrock are, but I am not sure I have analysed the negative aspects good enough.

Thank you very much for your attention!

11 Likes

Wow nice summary, but unfortunately now reply since 2015 :frowning:

What are you looking for?

If you’re curious about dependency updates, see https://roots.io/automate-wordpress-and-plugin-updates-with-composer/ (or Dependabot as an alternative) for a way to automate bumping your Composer dependencies.

Bedrock is a project boilerplate so there’s no way to easily merge in updates from Bedrock itself. Updating Bedrock itself also isn’t really something that should be needed. There’s rarely changes to Bedrock outside of bumping WordPress versions.

These are all correct (although you can use Composer’s version constraints to define your dependencies such that you don’t need to manually change the version number every time you want to update).

If by “rollback” you mean “go back to a previous version of a plugin” this is not correct: all you need to do is change the version number to the version you want to “roll back” to and run composer update again.

From the WPackagist site:

This site mirrors the WordPress plugin and theme directories as a Composer repository.

Any plugin downloadable from the WordPress.org site is available through WPackagist. Private plugins can be committed directly to your repository (and then exempted from your .gitignore file) or loaded in one of a few other ways (there are several threads in this forum dealing with loading private/paid plugins.

Bedrock disables the ability to update core and plugins from the admin UI in order to avoid this exact situation, so if you use Bedrock as intended then no, you will not encounter this problem. If you remove Bedrock’s ability to block admin updates then things could fall out of sync, but the intent of Bedrock is that updates are managed intentionally through the process described in Ben’s link above.

1 Like

When doing an composer update it doesn’t seem to actually update anything. But also there is a slight fault in this process because what if the WP or plugin update requires a changes made to the database structure or content. Those changes wont happen unless run through the dashboard updating process.

I learnt this the hard way with a live site (also running a woocommerce store) and it completely killed the site. There were very important changes to the database that simply didn’t happen and so the code and DB conflicted.

We work on and test updates locally and then push changes to production using bitbucket etc so how should this work with bedrock? The documentation I have read doesn’t really outline how to do it?