31

One of the most exciting new features in WordPress 3.0 is the core support for multisite. We’re not using MultiSite for real, so we’re asking your opinion before we get started.

  1. Are you using WordPress MU right now? If so, what for?
  2. Already tried the MultiSite feature in WP3.0? Is it working for you?
  3. To run truly multilingual, what would you need WPML to do on multi-site installs? (a detailed flow would be great)

When?

Our schedule for WordPress 3.0 support goes like this:

  • This week, add support for custom post types.
  • Until the end of May, add support for multilingual menus.
  • Then, we’d like to go after MultiSite support.

Speak out and get involved in the design. This time, we need more than testing. We want you to help build the right features for multi-site support.

31 Responses to “What do you think about WPML and WP3.0 Multisite?”

    • It’s a good point, but there’s not much to do in order to reuse tables for different sites.

      Just like WP keeps different tables for different sites, so does WPML (and every other plugin). You can argue if there’s a way to reduce the number of tables, but it’s difficult to share tables between different sites.

      • Also sharing the same table for all the Multisite is not a good move i think… if some user f**ked up the translation stuff it’s not good…

  1. We currently use WPML and WPMU 2.9.2

    We have many sites that look the same and have teh same multilingual string, for now when we set up new sites we have to copy from our default site the WPML language data separately since it doesn’t copy over easily with this plugin http://wordpress.org/extend/plugins/default-blog-options/ that we use to create new sites based on a template.

    What would be incredibly useful (and I haven’t had a chance to look at your 3.0 version yet so maybe its there) is a way to easily import translations from one site to another (as site admin) so that when creating a new site we can just one click import all our translations (or even better copy all the WPML settings) from one site unto another site.

    What would be “incredible” would be the ability to set up “groups” of sites to which translations apply.
    By that I mean that if in group 1 I have a.example.com and b.example.com. And in another I have c.example.com and d.example.com, that the changes to one group are reflected only in their group.
    (now that could be code that applies to more than one DB at the same time, and it could be limited to site-admins as well, would still be incredibly useful)

    Again Thank you very much for your great plugin.

  2. Quote Amir – “Just like WP keeps different tables for different sites, so does WPML (and every other plugin). You can argue if there’s a way to reduce the number of tables, but it’s difficult to share tables between different sites.”

    That’s pretty close to admitting you don’t understand how to use /mu=plugins/ as opposed to /plugins/ within the WPMU heirarchy.

    At Steph – rehacking WPML to be an mu-plugin (fully or partially) would solve your issue.

    • You’re absolutely right. We’re not big experts in WPMU. This is why I wrote this post, to get others involved.

      Do you have specific suggestions?

  3. Hi Amir,

    I’m not good enough at programming to tell you how to support multisite feature whitin your plugin but if you includ this feature (at least) in your “developer support” program it would certainly justify the $200 expense in my budget.

    Why? Using a “Fundation Theme” will give me a stable base to start new project comming in. WPMU was a solution design for business needs. I would be very desapointed if it doesn’t find his way in a future version of WPML.

    Thank’s Amir. You and your team have produce a very professional “top level” plugin so far. Keep on the good work!

    • It’s on our todo list, but we can’t promise when. For WP3.0, we still need to add support for multilingual menus, so there are other things besides multisite.

      Purchasing a support subscription doesn’t change our order for adding features. We’re doing our best to add everything and are trying to stick to our development plan.

      It would still be good (for you) to get a support subscription. If you’re building sites commercially, this subscription would pay for itself in no time.

  4. Hi,

    I would like to argue that WPML would be most useful in a multisite environment where one install (in the mu-plugins folder) is needed to make it available to ALL sites.

    The main advantage in having WPML work this way is that the plugin is installed ONCE and configured ONCE, to be reused in ALL sites.

    For example, if I had 100 sites [/, /site1, /site2, … , /site100] I would only need to install WPML once and only have one place to upgrade it. In the current form, I have to install WPML N number of times (and configure it that many times too). This is a show-stopper, I would imagine, for any wordpress install that has more than 4-5 sites.

    So… to your questions:

    1. Are you using WordPress MU right now? If so, what for?

    Yes. We use WordPress MU to run a collection of multilingual sites. Each site is managed by different groups; but, each group needs the multilingual facility.

    2. Already tried the MultiSite feature in WP3.0? Is it working for you?

    Absolutely … even better than WordPress MU.

    3. To run truly multilingual, what would you need WPML to do on multi-site installs? (a detailed flow would be great)

    a. Install WPML in one location
    b. Configure WPML for ALL sites via Superadmin.
    c. WPML can ONLY be configured by Superadmin … not by the site admins, since any changes are global.
    d. Keep the same functionality that is currently present in WPML

    Let me know if you need more info … or if you need an extra hand to try and code this.

    • So all your child sites have the same languages?

      If you don’t mind telling, what are these sites for? Any URL?

  5. Exactly. All the sites have English as the base language, but, each one has the option of producing either a French or Spanish page. As such, your plugin is perfect for this. Unfortunately, as I mentioned earlier, the only major drawback is that WPML must be installed on each individual site.

    All the site are located in an intranet … as such, there are no public URLs that I can point you to. The company for which I work has each department managing their own “site”. So… although we all belong to the same company, each department manages their content. In that sense, we are using WordPress as a CMS and each department maps to a site. Hope this makes sense… if not, let me know and I’ll go deeper into the details if I can.

  6. / company (site1)
    |
    |
    ———————————-
    | |
    dept1 (site2) dept2 (site3)

  7. sorry … my previous “diagram” didn’t work out … let me try again:

    / company (site1)
    |
    —-> deptX (site2)
    |
    —–> deptY (site3)
    |
    —–> deptN (siteN)

  8. I would like to see to be able to use separate settings for each site as well. This way, all the sites won’t have to have the same base language.

  9. Hi,
    I mentored it earlier in the forum but I wanted to point it on again.
    I’d use it for a company too wich has every department or branch their own site. My experience with WPMU isn’t the best so I’m using the plugin “WP-Hive”. Maybe I will use it with WP 3 too. So it would be nice if WPML also supports multisite plugins like WP-Hive.
    The most important feature I miss in WP and all plugins is the possibility to bypass the permalink stucture. So that you can setup websites entirely free. For Example using at multisite subdomains and subdirectories at the same time: domain1.com (main site), domain1.com/site2/, domain1.com/site3/, subdomain.domain1.com (Site 4), subdomain.domain1.com/site5/ or with WPML: domain1.com/main-language/, domain1.com/second-language/ or domain1.com/country-or-branch/main-language/ (example: switzerland/de/ or /deutsch/ or /german/) and so on.
    The main language from the project I’m working on ist at this moment German but there will be some sites with the main languages in English, Dutch, Danish, Norwegian and maybe Chinese or Japanese and all sites are in the company network.

  10. For WP3 MultiSite the most ‘urgent’ feature for me would be multilingual support for Custom menus and Custom Posts. Maybe even on top of this all a full support for the Admin backend of WP3. These might all just as well be functions that are already supported in WP3 at some point, but I just want to emphasize these items for translation support.

  11. Excellent … thanks Amir.

    I’ve read the details and want to make sure I understood them properly. To configure the plugin once and have it propagate to all sites I will need to purchase support?

    Also, do you have any idea whether or not you guys will be able to integrate the ability to translate the name of the site? Example:

    *** If /computer is a site ***
    /computer/page1 /ordinateur/page1

    Thanks.

    • You need to purchase support if you want to get technical help from us. Many time, people manage just fine on their own.

      A support subscription is good for getting help with the plugin. It doesn’t cover us doing custom programming.

  12. Thanks for the explanation.

    Another feature that would be critical in a multilingual multisite environment:

    The ability to translate the name of the site – Example:

    *** If /computer is a site ***
    /computer/page1 /ordinateur/page1

  13. I want to throw out there how we use WPMU since some people mentioned that all their sites used the same base language and all of them always used the same languages.
    While I can see that being a common thing, We have approx 70% of our sites with English/French, 20% English only, 10% French only.
    I mention this because I wouldn’t want to be stuck to not be able to have any of the benefits of sharing translation tables because they are not all the same pattern, almost all those sites have the same French and English texts in them. What would be the best solution possible would be to make a wpml translation “set”.

    So for example 1 Group of table is called group 1. and I can assign group 1 to 60 sites, and have Group 2 for 3 other sites and maybe group 3 for a special site that is completely different than the others. I think this would be incredible and I would be more than willing to pay towards the development of this.

    I think it would suit everyone as most people might just use 1 group so it would still be simple for 90% of users but have the flexibility to really do incredible things.

    -Steph

    • I think that we should make WPML work with the Domain Mapping plugin. It’s just not something that we can do right now, as we still have other pressing issues to add for full WP3.0 support.

  14. @Steph

    The home page for WordPress MU domain mapping specifically says (about the plugin):

    “It only works if your WordPress MU site is using sub domains.”

    Again, what I’m trying to do here is have the name of the site translated.

    For example:

    domain.com/departments —> domain.com/département
    domain.com/languages —> domain.com/langue

  15. Hi Amir.

    I’m currently running an important personal project that handles two major discussion points of this thread: ability to have pre-configured settings for all the sub-sites (existing and upcoming) and WordPress MU Domain Mapping plugin compatibility.

    Is this thread still alive or should I post my questions in another one? The subject remains very critical for me, so please let me ask them here.

    What are the conclusions of this post’s survey? What direction have you decided to follow and what features to implement on this subject? What is your related roadmap? Have you added any of the requested features to the upcoming 2.0 release? Have you considered the ability to have pre-configured settings for all the sub-sites?

    Does the 2.0 release finally work with the WordPress MU Domain Mapping plugin as expected? If no, what is the roadmap?

    If these questions have already been answered elsewhere, please send me to right post(s).

    Thanks.

    • We have other plans than adding support for the Domain Mapping plugin. I know that it’s important, but we’re also working on a few other things, which are very important to us.

      In order for us to implement it, we will need to take a developer from another project and assign to it. Would you be interested in sponsoring this kind of activity?

      • I’ll probably have to work in the next few months on a solution for the two concerns. Depending on what it might be and on the results of my assessment of the 2.0 release, I’ll let you know. By that time, if you have anything to share that might help, you’ll be welcome.

        Thanks.