Mu-plugins Not Working

[Lynn Hepler]

Im trying to load plugins automatically by putting the plugins into mu-plugins folder. But if the plugin is put in a folder, it isn't loaded. I tried some popular plugins such as W3 Total Cache, WordPress SEO By Yoast, but all of them are not loaded.

I've recently faced this very issue and in order to avoid mixing all plugins or patching files to keep organization, I've found that you can actually keep all plugins within separate sub-folders and create a symbolic link in the the mu-plugins folder pointing to the plugin's main file within the respective sub-folder.

I have been working on running WordPress inside Docker containers, and am using mu-plugins to run scripts on the server. I found out there is a global constant in WordPress called WPMU_PLUGIN_DIR that will help solve this problem.

Must-use plugins (a.k.a. mu-plugins) are plugins installed in a special directory inside the content folder and which are automatically enabled on all sites in the installation. Must-use plugins do not show in the default list of plugins on the Plugins page of wp-admin (although they do appear in a special Must-Use section) and cannot be disabled except by removing the plugin file from the must-use directory, which is found in wp-content/mu-plugins by default. For web hosts, mu-plugins are commonly used to add support for host-specific features, especially those where their absence could break the site.

Despite its suitability for many special cases, the mu-plugins system is not always ideal and has several downsides that make it inappropriate in certain circumstances. Below are several important caveats to keep in mind:

The code handling /mu-plugins/ was merged into the main WordPress code on 03/07/09 with this changeset a full 10 months before the wpmu codebase was initially merged, and all WP sites could take advantage of autoloaded plugins, whether they had MU/Multisite enabled or not. The feature is useful for all types of WP installations depending on circumstances, so this makes sense.

I've looked at other posts regarding mu-plugins but I don't understand yet. Here's the situation: My site is hosted by a service that automatically sets up 2 caching plugins. Cloudflare and OP Cache. They were originally installed in the mu-plugins folder. I'm not sure what happened, as there are multiple people working on this site, but they all disappeared.

So I guess when I reinstalled them, it put them in the normal plugins folder. If I delete the mu-plugins version, I can then activate it. However, what I'd like to do is keep them in the mu-plugins folder and activate them from there, but they don't appear unless they're in the normal plugins folder.

So code in the mu-plugins folder will never have an activate/deactivate link. You can never put code in both mu-plugins and plugins. You also can't just put a plugin in mu-plugins, it needs a PHP file that includes the plugins main file to work.

MU plugins behave a bit differently as Twerking N00b hinted at and must have an init file in the ROOT of the mu-folder (unlike normal plugins). The structure you should aim for is one init file per mu-plugin, and then the folder with the actual plugin code. The only thing the init file does, is one line with an "include", that includes the main plugin file.

Note: WordPress only looks for PHP files right inside the mu-plugins directory, and (unlike for normal plugins) not for files in subdirectories. You may want to create a proxy PHP loader file inside the mu-plugins directory:

Warning: We strongly recommend performing a complete backup of your site before changing things or adding code to server files in case anything goes wrong. Snapshot makes backing up and restoring WordPress sites a breeze!

Sticking with Elementor for this example, you may decide to hide this to avoid problems and leave the theme customization path inside the admin area at Templates > Theme Builder. Or you may decide to remove it altogether, because even if you disable options from the admin bar, some users may still not understand what it is and why it displays on the front end of their sites.

Note: You can use the previous step to hide the Elementor templates only (to keep your theme safe) but still leave access in Elementor to create and modify pages. This, however, can be risky, since when users are on an Elementor page, they can navigate to other elements like the header or footer, or access Elementor global settings that will affect the site.

Again, you can use Branda to customize the admin panel and the left menu or hide/show menus depending on the user role. This is great if you are the only admin and want to display the minimum required menus for end users or add custom CSS.

The autoloaded plugins are included after all mu-plugins and standard plugins have been loaded. An asterisk (*) next to the name of the plugin designates the plugins that have been autoloaded. To remove this functionality, just delete web/app/mu-plugins/bedrock-autoloader.php.

