The Future of WordPress MU – Have your say

So, still no response to my questions regarding the future of WordPress MU, and I don’t expect we’re going to see any any time soon, so I figured that I’d put down my thoughts as to how I’d like to see WordPress MU and WordPress merge.

And ask you to put your thoughts down too… on your blogs, in the comments, anywhere.

Because surely, as this is up to the community, and as a member of the community, I’m hoping that I have a voice here, and I hope that we can have a discussion.

And I’m also hoping that other members of the community like other Incsubbers, WPMU DEV Premium members, WP.MU users readers of would also like that.

Rather than one individual, or a small group of individuals, privately making a decision.

So, for my part, here’s what I’d like to see (in rough order of importance to me, personally):

  1. That the functionality is still called MU or Multi-User… many of us have build our livelihoods on this and changing it would be like changing ‘Plugins’ to ‘Extras’
  2. That this is absolutely not rushed… the last thing anyone needs is WP (with MU) version 3.0.9b
  3. That there is still an wp-content/mu-plugins/ folder and that existing plugins continue to work in that
  4. That above all, the continuing operation of existing MU plugins and themes that use MU specific code, is placed as a priority where changes are made
  5. That the process is clear, transparent, and up for discussion

So, what are your points of concern regarding the merge of WordPress MU into WPMU?

What questions do you have? What items do you want addressed?

And then, hopefully, those who would make such decisions will take note of our concerns and opinions and include us in the discussion.

That wouldn’t be too much to ask… would it?

