Looking for clarity on plugin management. I am using Bedrock with Sage 9. I understand how to install and use the plugins but looking for clarification on ongoing management. Can we no longer update through wp-admin or do all updates now need to be done with Composer and then deployed into the production environment? This seems like it would be a lot more unnecessary work for no reason other than to keep the developer’s local environments in sync. Are there other advantages that I might be missing? Thanks.
The intent is that you manage all dependencies through Composer, not WordPress itself. Not being able to update plugins through wp-admin is a feature of Bedrock, not a bug. If you feel it is a bug, then Composer dependency management may not be for you.
There is a development advantage, yes, but it also means that you can execute particular actions (i.e. Trellis deploys, setting up local development) with reasonable assurances that you are not overwriting or missing something: All of your dependencies are locked in place by your project. This is a huge advantage (to the point where it is arguably necessary) for automated deploys (i.e. with Trellis). It also prevents clients from accidentally (or purposefully) updating, adding, or modifying plugins and breaking the site.
1 Like
Thanks for the reply. Didn’t think it was a bug and I was thinking it was what you described. I currently don’t use Trellis but rather use Git with Ansible for deploys. Admittedly, I have been letting Git manage all assets (plugins included) and we use MigrateDB for db management. I have been running this way for years using Sage (and before Roots). Also, I don’t do sites for other clients.
Having said all this, our current workflow isn’t what I’d like it to be (there have been times when dev environments have been out of sync) so that why I am trying to figure out the best process. Maybe I’ll look into Trellis as well to see if that’s the missing piece to the stack I have been looking for.
Thanks for taking the time to answer… it’s most appreciated!
Trellis also uses Git w/ Ansible to deploy your site, so it would probably be similar to your current setup in many ways. It sounds like the major different would be that Trellis (by default, although you could configure it differently if you wanted) assumes you don’t keep dependencies and build artifacts in your repo, and downloads/deploys your dependencies and generates/regenerates your theme assets when you deploy.
Although I’m obviously a bit biased, Trellis is one of my favorite systems for deploying websites (and my favorite for deploying WordPress), and I use it weekly, if not daily. Hope you find what you’re looking for! 
I noticed the playbooks in Trellis yesterday. I guess my only question left is the speed of Vagrant vs my native environment (Mac, Nginx, etc.). Having been through the changes over the years from Grunt to Yarn/Webpack, speed gains have been the biggest positive and I would like to not move to anything slower. Will the performance moving my environment inside Vagrant be just as fast?
Thanks again for the help!
No. Vagrant, unfortunately, will always be slower than native because it has to operate through the VM intermediary. The primary advantages of using VMs are exact replication of the production environment and isolation from your host system, but you may not really need those things. A lot of the Roots team uses Valet for local development (I use Devilbox because trying to get Valet working on WSL is a pain in the butt and IME Docker performance is significantly better that VirtualBox on Windows).
Ugh, that’s what I was worried about. Think I’ll probably just kept our current workflow intact and play around with Trellis on the side for a bit.
On a side note…loving Sage 9 and especially the speed of things! Too bad there are devs out there that are missing out, lol. It really is a pleasure to work in. Thanks again…
Happy to help!
You can use Trellis without using the local VMs: That’s what I do. I do local development through Devilbox, and only use Trellis to deploy to staging/production on Kinsta. Even if you never use the provisioning tools Trellis provides, it’s very very useful for nice, simple, automated deploys.
Do you think there is any way to use Trellis with something other than Vagrant? I’ve run into slowness & lag in my local dev environment, and have been looking for a way to improve this. But I don’t know much about local dev and I’m not sure where to go next.
Yes:
Deploying w/ Trellis does not depend on a local VM. (Effectively) all Trellis does on deploy is generate assets and push necessary files to the remote server, none of which require a local dev environment. I’ve deployed sites without spinning up any local machine. Ultimately this means that whatever local dev environment you use doesn’t matter to Trellis so long as it works with Bedrock.
What you want to use for your local dev environment is up to you. As mentioned before, I’ve been using Devilbox lately, although that still creates a virtual environment, it’s just running in Docker instead of in a single VirtualBox VM. Lots of folks here swear by Laravel Valet, although it’s primarily a Mac product, and my own experience trying to use forks of it in Windows or Linux environments has been fraught. Some folks have also used Lando, although I haven’t heard that name in a while. I used to use ScotchBox a lot. Ultimately the best solution is the solution that works best for you; there’s no authoritative answer. The major benefit of Trellis’s built-in local dev provisioning is convenience and replication of production environment, but if you don’t need/want/like those things, there’s no reason to limit yourself to it.
Thanks @alwaysblank for the detailed response! I guess a better question is: Can Trellis provision with something other Vagrant? I do like the benefit of Trellis’s built-in local dev provisioning, as you mentioned.
Trellis is essentially just a set of customized ansible playbooks, so yes, you could write your own playbooks to provision a local VM with whatever system you want on whatever platform you want. I have a feeling that would be a non-trivial endeavor, though.
This topic was automatically closed after 42 days. New replies are no longer allowed.