I’m noticing that my bedrock/trellis site has lost the menu option to add a new plugin in the admin area.
I fully understand why this is a good thing - I’m managing plugins via composer now. However, just for the moment, on a staging site, I need to add a plugin via admin.
Is this still possible? A config setting perhaps?
DISALLOW_FILE_MODS is set to true in staging and production environments by default. See here: https://github.com/roots/bedrock/blob/master/config/environments/production.php#L7
Changing it to false will allow you to install/update plugins via the WP admin dashboard.
or you could SSH into the server and use WP-CLI to install the plugin from the command line
Benefits: don’t need to commit plugins to the repo only to remove them afterwards
Caveats: the plugin would need to be reinstalled if a new deployment is ran
Good call @paul_tibbetts - I’ll keep that in mind too.
In my case, I’ll sometimes want to give non-technical people the option to try out plugins they’ve heard about, to see if they’ll work nicely on the site. Obviously I won’t let them do this on production, but I could allow it on staging, or maybe a ‘sandbox’ server, if I don’t want to lose parity on staging. So allowing plugin installation via the admin area is useful here.
How do you prevent the deploy from removing the plugins? I have a client with so many commercial plugins that I have not figured out how to handle yet.
I know this may not be “the Bedrock way” because it decouples the management of plugins/themes/updates from Composer, but for clients where I cannot (or do not) want to maintain active management/control of their site following completion of the project I make the following modifications to bedrock at the outset of the project which subsequently allows plugins/themes/updates to be managed via the Admin yet still allows me to perform trellis deploys – without removing/overwriting plugins!
production.php (create if necessary) and staging.php (if desired) files in site/config/environments/ to allow theme/plugin/updates via the Admin:Config::define('DISALLOW_FILE_MODS', false);
trellis/roles/deploy/defaults/main.yml under the project_shared_children heading (line 33 ATTOW), which will create new themes and plugins directories in /srv/www/example.com/shared/, symlinked to the themes and plugins directories in site/web/app/:project_shared_children
[...]
- path: web/app/plugins
src: plugins
- path: web/app/themes
src: themes
/srv/www/example.com/shared/[themes/plugins], which is retained across deployments!Once these changes have been implemented you can deploy at your leisure, assured that themes and plugins won’t be overwritten or removed!
Note: if you want to shim this in to an existing installation just mv the plugins and themes from your previous release (/srv/www/example.com/releases/[release -1]/web/app/[plugins/themes]/*) into the newly created /srv/www/example.com/shared/[themes/plugins]/ directories after deploy.
Thanks a lot for this, very helpful @gnowland!
It looks like once this is done, we will lose the ability to manage plugins with composer afterwards?
I was looking for a way to keep my composer plugins just as is, plus giving the client ability to add plugins by themselves. Something like:
Plugins added through admin -> goes in shared/plugins
Plugins added through composer -> goes in web/app/plugins as normal.
But after doing as above, the only the plugins in the shared folder worked.
@faahim, did you find an answer to your question above?
I ask as I am about to move a theme (Thrive Theme Builder) to shared as described by @gnowland
This related answer may help: