Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Thomas Scholz 1:17 pm on 2014/10/28 Permalink | Reply  

    How to disable broken save_post callbacks 

    Many plugins are not multisite aware. This is rarely a problem, because each site in a network works almost like a normal site in a single-site installation. But sometimes … things go really wrong.

    There is a hook, the action save_post, that can be called multiple times when a post is saved: one time for each site. Many plugins are not aware of this, they run their own code on every call to save_post without a check for the site context. The result is that they are either deleting user data on the other sites, or they overwrite existing data.

    This happens when MultilingualPress updates the post translations.

    Site A save_post - MultilingualPress {
        creates or updates translations:
        - switch_to_blog( Site B) -> save_post
        - switch_to_blog( Site C) -> save_post
        - switch_to_blog( Site D) -> save_post
        return to Site A

    MultilingualPress removes all POST data before the other save_post actions are called, and it restores it when it switches back. Normal plugins use a nonce as a basic security check before they try to save anything. Since we remove the nonce along with the POST data, they will not do anything. So far, so good.

    Unfortunately, some plugin author don’t use nonces. They just try to save their data, without proper context checks. There is nothing we can do about that.

    But you can. You have to find the code (function or class method) that is registered for the save_post action and then remove it earlier. There is another hook that runs right before save_post: the filter wp_insert_post_data. You can hook your own custom callback to that filter, check if the current context is in a switched site and then remove the “evil” callback. Don’t forget to return the filtered value, that’s necessary for filters.

    Here is an example for the Custom Sidebars plugin:

    add_filter( 'wp_insert_post_data', function( $data ) {
        if ( is_multisite()
            && ms_is_switched()
            && class_exists( 'CustomSidebarsEditor' )
        ) {
            $cse = CustomSidebarsEditor::instance();
            remove_action( 'save_post', array( $cse, 'store_replacements' ) );
        return $data;

    If you are a plugin or theme author and want to be sure that your code is safe to run in a multisite: please contact me. I,or one of my colleagues, will look at it and tell you what needs to be changed.

  • Thomas Scholz 8:31 pm on 2014/10/22 Permalink | Reply  

    Manage multisite per command line 

    Sven Hofmann has written a long tutorial in German in which he explains how to use WP CLI to migrate a multisite installation, import content and deal with common problems. I have asked him to split that article into two posts and publish it in English on

    The results are:

    This is incredible useful information. Read it, try it, and speed up your workflow.

  • Thomas Scholz 9:37 am on 2014/10/20 Permalink | Reply  

    A basic plugin for MultilingualPress 

    Plugins for MultilingualPress should wait until MultilingualPress is actually loaded. That means they should use a hook provided by the main plugin to be sure that MultilingualPress is running and ready to be used. There are three main entry hooks:

    1. inpsyde_mlp_init: equals to plugins_loaded, 0 plus MultilingualPress loaded. Happens before scripts and stylesheets are registered. The only parameter is an instance of the class Inpsyde_Property_List which holds useful plugin information.
    2. inpsyde_mlp_loaded: Almost the same, but after the scripts are registered.
    3. mlp_and_wp_loaded: equals to wp_loaded, 0 plus MultilingualPress loaded. The first parameter is again the same Inpsyde_Property_List. When in doubt use this action.
      wp_loaded happens after WordPress has checked if the current blog was marked as spam. Unless you want to run your code on spam blogs, wait for this action.

    When we use type hints in our callback function, we should declare the dependency for the first parameter against the interface Inpsyde_Property_List_Interface, not against a concrete class.

    First example

    (All code examples here require at least PHP 5.3.)

        function( Inpsyde_Property_List_Interface $mlp_data ) {
        // your code here

    The class Inpsyde_Property_List

    This class is very similar to a stdClass from the PHP core: just some key-value pairs. There are two important differences: an Inpsyde_Property_List can be made immutable, and it can have a parent class.

    To make an instance of this class immutable, we call its method freeze(). Once that is done, there is no way to change any data of this class. Any attempt to do that will return an instance of WP_Error. We can test that with the method is_frozen() which returns true or false, depending on the current state.
    The instance we get from MultilingualPress is always frozen. We can rely on its data, because no matter how many plugins access it, they cannot change it.

    What should we do if we want an instance with almost the same data, but some of them with different values? We create a new instance and use the existing one as its parent. Now we can change the values for our internal use and use the other values as if they were properties of our new instance.

    Usage example for Inpsyde_Property_List

        function( Inpsyde_Property_List_Interface $mlp_data ) {
            $ours = new Inpsyde_Property_List;
            $ours->set_parent( $mlp_data );
            $ours->plugin_url = plugins_url( '/', __FILE__ );
            $ours->css_url    = "{$ours->plugin_url}css/";
            $ours->js_url     = "{$ours->plugin_url}js/";
            $ours->image_url  = "{$ours->plugin_url}images/";

    This approach avoids common problems with classic inheritance, like the fragile base class and statically linked dependencies. We could call it delayed inheritance. The concept is explained in Steve Yegge’s article The Universal Design Pattern.

    We will look at the various default properties from MultilingualPress in a separate article. For custom code, we need just one important property:

    The autoloader

    The property loader holds an instance of the class Inpsyde_Autoload, a very simple Collection Pipeline for instances of the Inpsyde_Autoload_Rule_Interface which handle the actual class loading. Sounds complicated, but it is dead simple.

    Let’s say our plugin is organized like this:

    - plugin.php // the main file
    - css/ // stylesheets
    - js/ // scripts
    - php/ // PHP classes
        - Plugin_Name_Controller.php
        - Plugin_Name_Model.php
        - Plugin_Name_View.php

    Now we want set up an autoloader to get our classes when we need them. There is one existing class for that, we can reuse it to create a new auto-load rule: Inpsyde_Directory_Load. It takes a path to a directory, and we pass its instance to the Inpsyde_Autoload instance provided by $mlp_data->loader.

    Usage example for Inpsyde_Autoload

        function( Inpsyde_Property_List_Interface $mlp_data ) {
            $load_rule = new Inpsyde_Directory_Load( __DIR__ . '/php' );
            $mlp_data->loader->add_rule( $load_rule );
            // We can just use our classes now, no 'require' needed.
            $model      = new Plugin_Name_Model( 'foo' );
            $view       = new Plugin_Name_View( $model );
            $controller = new Plugin_Name_Controller( $model, $view );

    All we have to take care of is that the class names match the file names. This works for interfaces and traits too. Inpsyde_Directory_Load works with flat directories only, it doesn’t search in child directories. It is very fast, because the complete directory is read just once. There is no separate file_exists() check for every class name.

    And that’s all we need for a start: Hook into mlp_and_wp_loaded, register the directory for the auto-loader with the help of the property list – and write awesome code!

  • Thomas Scholz 11:03 am on 2014/10/17 Permalink | Reply  

    How to add icons to the language nav menu items 

    By default, our language navigation menus show the language name in its native spelling. This intended: We want to discourage the use of flags for languages. But we do offer the option to use a custom image for each site, and if you want to use that, you can add it to the link text.

    The hook for that is mlp_prepare_nav_menu_item_output. You get two variables as input:

    1. $item: The nav menu item, an instance of the class WP_Post with some extra properties.
    2. $translation: An instance of an implementation of the Mlp_Translation_Interface. If we couldn’t find a translation for some reason, this variable is NULL, so you have to test it before you work with it.

    The $translation has a method get_icon_url() which is again an object: an instance of the Mlp_Url_Interface. It can be casted to a string to get the URL. Another way is calling the method __toString() directly. If there is an icon, the escaped URL is returned. You get an empty string otherwise.

    Here is how you can use it:

     * Adds an icon to the menu text
     * $item is passed as an object handle, so this function can change it directly
     * and doesn't have to return anything.
     * We still return a string value to make unit tests easier.
     * @link
     * @wp-hook mlp_prepare_nav_menu_item_output
     * @param   WP_Post                        $item
     * @param   Mlp_Translation_Interface|NULL $translation Might be NULL
     *                       if there is no translation for the item or
     *                       the other site is not linked to the current
     *                       site.
     * @return  string  When and why we stopped.
    function mlp_add_icons_to_menu( WP_Post $item, $translation = NULL ) {
    	if ( ! is_object( $translation ) )
    		return 'no translation object';
    	if ( ! class_implements( $translation, 'Mlp_Translation_Interface' ) )
    		return 'invalid translation object';
    	if ( FALSE !== strpos( $item->title, '<img' ) )
    		return 'icon already present';
    	/* $translation->get_icon_url() returns an instance of
    	 * Mlp_Url_Interface, so we have to cast it to a string
    	 * before we check it with empty().
    	 * @see Mlp_Url_Interface
    	$icon_url = (string) $translation->get_icon_url();
    	if ( empty ( $icon_url ) )
    		return 'no icon available';
    	$item->title = "<img src='$icon_url' alt=''> $item->title";
    	return 'success';
    	'mlp_prepare_nav_menu_item_output', // hook
    	'mlp_add_icons_to_menu',            // callback
    	10,                                 // priority
    	2                                   // number of accepted arguments

    Download as plugin: MultilingualPress Addon: Nav Menu Icons. Activate it as a network plugin, and it will just work without further configuration.
    You might have to adjust the image position in your stylesheet. Example:

    .mlp-language-nav-item img {
        vertical-align: middle;

    Here is a screenshot of such a changed menu with our built-in flags. Again: please do not use these flags. :)

    Navigation menu with icons

    Always add an alt attribute, but leave its value empty if you still have text, so users with screen readers don’t have to waste their time with it. The item text is good enough.

    • Jeroen 9:07 am on 2014/11/11 Permalink | Reply

      Hi Thomas. I posted a question on the plugin support page of MLP. The question was about adding a language button in my menu. They directed me to this post you wrote. I succeeded in installing the plugin. But where in my WordPress dashboard can I edit something to make this work? And what editing is needed? Some help would be awesome ;-).

      • Jeroen 9:14 am on 2014/11/11 Permalink | Reply

        I’m so sorry. I just now see that network activate already did the job! It picks the flag-url from the site settings and adds the image to the top menu without needing to edit anything. Awesome add-on!!!
        Thank you so very much :-)

        • Thomas Scholz 10:17 am on 2014/11/11 Permalink | Reply

          Thanks for the feedback. The activation of the plugin deserved indeed a short explanation. I have added one, plus a suggestion for the theme’s stylesheet.

    • Gus 10:09 pm on 2014/11/20 Permalink | Reply


      I am trying to insert the language selector plugin in a template monster header but it seems impossible…

      • Thomas Scholz 1:23 am on 2014/11/21 Permalink | Reply

        Please use our support forum to explain the problem, add your ode and the error messages that you get. I’m sure that we can find a way to solve it. :)

  • Thomas Scholz 7:22 pm on 2014/10/15 Permalink | Reply  

    MultilingualPress 2.1.2 “Edith Fellowes” 

    This release is dedicated to all people who care about ugly things, because that’s what we do too.


    • Combine all scripts and stylesheets, separated for frontend and backend.
    • Minify scripts and stylesheets when SCRIPT_DEBUG and MULTILINGUALPRESS_DEBUG are not set.
    • Make the icon/flag for the current site available in nav menus (tutorial follows).
    • Sites with custom name are now returned in Mlp_Language_Api::get_translations().
    • Better updates: Make sure that site relations are not lost and languages are not duplicated.
  • Thomas Scholz 10:38 am on 2014/10/01 Permalink | Reply  

    MultilingualPress 2.1.1 “Kris Kelvin” 

    No matter how smart your own tests are – you users are smarter. This release fixes the bugs they found and reported. Thank you all for the feedback!

    I named this release “Kris Kelvin”, because …


    • Fixed autoloading with glob() on Solaris systems. This deserves a separate post here.
    • Fixed database error when upgrading from a preview version of the 2.1 branch.
    • Custom flags are now fetched from the correct site.
    • Built-in flag icons are checked on the file system before we return an URL from them.
    • Language switcher widget is now visible for all users.
    • Improved description of the widget options.
    • Search pages are translated correctly.
    • Pro: Table duplicator works with custom tables now. Blog post and new plugin for that will come too.
  • deku86 2:34 pm on 2014/09/26 Permalink | Reply  

    Multilingual Press 2.1 is out now! 

    Today we released the final version 2.1 of Multilingual Press. The release includes a lot of improvements and great new features. A full list of all changes you can find in the Changelog. Thanks for all the feedback of the RC!

    Changelog 2.1.0

    • Added links to translations to the head element.
    • Relations between sites are now stored in a separate table mlp_site_relations. This is faster than the previous option call, and it is less error prone, because we don’t have to synchronize these relations between sites. The old options will be imported into the table automatically during the upgrade.
    • You cannot edit trashed translations anymore. If a translation has been moved to trash, you get a notice on the original editor page now, not the post content.
    • Post meta fields in poorly written plugins will not be overwritten anymore. We had many reports about plugins without a check for the current site when they write meta fields. Now we remove all global post data before we synchronize the posts, and we restore them when we are done.
    • The HTTP redirect will respect the visitor’s language preference now correctly.
    • All users who are logged in can disable the automatic redirection in their profile settings now.
    • You can see for which site the HTTP redirect is enabled in the global site table in the network administration in an extra column.
    • Installation and uninstallation are heavily improved now. We catch many more edge cases and switches from Free to Pro.
    • Languages are now synchronized between MultilingualPress and WordPress. When you assign a language in MultilingualPress to a site the first time and the language files are available, we set the site language in the WordPress option to that value.
    • You can add language links to regular navigation menus in the backend now. These links are adjusted automatically on each site: if there is a dedicated translation, the link will be changed to that page. It will point to the other site’s front page otherwise.
    • Users who are not logged in will not get permalinks for non-public sites anymore. You can work on a new site now safely, test all the links while being logged in, and your visitors will never see that until you set the site to public.
    • Post formats are now supported in the post translation page. We offer only formats that you have used on the other site at least once, because that is the onloy way to know that they are actually supported on that site.
    • Post parents are now synchronized when you save a hierarchical post type like a page.
    • You can link existing terms (tags, categories, whatever) now. We will add support for term creation on that page later.
    • There are hundreds of other, minor improvements, too many to list them all.


    If you own a Pro version, the ZIP archive is already in your download area: English and German. The free version is available on our GitHub repository.

  • Thomas Scholz 11:03 pm on 2014/07/14 Permalink | Reply  

    How to get a post from another site in the network 

    Let’s say we have a site id and a post id. The source doesn’t matter, it could be a database, user input, whatever. Now we want to get a WP_Post object from that site.

    A first idea might look like this:

    switch_to_blog( $site_id );
    $post = get_post( $post_id );

    But this is not necessary, there is already a function in WordPress for that:

    function get_blog_post( $blog_id, $post_id ) {
        switch_to_blog( $blog_id );
        $post = get_post( $post_id );
        return $post;

    Nice, but there is an important, subtle bug in that function: it is using get_post( $post_id ) without a check on the post id. If $post_id is 0, NULL or "", get_post() will use an existing global post object or id. But the current global post is from the source site, not from the target site! The id on site 1 references a completely different post than on site 2.
    WordPress doesn’t care. So we have to do that check:

    $post = NULL;
    if ( ! empty ( $post_id ) )
        $post = get_blog_post( $site_id, $post_id );
  • Thomas Scholz 6:17 am on 2014/04/02 Permalink | Reply
    Tags: , theme   

    Create a custom language switcher 

    We offer a widget and the “quick links” to show links to translations, but many users need a custom solution at other places or in a formatting we just don’t give them (yet).

    There is a handy helper function to get all the links as an array: mlp_get_interlinked_permalinks(). It returns an array with the text (human readable language name), the permalink to the other site’s translation and an entry lang (the language code) – for each single translation.

    You can use that to create your own language switcher. The following function creates a string that might look like this:

    EN | DE | RU

    Add it to your theme’s functions.php.

     * Create a navigation between translations
     * @param  string $between  Separator between items
     * @param  string $before   HTML before items
     * @param  string $after    HTML after items
     * @return string
    function mlp_navigation(
        $between = ' | ',
        $before  = '<p class="mlp-lang-nav">',
        $after   = '</p>'
        $links = (array) mlp_get_interlinked_permalinks();
        if ( empty ( $links ) )
            return '';
        $items = array ();
        foreach ( $links as $link ) {
            if ( isset ( $link['text'] ) ) {
                $text = $link['text'];
            else {
                // take just the main code
                $first = strtok( $link['lang'], '_' );
                $text  = mb_strtoupper( $first );
            $items[] = sprintf(
                '<a href="%1$s" hreflang="%2$s" rel="alternate">%3$s</a>',
                esc_url( $link['permalink'] ),
                esc_attr( $link['lang'] ),
        return $before . join( $between, $items ) . $after;

    Now you can call the function wherever you need it without any arguments:

    echo mlp_navigation();

    Don’t forget the closing semicolon!

    If you want to get a list, you can change the parameters:

    echo mlp_navigation(
        '</li><li>', // between items
        '<ul class="mlp-lang-nav"><li>', // before
        '</li></ul>' // after

    We will add support for custom menus in one of the next versions of Multilingual Press, so you can create your own menus with drag and drop.

    • Piet 4:31 am on 2014/07/02 Permalink | Reply

      Thanks for the tutorial, I will try to implement this. I noticed though that although Posts and Pages are perfectly linked together across languages, Categories are not. If I am looking at a Category Archive the language switcher links to the homepage of the resp. languages. Is there a way to fix this?

      • Thomas Scholz 5:47 am on 2014/07/02 Permalink | Reply

        This part is not completed – yet. We will add taxonomy support in version 2.1.

    • Jorge Díaz 11:39 pm on 2014/09/26 Permalink | Reply

      Hi, I think that the answer to this question is going to be pretty obvios, but when you want to print the code in a page you have to write the code using if that is correct I used it but I don’t know what is happening because is not showing the language switcher.

      • Thomas Scholz 12:00 am on 2014/09/27 Permalink | Reply

        Is there something missing in your comment? I’m not sure what exactly you are asking. :)

        • Jorge Díaz 1:20 am on 2014/09/28 Permalink | Reply

          Hi, thanks for your answer, actually yes the PHP tags are missing, but I finally did it, now I have other question. Multilingual Press works with multisite, I have multisite setup and 2 sites the second is cloned from the first one so I have the same data in both (pages and post) Priority of first language (site for first site) is 10 and second language(site) is 9. But how do I create the relationships between the pages from the first language to the pages in second language, because when I click the check button it creates a page in the same site as draft, so I don’t know what I am missing.

          • Thomas Scholz 1:46 am on 2014/09/28 Permalink | Reply

            Use the button Change Relationship to find the other post or page. It is right below the editor for the translation in MultilingualPress Pro. See our docs for screenshots.

            • Jorge Díaz 2:25 am on 2014/09/28 Permalink

              Hi, thanks for you answer, I am using the free version, I think that custom relationships are not available for the free version, now I managed to create a widget are as you can see here it looks like the same widget from social icon, now my question is, is it possible at least to leave the widget as it is (because if I uncheck the “trasnlate this post option” it disappear) but linking to home page, because now it links to a page that doesn’t exist. Sorry to bother you. :(

            • Thomas Scholz 2:05 pm on 2014/09/28 Permalink

              If it links to the wrong page, it’s a bug. You should uncheck the option Show widget for translated content only. in the widget settings to get it on all pages.

              I have extended our language API in version 2.1, so you can create a much more granular language switcher now. I hope to find the time for a post about that next week.

            • Jorge Díaz 7:21 pm on 2014/09/28 Permalink

              Actually that option is unchecked :(

            • Jorge Díaz 7:29 pm on 2014/09/28 Permalink

              I have unchecked “show current site” and “show widget for translated content only” and now it appears just the flag for the other site in both site, but it’s linking to a page that don’t exist :S for example if the page is the home ( it’s linking to and if I go to it links to so I don’t really understand what is happening.

  • Thomas Scholz 3:31 am on 2014/03/30 Permalink | Reply
    Tags: http,   

    Language negotiation – how our redirect feature works 

    For our users, one of the most important features of Multilingual Press is the HTTP redirect. Each visitor should be sent to the page she understands best.

    This is hard.

    Example: Maryam (مري) visits your site for the first time. She understands Arabic, English and Latin. Arabic is her native language.
    You have three language versions of your content: English, Arabic and Russian. The original content is written in English, the other sites are translations.

    Which page should Maryam see? Arabic or English? It depends on two factors: The quality of your Arabic translation and Maryam’s capability to read English.

    Multilingual Press cannot judge the quality of your translation, but you can give each language a weight, or as we say: a priority. There is a field for that in our language manager.

    Screen shot: Language Manager priorities

    Maryam can do the same in her browser. If her English is not very good, she can add a weight to that preference, and her browser will send that in a q value:

    Accept-Language: ar,en;q=0.7,la;q=0.4

    We read that as:

    Arabic   ar = 1.0 (omitted values equal 1)
    English  en = 0.7
    Latin    la = 0.4

    Multilingual Press will now multiply your priority for each language with Maryam’s preference for that language. The highest number wins. This is called Language negotiation. If there are two highest numbers or the highest number matches the current language, or Maryam selects one language per widget (an URL with a noredirect parameter), she will not be redirected.

    Our algorithm is clever enough to handle subsets: If your only English content is in Belizean English (en-bz), but your visitor’s preference is Canadian English (en-ca), Multilingual Press will strip the second part and find the matching English content.

    What does that mean for you?

    You should always know the quality of your translations. Set the priority for the original language to the highest value, weight the translations lower.

    In our example: If you set the priority for English to 10 and for Arabic to 7, Maryam will not be redirected when she visits the English or the Arabic site. She will be sent to the Arabic site (her first preference) if she visits the Russian site.

    But if you set English to 10 and Arabic to 6, the result of Multilingual Press’ calculation will be:

    Arabic   ar = 1.0 x  6 = 6
    English  en = 0.7 x 10 = 7
    Latin    la = 0.4 (not calculated = 0)
    Russian  ru = 0.4 (not calculated = 0)

    Maryam will get the English site.

    We will also use your priorities to sort the languages in our switcher widget in one of the next releases.

    Conclusion: Set the language priorities carefully. They can decide how good your visitors will understand your message. But always provide a way for your visitors to override automatic content negotiation manually, because not everyone uses a browser which is configured to their needs, or the browser’s user interface is very poor. And sometimes your translation is not as good as you think it is.

    Screenshot: Google Chrome language settings

    Google Chrome language settings

    For developers

    You can override our selection per filter:

     * Change the URL for redirects. You might add support for other types
     * than singular posts and home here.
     * If you return an empty value, the redirect will not happen.
     * The result will be validated with esc_url().
     * @param string $url
     * @param array  $match 'blog_id'  (int)    target blog ID
     *                      'language' (string) target language
     * @param int    $current_blog_id
    $url = apply_filters( 'mlp_redirect_url', $url, $match, $current_blog_id );


Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc