Place Plugins in Shared Folder

josialoos · February 15, 2021, 12:01pm

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

neonbrand.com · February 15, 2021, 6:45pm

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.

josialoos · February 16, 2021, 9:54am

@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

josialoos · February 16, 2021, 10:05am

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!

neonbrand.com · February 22, 2021, 8:22pm

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.

strarsis · February 22, 2021, 8:50pm

This should be relevant:

github.com

roots/trellis/blob/a81c10b5b0bc01c5ffb61891dd7c6b82c166278a/roles/deploy/defaults/main.yml#L25


  - vendor

# All the templates to process on the remote system on deploy. These could contain config files.
# `src` and `dest` paths work the same as project_local_files.
project_templates:
  - name: .env config
    src: roles/deploy/templates/env.j2
    dest: .env
    mode: '0600'

# The shared_children is a list of all files/folders in your project that need to be linked to a path in `/shared`.
# For example a sessions directory or an uploads folder. They are created if they don't exist, with the type
# specified in the `type` key (file or directory).
# Example:
# project_shared_children:
#   - path: app/sessions
#     src: sessions
#     mode: '0755'      // <- optional, use an octal number starting with 0 or quote it, defaults to `'0755'` if `directory` or `'0644'` if `file`
#     type: directory // <- optional, defaults to `directory`, options: `directory` or `file`
project_shared_children:
  - path: web/app/uploads

github.com

roots/trellis/blob/a81c10b5b0bc01c5ffb61891dd7c6b82c166278a/roles/deploy/defaults/main.yml#L11


# If you use the "git" strategy:
# - you must set a repository (no default)
project_git_repo: "{{ project.repo }}"
# - you can set the git ref to deploy (can be a branch, tag or commit hash)
project_version: "{{ branch is defined | ternary(branch, project.branch) | default('master') }}"

# The source_path is used to fetch the tags from git, or synchronise via rsync. This way
# you do not have to download/sync the entire project on every deploy
project_source_path: "{{ project_root }}/shared/source"

# There are certain folders you'll want to copy from release to release to speed up deploys.
# Examples: Composer's `vendor` folder, npm's `node_modules`.
# These should not be part of project_shared_children since dependencies need to be atomic and tied to a deploy.
project_copy_folders:
  - vendor

# All the templates to process on the remote system on deploy. These could contain config files.
# `src` and `dest` paths work the same as project_local_files.
project_templates:
  - name: .env config
    src: roles/deploy/templates/env.j2

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

system · March 29, 2021, 12:01pm

This topic was automatically closed after 42 days. New replies are no longer allowed.