Roots Discourse

Place Plugins in Shared Folder

Hi folks,
I often have clients that want to handle the plugins theirselves. So no composer update …

To make that work I would like to place the plugins in the shared folder (same as uploads) and have a symlink so that I don’t have to sync/update the plugins everytime I do a new deploy.

I’m not sure though how I can make this work with standard roots ecosystem (trellis, bedrock, sage).

Some hints which steps I would have to take would be highly appreaciated!

cheers
Josia

I’ve got the same situation with a few bedrock sites I manage. This is not the exact solution you’re asking for… but here’s what I do.

In config/application.php I change the “DISALLOW_FILE_MODS” param to “false”

// Disable plugin and theme updates and installation from the admin
Config::define('DISALLOW_FILE_MODS', false);

This allows them to install and manage plugins from the dashboard. I can still use composer to manage plugins, although if they install anything, I don’t get it on my end unless I add it to composer. Which I do real quick by running “wp plugin list” from the live site and then syncing it up with my composer.json. There’s a little more to it than that, but it seems to work.

One thing I was initially concerned about was if they installed a plugin, I was afraid me running “composer install” would uninstall their plugins. This does not happen. The plugins they install from the dashboard remain in place even after running composer install.

Hope this helps. :man_shrugging:t3:

@Xilonz commented this in patreon slack workspace:

This is a Trellis thing. project_shared_children can be used for this in your wordpess_sites.yml on each project or overwrite the default (same var name) in main.yml

hey @neonbrand.com thanks for sharing your experience! I’m running a similar setup as yours for a client-page with loads of plugins - its always a mess.
As far as I remember when I run a new deploy, the plugins installed on the livesite will be gone right? Or was it wordpress update? Maybe they disappeared for some other reason and I was just confused and interpreted this wrong?
Also any plugin I just add to composer and deploy to production without installing it on local dev first will not be installed on live site after deploy. I will have to do composer update wpackagist/plugin-slug. But when I do a new deploy the plugin will be gone again. I guess this is due to missing entry in composer.lock. its annoying …

so I often end up with different plugins running on different environments, which is quite confusing and wastes a lot of time, especially when I just want to do some quick changes and have to figure out whats going on every time.

all in all I think I might be better off without using composer for clients that are advanced wp-users and want to handle plugins and stuff theirselves.

could you describe how exactly you do this? I guess you use something like this $wp plugin list --format=csv --fields=name,version | awk '{if ($1 != "name,version") print $1;}' | awk -F',' '{print "\"wpackagist-plugins/" $1 "\":" " \"" $2 "\","}' but export it as .json instead? maybe you can copy the code you’re using here and explain how you then “sync” it in the next step? That would be awesome as it might solve my problem or at least make it less timeconsuming.

I also started digging in to satispress and stuff like that, but had the impression it will just bloat up the plugin management and make everything even more complicated …

looking forward to your thoughts on this!

Sorry to take so long to respond! To your specific questions:

The plugins do not get blown out upon running composer install. Any versions that are different than your composer lock file version will upgraded/downgraded, but not removed.

I believe this to be true. My process is running composer require wpackagist-plugin/slug locally. Once it works, I push to production and run composer install.

You nailed the formatting. Most excellent. I take that list and drop it into the composer.json plugins block. Now yes… this is where it gets a little complicated.

I do have a dev site that I run satispress on where I store all of my premium plugins. It’s pretty excellent.

So some of those plugins are premium plugins, I have to swap out wpackagist-plugin/slug with neonbrand-repo/slug, if that makes sense.

And then of course they will have inevitably added a few premium plugins themselves… to which the decision is to either move a copy to my satispress site and update through composer, or just leave it on the site for them to manage… I often find myself adding them to satispress since my ocd loves a clean composer install.

It’s an interesting situation for sure… not smooth, but somewhat manageable. :man_shrugging:t3:

This should be relevant:



This part of the Trellis configuration determines what is shared and what is copied between deploys.