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.
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!
Add the following to both 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);
Next, add the following to 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/:
From the next deploy onwards all themes and plugins installed via the WordPress Admin will be written to /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.
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.
In case anyone is looking for a solution for this - instead of setting the whole plugin and theme directories as project_shared_children, I instead only did this with the plugins I have to install through the wp dashboard. see example:
But even those plugins should be installable using composer, as composer can also extract archive files (as zip) into a directory - or put the premium plugin code into a private repository.