The load order of plugins

[drmike]

Just checking.  Plugins load in alphabetical order, correct?  Just want to make sure.

Thanks,
-drmike

[Andrea_R]

The code may load in that order, but I believe if the plugin calls a function call somewhere in the template, it loads in the order in which it appears on the template.

[drmike]

Thanks

[Luke]

Mu-plugins are actually loaded in the order they come in on disk, or something stupid like that.

It changed at the 1.5 interval, and has on occasion been known to not load some plugins.

[drmike]

Hmmm, only time I never saw a plugin load from mu was when it was within a subdirectory under the mu subdirectory.

Maybe I',m just lucky.

[Luke]

Could be. I fought with it a few times right after 1.5, and then a time or two recently as well.

Since then, I've pretty much moved to a single file in mu-plugins. It has 3 sections, that check for the admin area, not admin area, and then all the time. From there, it includes files from two of the 3 directories. Either admin or public, and then the "all the time" directory.

Cuts out all the problems that way, as the main mu-plugins dir only has to include one file, which never changes.

[Andrea_R]

Dude, that;s a sweet idea.

[drmike]

That came up before.  For us, it seems like most of the mu-plugins we have are both public and admin so it wouldn't do much good.  wp-shortstat comes to mind as an example.  While you see the output on the admin side, something also loads on the public side.

I do have planned moving the widgets over to the own plugin file like edublogs has where folks have to activate it to get the additional widgets.

And all the css from the plugins and what not are in their own file.  Not sure if that's sped things up but our headers look a lot more organized.

[ron_r]

You would have to split plugins into 2 or 3 files. If I'm writing a plugin of any size I use separate files anyway partly looking down the road to doing what Luke has done.

[Luke]

For me, the less in mu-plugins the better. But we've all beat that horse to death.

99% of plugins can be put in the normal plugins directory, and if someone wants it, they can turn it on. If they can't be bothered, they probably aren't worth having as a user.

I'm in the process of building a niche site, and the mu-plugins directory will be practically empty. Then again, some things will be hacked in that would have been there, but that's beside the point.

[ZappoMan]

btw, here's what we're doing these days.

1) we have a mu-plugin that loads "plugins" from directories inside of the mu-plugin directory just like regular plugins. So that means, it scans the comment and looks for "Plugin Name" and only loads the php if that comment exists. This doesn't effect the behavior of files in the mu-plugin directory, only those in subdirectories of mu-plugin.

2) we cache this list of files, and only regenerated it if a siteadmin goes to a special admin page and reloads the plugin list.

Inside of our plugins we've adopted the following design pattern:

a) plugin-name-min.php - this is a super small file which exposes only the minimum APIs and callbacks needed for the plugin to "load" but it doesn't contain the body of the code.

b) plugin-name-min.php will check for is_admin() and other state functions to determine which other helper files it may or may not need.

c) inside of an API call, where something actually needs to be done, it will do an include of plugin-name.php and then call the actual implementation function.

======

The effect of this design pattern is that the *-min.php files load, parse, and execute quickly, because they have very little code.

If and only if the plugin is actually needed does it even load, and parse the main implementation file.

We're pleased with how this is working for us.