The MU forums have moved to

How do I make plugins active by default? (64 posts)

  1. mrjcleaver
    Posted 16 years ago #

    I have volunteered to contribute code, several times.

    Your answer "it's insane" was at odds with Dr. Mikes "why don't you contribute code". I am simply trying to get a consistent answer before spending time.

    The concepts are inconsistent (are mu-plugins truly plugins if they don't adhere to the full spec of plugin) and the documentation is sprawled (There is no definitive mu-plugins documentation).

  2. lunabyte
    Posted 16 years ago #

    But the concept is not inconsistent. There are plugins, and then there are mu-plugins.

    It's as simple as that.

  3. teach42
    Posted 16 years ago #

    I'm not a programmer. I'm a site admin. I've been a Wordpress user for 3+ years and a huge advocate for it. I'm about to start using WordpressMU for my teacher community of 2500+ users and I'm thrilled to be doing so.

    That being said, it has been an incredibly difficult experience trying to figure WPMU out. There is NO documentation beyond the basic install. And it definitely needs it.

    RE: plugins vs. mu-plugins. I had no idea what the difference was. I have read in several places, that MU-plugins were plugins that you wanted to be active for every blog, and the plugins folder was for plugins to be activated on a per blog basis. So when I see Lunabyte say how simple it is, I have to disagree strongly. It isn't that simple. If it were, we wouldn't be having this conversation.

    On the whole, I have spent an unusually high amount of time trying to figure out basic functions. As someone who has spent quite a bit of time in the open source community, WPMU seems to be significantly worse than average when it comes to documentation. Considering how worth a project it is, it's really too bad.

    I guess may have had some of that info, but it has been down for as long as I've been working on WPMU, and unfortunately the list of FAQ's that WPMU Codex used to have, just says to see that defunct wiki site. So there isn't even an FAQ to refer to.

    I guess this isn't even the right place to be having this conversation, but I figured I'd chime in as someone with fresh, recent experience. My two cents.

  4. drmiketemp
    Posted 16 years ago #

    May I politely suggest stepping up and helping out with the documentation?

    Gotta admit that getting folks to help out instead of just taking all the time is a big minus around here for those who do try to help out. It's one of the reasons why I'm no longer releasing code. (Well that and the lack of respect the developers have for the volunteers around here.)

  5. lunabyte
    Posted 16 years ago #

    "RE: plugins vs. mu-plugins. I had no idea what the difference was. I have read in several places, that MU-plugins were plugins that you wanted to be active for every blog, and the plugins folder was for plugins to be activated on a per blog basis. So when I see Lunabyte say how simple it is, I have to disagree strongly. It isn't that simple. If it were, we wouldn't be having this conversation."

    Ah, but it is that simple.

    Keywords: Active for every blog.

    Note: Active.

    Not activated.

    Some WP plugins can handle that, some can't. For those that can't, a simple contact to the plugin author should square it up. Or you can take the quicker route, and just recode part of it.

    "Most" plugins look to install a couple options. A simple check to see if the option exists, and if not insert some default data does the trick nicely. Also, if the plugin needs a table, same theory applies.

    That being said, a plugins shortcomings aren't for the MU developer to sort out.

    "I'm not a programmer. I'm a site admin."

    From the readme file, included with MU:

    "If you're not comfortable editing PHP code, taking care of a complex webserver and database system and being pro-active about following developments of this project then run, don't walk, to and sign yourself and your friends up to free blogs."

    Can't say you weren't warned.

  6. andrea_r
    Posted 16 years ago #

    - if you aren't familiar with wordpres to begin with, then MU is going to be HARD.
    - documents exist for worpress (see:codex - that the *official* documentation).
    - traditionally, it has been the devs insistence that the majority of docs be written by the community. It is one of the biggest ways they say you can help out.
    - also traditionally, at least in the early days of WP, the same attitude from devs and core community members was the same. Feel free to write docs and to figure stuff out, read the code.

    Not condoing it or saying it's a great idea, but there it is.

    That being said, I am working on some docs.

    For reference, I am "just" a soccer-mom with rusty to non-existant programming skills, but digging into this project has sharpened them. The knowledge is out there if you're good at searching and wading through information and most importantly. poking around on your own and trying stuff out.

    (good recent example: there's a STICKY POST with the correct forum search link in it, and it's at the bottom of every forum sub-topic. Yet still, dozens of people every days cannot find it or use search properly.)

  7. mrjcleaver
    Posted 16 years ago #

    Donncha has agreed to link to Codex from the Forums. He's said we can expect this today. See

  8. andrea_r
    Posted 16 years ago #

    I saw that.

    And nowhere did any of us say documentation was not needed.

  9. ladynada
    Posted 16 years ago #

    Is there a way to have a plugin that only the admin can use, and not the bloggers?

  10. omry
    Posted 16 years ago #

    ladynada, make calls to is_site_admin() in strategic points.

  11. lunabyte
    Posted 16 years ago #

    Search the forums for main site only plugins.

  12. Cimmo
    Posted 16 years ago #

    I'm the author of Cimy User Extra Fields a very famous plug-in for WordPress also linked in this thread and I'm trying to make my plug-in compatible with W-MU.

    I'm very disappointed about some comments, seems sometimes that authors of plug-ins should just do something that is not well documented and is not clear at all.

    I think that WordPress is not well documented and WordPress MU is even worse!
    So let's explain to all that making a plug-in compatible for W-MU is not difficult, is only a long way finding all the differences (not well documented) from the original WordPress.

    Some examples:

    1) users are all in common, can be obvious, but for me no.

    2) plug-ins in mu-plugins aren't activated, they are always just on when you copy the file into, so if you do something in the activation (like creating tables) you have to force it every time (insane) or make a button to do it from the admin panel.

    3) mu-plugins doesn't accept sub-dir or at least first file should be in the root dir

    4) wpdb->prefix simply returns always the prefix from one of the blog, if you want the prefix "clean" from the number of the blog you haven't a function, you have to use $wpmuBaseTablePrefix; variable (undocumented)

    5) some hooks aren't the same, like adding something to the user's registration form, the hook in WP is: register_form
    in mu is: signup_extra_fields

    so the problem for me is not coding, but finding a good documentation that explains all these stuff, so it's not so nice see a lot of users pushing in my blog to support WordPress MU, see that some users are angry with plug-in's authors and see that others are telling that we just do that, also without having the documentation.

    The real question to ask is TO DO a better and more organized documentation that point first to all differences from WordPress and MU one!
    This should be for me the first goal of every project, documentation is more important than adding a new feature, so first should be completed the documentation, then the rest.

    Hope that plug-in's authors point is clear now.

    Marco Cimmino

  13. lunabyte
    Posted 16 years ago #

    Um, your point is clear, but I can't say that it reflects all plugin authors.

    You do bring up some valid points, but there are other logical options as well.

    First, you should keep in mind that mu-plugins is a very "special" type directory.
    99% of plugins don't need to be in there, as they should be in the standard plugins directory instead.

    Only plugins which must be loaded on every blog, and for every single page load should be in there.

    If it's something a user may/may not want, it should be in /plugins/.

    Using $wpdb->table is the proper way to go about it.
    That way all tables from a plugin are correctly associated with the proper blog. Unless one "really" needs a global table (like SK'2 blacklist, for example), then only would you need the true table prefix. If you need the blog id, then there's a variable for that available ($blog_id).

    Granted, in this plugins case, I can't specifically see it being needed. If you want a different table prefix, for example something like my_plugin_{blog_id}_table-name, it just isn't something you want to do in MU. You'll wreck folks blogs with a quickness. Especially if those blogs are scattered over multiple database servers.

    While there are some aspects of the WordPress documentation that could be better, you have to admit that honestly their Codex should be a role model for other projects. Again, there's always room for improvement.

    When it comes to MU, it's 98% WordPress. Yes, there's differences. But, most things still work as intended.

    When a plugin needs activation, simply checking for an options existence is far easier than hooking into the activation process.

    if ( !get_option("my_plugin") ) {

    Always easier to do that, IMHO, regardless of WP or MU since who knows, that plugin activation hook may be subject to change in the future. But, the widely used get_option function is likely to remain the same for quite some time as it's heavily used in the WP core.

    Whether that's just a single T/F entry in the $wpdb->options table, or maybe a version number or something, it's (again, IMHO) a better option to hook into.

    If you need a "sitewide" table, like users for example, $wpdb works just fine.

    "Most" plugins which are, or could be, common to WP and MU won't need to mess with table prefixes, or with global tables. They concentrate on a particular blog, vice the system as a whole.

    Although there may be a need for certain sitewide admin options, which can be tacked to the Site Admin menu, and use get_site_option() for storage. Those are rare cases though.

  14. Cimmo
    Posted 16 years ago #

    lunabyte you missed some points:
    1) I'm not searching for help now, just before! Spent 2 hours to understand all the differences.
    I don't need help to understand *how* to implement mu support, for me is enough understand how it works, then my code implementation is my stuff.

    2) doing a get_option waste querys, mine solution not, a simple button is easier anyway and do not waste cpu cycles ;)

    3) most plugins... I do not care about *most* plug-ins, mine add extra fields to user registration, users in MU are not blog specific, so I need a non specific table prefix in order to make the extra fields available for all users when they want to register their blogs.

    4) Codex is not a model! PHP has a good documentation and should be a model.
    For example a lot of hooks are undocumented, I just discovered them because I look into the code.

    anyway do not want to flame, just before saying that is author's stuff think if they have all the docs they need to code.

  15. lunabyte
    Posted 16 years ago #

    No, I don't think I missed the point, really.

    I was just providing a little feedback, nothing more.

    But, to hit on your response:

    1) Fine. I wasn't telling you how, just addressing your points.


    "doing a get_option waste querys, mine solution not, a simple button is easier anyway and do not waste cpu cycles ;)"

    Sorry, but I beg to differ. If you check out around line 207 in /wp-includes/functions.php, each time you call get_option it doesn't run a query. It only runs 1 query, the first time get_option is called. Which, FWIW, WP and MU will have already done by the time plugins run. As a note, it also is cached, so it doesn't always hit the DB for the results. Provided object caching is enabled, which if you're running MU you'd be "nuts" to not have it enabled.

    3) I'm sure you don't, but there are more plugin authors out there besides yourself who may find this information helpful.

    Better read through the code a bit more. The core calls wpdb->table for the "global" tables (the ones that by default use wp_table-name vice having a blog id in there), and not following SP could in turn possibly break MU.

    4) Maybe you're not familiar with too many open source projects? Compared to a vast majority, WP is actually well documented. Which is where I'm drawing my opinion from. The more you dig into other open source projects, the more you'll be wishing for docs even close to the codex. Yes, it could be better. Everything could be better.

  16. Cimmo
    Posted 16 years ago #

    well I had this discussion with another open source project.
    They all think they have a good documentation, however for me when there are a lot of undocumented things is just enough to say "not a good documentation"

    But they are all opinions and point of views.

    best regards
    Marco Cimmino

  17. lunabyte
    Posted 16 years ago #

    All I'm trying to get at is that it could be a whole lot worse. And oh yeah, it sure could be.

  18. bschwarting
    Posted 16 years ago #

    wow, that was a long read, and very interesting :)

    my two cents:

    lunabyte, a little harsh, but seems to have some good points.

    andrea, drmike and mrjcleaver seem to be great contributors. hopefully they will come back to contributing code, if not, we are all missing out.

    I'm new, and don't mind helping out. I might document my experience of MU and what i learned the hard way. Seems like an incredibly powerful tool for free.

    plugins vs. mu-plugins - 10+ years of IT and it was a hard concept for me to understand at first, now it makes perfect sense. I'll make sure that's a part of my documentation/experience.

    andrea has a great start on the basics here:

    maybe we can all add to them?

  19. logip
    Posted 16 years ago #


    My first post here. I've asked to set up WPMU for a uni of 3000. I'v done a lot of open source stuff but ran into troubles with this one fast. Just one easy question:

    Where are old versions of WPMU? Regular Wordpress has something called 'Release Archive'. Does WPMU also have one? The reason I'm asking is the only WPMU module I really need to use is not working on 1.2.5a and if I don't get it to work the project is dead and that would be a shame.

    best regards, Logi

  20. logip
    Posted 16 years ago #

    Sorry about the off topic post. I just have not figured out how I can start a new thread :) Nei good. I'm also been trying to find any decent documentation on WPMU plugins.

    regards, Logi

  21. andrea_r
    Posted 16 years ago #

    look in trac for older versions of code:

    And my site may help. click on my name.

  22. logip
    Posted 16 years ago #

    Thanks Andrea_r for that. I found version 1.2.1 on the trac page and at the bottom you can download the whole lot in one Zip. Very good. Thanks a bunch, on with the testing then.

    best regards, Logi

  23. redlasso
    Posted 16 years ago #

    Good code documentation is when you can hide all the code and the only text that is left is comments, and the comments tell exactly what is going on.

  24. diniscorreia
    Posted 16 years ago #

    I'm very familiar with "regular" Wordpress and I've recently started a project using WPMU: and yes, there's plenty of good documentation on Wordpress, but not so much on MU.

    Anyways, I didn't really understood at first the differences between the mu-plugins and the plugins folder. The mu-plugins seemed like the one thing I wanted ("global" active plugins"), however, plugins that need to add tables etc weren't running.

    Today I found PluginCommander and it's working great.

    It lets you choose which plugins to activate on newly created blogs. Best solution until there's a new way to deal with plugins in MU.

  25. cougar007
    Posted 16 years ago #

    @Radja (Page1)


    I finally get all my standart plugins activated when someone registers!

    there is only one thing from your line which was:

    $wpdb->query("UPDATE $wpdb->options SET option_value = 'a:1:{i:0;s:29:"cryptographp/cryptographp.php";}' WHERE option_name = 'active_plugins'");

    ... that needed to be fixed.

    The name and the location of the plugin which is inside of the quote needs to be in a backslash quote \"

    So that the line looks like that:
    $wpdb->query("UPDATE $wpdb->options SET option_value = 'a:1:{i:0;s:29:\"cryptographp/cryptographp.php\";}' WHERE option_name = 'active_plugins'");

    If you fix that it will work!

    Please also keep in mind that you must get your personal line so the one above probably will not work for you... it is just an example of how it should look like.

    to get your personal line do the following:
    connect to you database management system via phpmyadmin -> choose your wp mu database -> go to wp_"ID"_options table (where id is an example user where you copy the plug in settings from) - choose/edit the field active_plugins and copy the settings

    Paste it below the the line that Radja mentioned and finally replace some of the quotes with backslash quote (As in the example above)!

    When you follow those steps the plugins are 100% activated ... i just did it like this.

    If you need help with that feel free to shoot me a message
    info (at) woprot dot com is by the way a very helpful wordpress Remote poster ;-)

    greetings from germany :-)

  26. chmac
    Posted 16 years ago #

    WPMUPluginCommander does seem to fit the bill.

    I have another suggestion. If I write a small plugin which automatically activates all plugins in /mu-plugins/ (including subdirectories) will it be included with WPMU core?

    This might solve a lot of problems. It'll be a pretty simple plugin. It just flips through the plugins listed, checks which ones have been activated, and if not yet activated, runs the activation hooks.

    Doncha, what do you say?

    Cheers - Callum.

  27. lunabyte
    Posted 16 years ago #

    And it would parse every file, on every page load?

    I'd think that would be a waste of resources, IMHO.

  28. chmac
    Posted 16 years ago #

    My suggestion is it would store an option in the database to see if the plugins had been activated, if not, run the activation, if they had, do nothing. Given that the options are pre-loaded, it would be pretty light code.
    if (get_option('activation_run') == true) { return; }

  29. chmac
    Posted 16 years ago #

    I'll get round to writing the plugin if I need it at some point. Otherwise, if somebody can confirm (donncha I'm guessing) that it would be included in core, I'll write it sooner.

  30. andrea_r
    Posted 16 years ago #

    you'd have to write it first, submit it to trac, then see what happens.

About this Topic