Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Add option to place INSTALLed plugins to mu-plugins folder #83

Closed
wpsmith opened this Issue · 11 comments

4 participants

@wpsmith

In light of moving core functionality to a plugin (see links below), is it possible or a good idea to have the ability in the plugin activation class to move an installed plugin to mu-plugins folder?

WP Candy: http://wpcandy.com/teaches/how-to-create-a-functionality-plugin
Bill: http://www.billerickson.net/core-functionality-plugin/
Otto: http://ottopress.com/2011/creating-a-site-specific-snippets-plugin/
Justin Tadlock: http://justintadlock.com/archives/2010/12/30/wordpress-theme-function-files

@thomasgriffin

I like it and I don't like it. I too use a core functionality plugin boilerplate for each project that I work on, but I don't know how I feel about moving things into mu-plugins. Essentially you would be requiring a theme-specific plugin that isn't theme-specific. I think I would rather place the plugin in a site-specific folder first, like wp-content/plugins/site.com instead of mu-plugins. That way users still have the ability to tinker with the plugins and remove them if they want, because inevitably 'must-use' for one theme will not be 'must-use' for another (not all theme authors are smart).

@wpsmith

Since, it's about site core functionality, like cpts, etc., regarding site content, then it isn't so much theme specific. The idea about core functionality being in a core plugin is that it transcends themes. Furthermore, they still will have access and the ability to tinker with the plugins and remove them via FTP. And you are correct in saying that not all theme authors are smart, but I don't believe that should prevent more advanced theme developers from having this feature in the class, even if you don't advertise it. Personally, from those articles, to me, it seems that core functionality is about content, not front-end site design. The argument for mu-plugins is that it is because it will prevent the user from removing/deactivating the plugin which will essentially make them lose their content.

@thomasgriffin

Ok, I see what you are saying. I'm not sure how many people would use it, as most core functionality type plugins are for client-specific projects and are not tailored toward the masses like this class, but I could see a few cases where it would be appropriate. This could be an addition for 2.3.0 along with the strings class.

@thomasgriffin

Actually, the more I think about it, this could be very useful for say portfolio type themes where they absolutely need those CPTs to have their theme function correctly. And you are right, users wouldn't want that type of content to disappear if they switched themes, so I think this is a good idea. It would give theme authors one more reason to move toward the core functionality plugin direction, too.

@thomasgriffin thomasgriffin was assigned
@thomasgriffin

Ok, so I've been trying to think this out. All that needs to change is that there be a check within the installation process to see if the parameter 'must_use' is true, and if so, it will look to see if the mu_plugins dir exists, if not then create it and then move the plugin to that folder. That's pretty much it as far as I can tell. I'll look about testing this out soon so you can too. :-)

@wpsmith
@thomasgriffin

Ok, so looking into must use plugins more, there are a few annoying caveats, one being that only the plugin file should be placed into the mu-plugins folder. This isn't an issue when using a simple core functionality plugin that doesn't have any other files along with it - that's the key. Any plugin that has extra files to include or a directory structure is a pain because I then have to create a file within the mu-plugins folder to load each plugin. I'm sure I'll think of a solution, but I'm not exactly sure if I can pass a variable when writing a file :-P

@thomasgriffin

Hmm, I'll also need to extend the Plugin_Upgrader class so that I can process the correct install path before anything is done with the plugin package instead of moving it around afterward.

@thomasgriffin

Closing this issue as mu-plugins is just too messy and annoying to deal with. Just specify the plugin to be force activated and you will be set.

@DevinWalker

Not to beat a dead horse or anything but this addition would be sweet! Thanks for the awesome class though, it still is super powerful.

@jimmyandrade

My thoughts on the TGM as must-use plugin: when we set which plug-ins are required or recommended for a theme, the register function will continue being part of the subject code. TGM will keep looking for registering action coded on theme to set if the plugin is either required/recommended.

Regarding the problem of WordPress load only the mu-plugins that have a .php file in the folder itself, there is already a way around this. There's an autoloader that enables standard plugins to be required just like must-use plugins. It's Bedrock Autoloader, from @roots.

The autoloaded plugins are included during mu-plugin loading. An asterisk (*) next to the name of the plugin designates the plugins that have been autoloaded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.