0

I have a couple of plugins that need to install drop-in modules or mu-plugin modules when they're activated, and remove them when they're deactivated.

This requires copying -- or maybe symlinking -- a php file from someplace in my plugin's directory to either wp-content/ or wp-content/mu-plugins/ on activation.

On deactivation it requires removing that php file.

Why do this? One plugin, still in development, is a persistent object cache to use SQLite as a backing store. That requires a drop-in.

The other plugin requires hooking some stuff that happens during core version upgrades. Ordinary plugins aren't active during those version upgrades, so the mu module is necessary. (sigh)

This can get gnarly on installations with weird file permissions, or when the site owner wants to use composer to configure plugins.

Is there a canonical, worked-out, official way to do this?

5
  • 1
    are these plugins you've installed? It's rare that a plugin would do this, especially since there are a limited number of drop-ins that could conflict between multiple plugins, and an mu-plugin provides no benefits when your plugin is already activated and running
    – Tom J Nowell
    Commented Nov 30, 2022 at 13:52
  • also if I were using composer or another package manager I would want this type of automation to be disabled and turned off
    – Tom J Nowell
    Commented Nov 30, 2022 at 13:52
  • These are plugins for which I am the author. One is a not-yet-released persistent object cache plugin using SQLite, and the other is this. I suppose I could crib off John Blackbourn's Query Monitor. But if there's a standard scheme for handling these dropin modules, I sure would like to use it.
    – O. Jones
    Commented Nov 30, 2022 at 14:09
  • @O.Jones One example is the Memcached plugin which includes the dropin file in the plugin files and includes instructions for copying the file into the right place: wordpress.org/plugins/memcached/#installation Commented Nov 30, 2022 at 14:29
  • Thanks. There's also the Redis Cache plugin. Like Query Monitor, it places the drop-in upon activation.
    – O. Jones
    Commented Nov 30, 2022 at 20:03

1 Answer 1

0

There are no canonical methods for doing this, and in many cases it's undesirable. E.g. more than one plugin may want to override a drop in. You might also be reaching into and modifying files that are managed by the hosting company, which might either break things or trigger problems.

Instead, you should disable any functionality that requires your drop-ins if they aren't installed, and notify the user that they are required and how to set them up.

If you did want to automate it, I'd do it by providing it behind a button the user can press, but there is no official mechanism for implementing this. Generally the attitude is that if you can do it without a drop-in, you should. Since there is no alternatives to drop-ins for some tasks, they haven't been deprecated and still persist to this day.

You mention cribbing off of Query Monitor, I would consider that plugin a good example of what to do. It provides notices to the user that the db.php dropin is missing, as well as instructions on how to install it correctly, and CLI subcommands to automate the process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.