17 Responses

  • I have not looked at this for a while, but does WMPU now work on a different HTTP port? We have limited external IP’s and have different services running on different ports… I would like to use WPMU, internally and externally but was limited by this in the past… could this be a future development?

  • Sure it would be easier for a developer point of view.
    I’m rather a supporter of 1 product but flexible enough to build things on it than multiple flavors of a same product.

    My main concern is about WP administration: WPMU is not crystal clear and I don’t expect a beginner to confirmed user to manage a WordPress blog without having a huge headache.

    The mapping of URL has to be simplified too, to allow both subdomains, domains and subfolders (following a defined pattern).

    It’s not an easy move so it should be carefully and well thinked.
    Dotclear is another blogware with multi-blog enabled by default and it’s far from beeing complicated to administer.

  • 1. As I said in my email to you last June, I think the merged product is going to be called WordPress. I’m fairly sure of that now.
    2. Definitely won’t be rushed. It has to be done right, with easy upgrades. It has to be as “easy” as upgrading to a new version.
    3. There has been support for an mu-plugins folder in WordPress itself for the last 7 months.
    4. I can’t imagine that wouldn’t be the case. Most of the filters are used by WordPress itself.
    5. Definitely. Any help that can be given will be gladly accepted. Get on Trac and submit ideas, tickets, and patches. PLEASE!

    Tom – want to help? Get your coding hat on and submit a patch. If your business depends on the software, assign a developer to help part-time. It’s GPLed. Participation is the name of the game.

  • New Recruit

    +1 to what Donncha said. I’ll add that we’ll definitely give the Site Admin menu/screens some UI love before the merge. Really, merging MU and WP core will benefit everyone, because it will be more flexible and we’ll have fantastic developers collaborating rather than operating in silos.

    To your point about hoping you have a voice: everyone has a voice. The core team listens and then makes a final decision based on a variety of factors. That said, right now the WP core team is focused on 2.9, which is about to hit feature freeze, so the merge is not being planned behind closed doors as your post kind of makes it sound. When the team is ready to move on to 3.0 and figuring out the merge, there will be many dev chats, blog threads, forum threads, etc. devoted to how it should work, and such opportunities for joining the discussion will be announced on the dev blog when it starts gearing up. To make your voice heard at that point, I would suggest getting involved with the official community channels such as the weekly IRC dev chats and the discussion threads that take place on (The official MU channels will also be active, obviously.)

  • I really don’t care what it’s called. Our users don’t care what it’s called. As long as it works, they’re happy. (Of course, I have no monetary gain from WPMU, per se. All of my work is part of my normal salaried position, and if the WPMU functionality went away (not that I’m expecting that), work would suck, but we’d pick up the pieces and move on.)

    I did hear talk of the mu-plugins folder being deprecated. (It’s in a video of “how not to build plugins” from the recent Portland Wordcamp. That does concern me as well. However, if, say, for example, the full functionality of Plugin Commander and then some was incorporated into core, I think I could live with the mu-plugins directory going away.

    But, speaking of plugins, one of the things I’d like to see incorporated into the merge is some sort of clean up process for the plugins repository, and an improvement in the search functions for it. Right now it’s a mess, and I know there are on-going discussions about what to do about that. While lots of plugins do currently work with MU, there are lots that don’t – some of which fail fairly spectacularly. Even a way to limit the plugins you view to those that have been tested on the version you are running would be an improvement….

    I’d love to see domain mapping made a part of the core. I’d also love to see default settings for new blogs incorporated into the core. (I’ve already offered to help with that one.)

  • New Recruit

    I’d like to throw in my two cents, but first want to ask – mu-plugins support is already in WordPress? Is that right? Any detail on this would be appreciated. That’s something I’d like to play with.

    In one sense I think that the whole debate about merging is backwards. Wouldn’t it make more sense to abstract out MU so that when teh time comes to merge, the entire wordpress codebase can simply be dropped in? If MU can be thought of as an administrative layer on top of wordpress, and perhaps run out of the mu-plugins folder in toto, then that would probably be a lot less messy in the long term.

    In fact you could theoretically use the same approach for a “meta dashboard” whch lets you manage multiple wordpress blogs from one location, even if they are separately hosted. Some sort of Admin-API might be the best route, which would let you manage MU wordpress either within the same database (WPMU as it exists now) or multiple single-user wordpress installs across separate databases, even separate servers.

    My point is that the meta-nature of WPMU should be emphasized with core wordpress functionality essentially agnostic to whether its single-user, or being run in a MU environment.

  • New Recruit

    “That the functionality is still called MU or Multi-User… many of us have build our livelihoods on this and changing it would be like changing ‘Plugins’ to ‘Extras’”

    “As I said in my email to you last June, I think the merged product is going to be called WordPress. I’m fairly sure of that now.”

    These two don’t necessarily contradict. It only makes sense that the merget *product* be called WordPress. However, there is a major difference in how WordPress users see WP works, and how WPMU powerusers see WPMU work. The difference is that WP user thinks in terms of a blog, while WPMU user thinks in terms of a site.

    On the technology side this comes evident in the plugins. Mu-plugins folder means more than just activating plugin on every site. It taps into to MU functionality. The issues there are different and these plugins should not be confused.

    Therefore it is sensible to talk about Multi-User functionality – or rather: Multi-Blog functionality. WordPress users who only ever use one blog never run into it, some may use some of it – while others use it extesively. This last group is the potential customer base.

    So, let’s think about an ideal case. There is a repository for non-MU plugins, from where these plugins can be installed from within the WordPress Admin area. Done. There is another repository for MU plugins, from where these plugins can be installed from within the WordPress. Undone. The users of these plugins are likely to be powerusers, who may be willing to pay for some service.

    So, in this ideal world, the MU-plugins would be hosted on some MU dedicated site, where an active MU-community would focus on MU-development. It is also important that some of the stuff there were free, as in free beer, as well as some of the advice and that the community would entail also non-paying members. (Of course there are different classes us members: free, paying and devs, each with their own needs.)

    And then there would be this plugin, say “MU-Support” that the powerusers could use to access to that site and it’s forums and install and update their mu-plugins and stuff, and could enter an eCommerce store, from where they could buy goods and services from any of the developers willing to sell them there. (For example, you could buy a subscription to access all the premium plugins and entrance to the premium forums for a period of time, or you could buy some pieces of high-quality documentation.) Just make sure that all MU plugin authors have a chance to sell at the same site with same terms. You don’t want to fight against each other.

    Everyone wins: Users get Multi-User functionality to WordPress, WPMU technology thrives and has demand for support, powerusers get an easy access to all the MU resources they could need, MU plugin developers get an excellent marketing channel for their expertise and a community, where to hook their prospective clients.

    So, let the product be called WordPress. And let there be a community of WPMU developers and users and their site. Let that be an All-Things-MultiUser site, both free and commercial. (If they use the freebies, they are more likely to buy the services as well. Let there be a virtual marketplace, where devs can advertise and/or sell their products and services (e.g. documentation and subscriptions). And let there be a plugin, with official visibility, that connects these two. Those who settle for free, would find all the free stuff and some open forums, while others would know that this is the place from where they get support for their money – and all of them could download the plugins they are authorized to download directly from the site, using the site Dashboard.

    How does that sound to you? As a user, I’d love to see something like that :)

    BTW, GNU Project has an official philosophy about selling Free Software:

  • New Recruit

    Thanks for all the excellent comments guys – I won’t address everything as I’ll be here all day but special thanks to Jane and Donncha!

    On what you guys have said, I guess I should clarify re: names… as you know we have a range of products that are extremely MU focused, think, wpmu dev, and even

    So I thought about how the ‘Themes’ submenu became ‘Appearance’ and that’s what stresses me out… if (for whatever reason) the Multi-User or MU tagline as a submenu item (under which would come site admin etc.) is changed then we will lose an *enormous* amount of brand equity.

    It’s a scary thought how much a change like that could screw up our businesses, which is why I’m uber sensitive to it and also to Matt’s general distaste for us.

    If you were in my shoes, I’m sure you’d feel the same way.

    And on that line, in terms of contributing, we’re currently looking into ways that we can support developers that work with us in terms of doing just that.

    It’s never been out intention not to contribute in that way, but when you are a two man band (no $30m VC round for us!) trying to eek out a living it’s not that easy.

    I will say though Jane, I’m not that keen on the ‘official channels’ side of things personally – I think contributions in terms of communication and ideas should be accepted regardless of channel… sure, there has to be a core code repository, but there’s no reason that voices can’t be heard outside of that.

  • Well I do care about what MU functiomality is called in WordPress.
    It should be labled “Community”.

    I consider MU a deployment tool for WordPress, a handy but very limited tool mainly because of UI and installation. Until I joined Now I consider MU a development of WordPress on steroids geared for Community.

    Should I be GPLed and arguing about not having to pay for premium development? Sure, but I would be really stupid if don’t understand the huge time and effort put into development of something quite different from standard MU. In fact so good that everyone wants this functionality in core, a lot different from just a deployment tool.

    I think that WordPress have to reconsider the whole idea of MU and turn it around. Enable WordPress to ‘include’ other hosted blogs and share a repository with plugin and code, basically keep the mu-plugin directory.

    Instead of just limit blogs from one MU installation, make it possible to connect and disconnect blogs to a Community network. In case of Community enabling WordPres, MU would still have its use and also give the possibility to administrate networks.

    I’m also a firm believer in paid support and development and think that any company doing things you do, for premium, benifits the whole community. It would not have been possible to develop MU this much unless corporations can pay for premium development.

  • New Recruit

    I think the actual product name should of course be WordPress, but the MU brand should get some brand visibility within the product. I think a “Multi-User” section within the WordPress dashboard would be fair enough. This would help a lot people who work on that side of WP using that brand, and that in turn would help the Multi-User functionality development in itself. Donncha, Jane, opinions? Is that too much to ask?

    As for the name, I think “Community” isn’t too good proper noun as it’s way too generic. Google for “Community” and “WordPress MU” and you get the point. It wouldn’t serve anyone. But maybe the the “MU” could stand for something cooler? Master of the Universe?-)

    As for the multi-domain functionality, I really don’t think it should go to the core. Get real. I’m positive most WordPress users don’t even have multiple domains, so it’d be useless overhead for most. Why bloat the core? But a free – free as in free beer – plugin would be fine.

    How about James, if you people gave three high profile birthday gifts to the Multi-User capable WordPress 3, such as a free – both as in free beer and as in free speech (=GPL) – domain mapping plugin with cross site scripiting, loadable directly from the WPMU Dev site to the WordPress installation? And as a premium service a possibility to limit the use of that plugin to supporters/upgraders only? (The two other options being that it is re-written in an incompatible way effectively deprecating your code or the GPLd code is included without your co-operation.)

    As I see it, everyone wins. WP3 wont hit the streets tomorrow, so you’ll get time to adapt. Common WordPress users aren’t bothered with a feature the’ll never need, people who need it can get it for free and learn about people who do other great stuff as well, and people who want to make money by restricting the the functionality, get to pay for it to the people who have well earned the money. Think about it.

    Oh, and I think the WPMU Dev premium customers would benefit in the long term, if you hung around the trac and contributed your code to the hooks and design and whatever – with the intent of building some awesome plugins on them. Not to talk about being able to label all your products as “WP3 compatible” on day 1 :)

  • I can’t wait for MU to be integrated. And I’m looking forward to seeing Jane’s UI love in there.

    @PSE – you should not wait to upgrade. Always upgrade, even if it seems like an interim step.

  • Well, I’m not a wpmu user but I have it installed on my development server and I follow it’s development.

    What I think is just simple: WordPress should be droped alltogether and replaced by wordpress mu. But the MU functionality should not be enabled by default.
    There should be an options page where I could enable the MU functionality specifying some stuff as if I want to enable subdomains or the folder style environment.

    Once it’s enabled, the Site menu would just appear on the dashboard and everybody would be happy.

    This way WordPress would still behave the same way it does now and the Multiuser environment would be just a click away (and some server tweaks, off course).

    As of the MU or Multiuser term, that’s another topic for discussion.
    I see your problem with this term being replaced by something else but the fact is that this term will be problematic once they are merged into one product, because WordPress is already multiuser (as it accepts multiple authors, editors, subscribers and administrators) so the “normal” user that’s new to all this wordpress stuff could just think that he must enable the ‘Multiuser’ environment to have multiple authors, administrators… Not the case.
    I think it can cause some confusion…

    Let’s wait and see what we get. Or let’s participate!

Comments are closed.