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?
1 Like
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.
1 Like
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.
6 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!
12 Likes
Wow nice summary, but unfortunately now reply since 2015 
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.
2 Likes
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?
1 Like
Have not yet ran into this problem myself, but for future reference I would love to hear input from other people on working with the issue of database changing during plugin updates.
Personally I change the WP_ENV variable in development mode and update it from the dashboad. Once finished I put the WP_ENV variable back into production.
@ben @alwaysblank I’m curious to know if this is accurate - when updating WP or plugins via Composer, are required database updates not actually run? If so, what is the recommended method for updating to ensure that any required database changes are made?
My current approach is local GitLab + renovate, though I still have to get the renovate bot running automatically using GitLab action/pipelines thing.
I’ve been working with 20-40 sites over the last 4 years where we managed updates with Bedrock and Composer, some of which have been WooCommerce, and I haven’t run into this issue.
My understanding of the plugin update process is that WordPress doesn’t run anything that says “Run your update logic now, plugin!” AFAIK the recommended way for plugins to handle updates is to essentially check for a plugin version in the database, and if that value doesn’t match what they have hardcoded, then assume they have been upgrade and do what they need to do–hence the “You’ve updated X Plugin, click here to upgrade your database” message you’ll see in the admin after updating certain plugins. In other words, the recommended method for applying database changes is the same on Bedrock as it would be on a vanilla install: Run the upgrade, then do anything you’re asked to do in the admin.
It might be possible that plugins left for long enough might be so out of date when upgraded that they would run into issues attempting to upgrade themselves, but I don’t know that I’ve run into that.
2 Likes
In very rare cases a plugin could bork the database somehow.
This shouldn’t be an issue anyway, because setting up regular backups should be one of the first things to consider.
Anyway, as those database backups are comparatively very small (and can be made even smaller when gzipped), for my Trellis deployment I also set up a backup during deploy plugin for trellis:
It is really a simple setup-and-forget tool.
2 Likes
What about the changes you made to the wp-config configuration and the installation via roots/wordpress instead of johnpbloch/wordpress. Is there an update guide anywhere to be found on that or can I just replace the new composer dependencies? I found some new configurations in the composer.json too so I wasn’t sure if they are related to the new dependencies and/or are needed.
Hi Ben - that link to the roots.io article on automating updates is broken. Does the article itself still exist?
And thanks for the Dependabot reminder. I’ve seen it mentioned several times but have never checked it out.
Are you still managing your dependencies updates with renovatebot ?
I can’t get it to work. Renovabot is not updating my wpackagist dependencies (while packagist deps are getting updated).
Do you use a particuliar setting in your renovate.json ?