A MU plugin, also known as a must-use plugin, is a plugin that is installed in the /wp-content/mu-plugins/ directory of WordPress. Typically MU plugins, if they are present, are activated and cannot be deactivated, unless you manually remove them. Usually they are used to perform specific actions or add features on all sites in a multisite installation, like adding custom code or changing global settings of WordPress.

MU plugins in WordPress can be used in single site installations. These are typically done with web hosts that require sites to have features that work well with their setup, like caching and security. For example, some web hosts add the Limited Login Attempts to the MU Plugins folder and do not allow users to manually remove the plugin from their WordPress installation. The Limit Login plugin helps with stopping bot attacks from gaining access to the WordPress admin or overwhelming the site from tons of login attempts (also known as a brute force attack.)

MU plugins cleverly help improve the performance of WordPress websites, especially in multisite networks, because they only load once. And yes, they still load once if several sites on that network have it activated.

To install an MU plugin, you can use a FTP client. Below is a short step-by-step guide on how to do that. Please note that if you use cPanel through your web host, you can use the File Manager to also manually install a MU plugin in WordPress.

MU plugins in WordPress can be a cleverly powerful tool to not just manage many sites within a multisite network because it can efficiently help with performance. If you install MU plugins, make sure to use best practices within this article to keep your WordPress sites running smoothly.

Hi,

I want to install it on a multisite. The plugin should be available to all websites so I guess that I have a choice between activating the plugin for the network or putting it in the mu-plugins folder. But what will be the difference? Or is it equal to my situation?

I would suggest using Network Activation. If you are running it in multi-site I would also suggest pre-populating your license key for new sites that are created in multi-site by adding code to your wp-config.php file.

What this will do is pre-populate the license key on the settings page so you don't have to do it for each site. Just keep in mind it will only do this when a site is first created, so existing sites won't be pre-populated.

No idea why off the top of my head other than not implementing the code properly. It should work. Others are using it, as are we. Make sure the key is correct int he code is added properly in the wp-config.php file. What exactly do you mean by "crashes it", do you receive an error?

Composer with WordPress is a complicated issue, but something that works well for whole site management. Both deliciousbrains.com and spinupwp.com are WordPress sites with their core files, plugins, and themes managed by Composer. Managing free plugins and themes from WordPress.org with Composer is easy thanks to the awesome Composer repository WPackagist, and even using premium plugins with Composer is possible, depending on the plugin author.

WordPress must-use plugins are a special type of WordPress plugin. They are installed in a different directory inside wp-content, and unlike normal plugins that are activated or deactivated by an administrator, these plugins are automatically loaded by WordPress.

So now your plugin is loaded automatically by WordPress! To be honest, for most mu-plugins this is great and all you need. Especially as most mu-plugin code will be very specific to their site, so they can be stored in version control instead of being managed by Composer.

For site-specific code, I prefer to keep it outside of WordPress plugins or even mu-plugins, sitting in an app directory next to my public directory. I can then benefit from PSR-4 autoloading with Composer, so I can create new classes and instantiate them anywhere without having a bunch of require_once file statements at the start of my code. You can see an example of how the site is structured here, which is our starting point for Composer-based WordPress sites that are primed to be hosted with SpinupWP.

The testimonials that appear throughout deliciousbrains.com (mostly in the form of tweets) are actually managed in the dashboard as a custom post type and their location on the site is controlled using Advanced Custom Fields. We have a similar setup for our alert bars that sometimes appear at the top of the site when we launch something new or have a special promotion going (if you head over to our WP Offload SES page right now, you might see one in action). We needed to replicate the same functionality on spinupwp.com so it made sense to reuse the existing code.

Initially I thought it would be as simple as creating some new libraries of code that I could host on GitHub, link to packagist.org so I could easily require them with Composer. The code would sit in /vendor and I could instantiate any classes from a site plugin or theme.

3a8082e126