Updates from Thorsten Frommen Toggle Comment Threads | Keyboard Shortcuts

  • Thorsten Frommen 8:32 pm on 2015/09/03 Permalink | Reply  

    MultilingualPress 2.2.2 

    Today, we released version 2.2.2 of MultilingualPress. The release is a patch that fixes a UI bug introduced in version 2.2.1, and allows to use MultilingualPress via symlink. Thank you very much for all your contributions.

    Relevant Changes

    • Bugfix term auto-selecting, again.
    • Use realpath() for plugin file in requirements check to allow for symlinked plugin folder.


    MultilingualPress 2.2.2 is available on our GitHub repository and in the official WordPress plugin directory.

  • Thorsten Frommen 10:01 am on 2015/08/31 Permalink | Reply  

    MultilingualPress 2.2.1 

    Today, we released version 2.2.1 of MultilingualPress. The release is a patch that fixes a UI bug introduced in version 2.2, and two other (possible) problems. Thank you very much for all your contributions.

    Relevant Changes

    • Bugfix auto-selecting the first remote term without relationships.
    • Handle deletion of post relations no matter from what site.
    • Improve validity check for table names (don’t be more restrictive than WP core).


    MultilingualPress 2.2.1 is available on our GitHub repository and in the official WordPress plugin directory.

  • Thorsten Frommen 1:55 pm on 2015/08/27 Permalink | Reply  

    MultilingualPress 2.2.0 “Michael Ende” 

    Today, we (finally) released version 2.2 of MultilingualPress. The release includes a lot of improvements and great new features. For a full list of all changes, please refer to the changelog. Thank you very much for all your contributions.

    Since the story of MultilingualPress 2.2 is somewhat like the Neverending Story, it was pretty obvious to dedicate this version to Michael Ende.

    Relevant Changes

    • MultilingualPress Pro and Free are merged now.
    • If specified, the Custom Name is used in get_name().
    • Site Relations do not exclude non-public sites anymore.
    • When duplicating an existing site, you can now set the search engine visibility of the new site.
    • In the Network admin, the site table now lists the Site Language.
    • The html tag now includes the current blog language. Also, the content and the quicklinks include the according hreflang attribute value.
    • While doing AJAX, do not redirect, no matter if admin-ajax.php or not.
    • Translations now can be saved as long as either a title or content is given. This is how WordPress core behaves.
    • The (new) Advanced Translator now includes post slug and post excerpt fields.
    • Translation meta boxes are only visible to users, who have the required capability to edit the according translation post.
    • When saving a post with unsaved Relationship changes, a confirmation pops up.
    • Make no-redirect links set the session to not redirect.
    • You can now remove all terms of a remote post in the Advanced Translator.
    • Cache various internal queries.
    • We introduced several filters. For a comprehensive documentation, please refer to the according Wiki page.
    • The long deprecated filters mlp_pre_save_postdata and mlp_pre_update_post have been removed.
    • The function get_blog_language() has been deprecated in favor of mlp_get_blog_language().
    • There are hundreds of other, minor improvements, too many to list them all.


    MultilingualPress 2.2 is available on our GitHub repository and in the official WordPress plugin directory.

  • Thorsten Frommen 2:53 pm on 2015/02/11 Permalink | Reply

    How to get translations programmatically 

    The most important API in MultilingualPress for you is probably the Language API. This API has a method get_translations() that you can use to get a prepared set of translations for posts of any post type, terms of any taxonomy, a search term, the front page or a blog page.

    You can access that API with a filter:

    $mlp_language_api = apply_filters( 'mlp_language_api', NULL );

    MultilingualPress will transform that NULL value now into an instance of the class Mlp_Language_Api. In other words: The variable $mlp_language_api is an object now. But you should still test that, just in case the user has deactivated MultilingualPress:

    $mlp_language_api = apply_filters( 'mlp_language_api', NULL );
    if ( ! is_a( $mlp_language_api, 'Mlp_Language_Api_Interface' ) )

    As you can see, you should test against the Interface Mlp_Language_Api_Interface, not against the concrete class. This enables other plugins to replace our implementation with a custom translation handler.

    Today, we are looking just at $mlp_language_api->get_translations( $args );

    Arguments for Mlp_Language_Api::get_translations()

    $args is an array, we can pass some options here to tweak the results.

    Name Type Description
    site_id int Base site. Usually the current site.
    content_id int post or term_taxonomy ID, not term ID.
    type string Either post, term, post_type_archive, search or front_page.
    strict bool When TRUE (default) only matching exact translations will be included.
    search_term string If you want to translate a search.
    post_type string For post type archives.
    include_base bool Include the base site in returned list.

    All parameters are optional. MultilingualPress will try to find proper values for them. We recommend to set the content_id for terms and posts though, because that is not always available, at least not in a reliable way.

    Now let’s see how our code could look like:

    $mlp_language_api = apply_filters( 'mlp_language_api', NULL );
    if ( ! is_a( $mlp_language_api, 'Mlp_Language_Api_Interface' ) )
    $args = array (
    	'strict'               => TRUE,
    	'include_base'         => TRUE
    /** @var Mlp_Language_Api_Interface $mlp_language_api */
    $translations = $mlp_language_api->get_translations( $args );
    if ( empty ( $translations ) )

    Note that $mlp_language_api->get_translations( $args ) will return an empty array if there are no translations even when we set include_base to TRUE.

    Now, let’s say the translations are not empty. We get an array of objects, each an instance of Mlp_Translation which implements the Mlp_Translation_Interface. That sounds complicated, but it just means that we have a set of methods on each object to get information about the translation.

    Methods for Mlp_Translation

    Method Return type Description
    get_source_site_id() int The site ID the translation is based on.
    get_target_site_id() int The ID of the site where the translation can be found.
    get_page_type() string Either post, term, post_type_archive, search or front_page.
    get_icon_url() Mlp_Url_Interface An object, an instance of a class implementing the Mlp_Url_Interface. It has a magic method __toString(), so we can cast it to a string and get an escaped URL.
    get_target_title() string The title of the translation, for example the post title or the term name.
    get_target_content_id() int The term_taxonomy_id or the post id. This is empty for other translation types like post type archives or search.
    get_remote_url() string The URL for the translation.
    get_language() Mlp_Language_Interface An object, an instance of a class implementing the Mlp_Language_Interface.

    The Mlp_Translation::get_language() object deserves an explanation. It has three public methods.

    Methods for Mlp_Language

    Method Return type Description
    get_priority() int A number between 0 and 10. See the post about Language negotiation for an explanation.
    is_rtl() bool Whether the translation is in a right-to-left language (like Hebrew) or not.
    get_name( $name ) string Different representations of the language. Default is the language in its native writing, eg. Deutsch for German. We strongly recommend to use that, because that’s most easily to recognize for your readers.
    Other allowed parameters are english to get the English name, http to get the HTTP value (for example de-AT) or custom to get the custom name you have set in the site properties.
    You can also use language_short to get just the first part of a language code with subsets, eg. just de.

    Example: Add translation links to the post content

    Let’s see what we can do with all this code. The following example adds very simple translation links to the post content. It uses the first part of the language code and sets it to uppercase. The images are used too, if they are available.

    add_filter( 'the_content', function( $content ) {
        if ( ! is_singular() )
            return $content;
        $mlp_language_api = apply_filters( 'mlp_language_api', NULL );
        if ( ! is_a( $mlp_language_api, 'Mlp_Language_Api_Interface' ) )
            return $content;
        $args = array (
            'strict'               => TRUE,
            'include_base'         => TRUE
        /** @var Mlp_Language_Api_Interface $mlp_language_api */
        $translations = $mlp_language_api->get_translations( $args );
        if ( empty ( $translations ) )
            return $content;
        $links = array();
        /** @type Mlp_Translation_Interface $translation */
        foreach ( $translations as $translation ) {
            $current = $img = '';
            if ( $translation->get_target_site_id() === get_current_blog_id() )
                $current = ' class="current"';
            $img_url = $translation->get_icon_url();
            if ( '' !== (string) $img_url )
                $img = "<img src='$img_url' alt=''> ";
            $text = $translation->get_language()->get_name( 'language_short' );
            $text = mb_strtoupper( $text, 'UTF-8' );
            $links[] = sprintf(
                '<a href="%1$s" title="%2$s" %3$s>%4$s</a>',
                esc_attr( $translation->get_target_title() ),
                $img . $text
        $links = '<p class="translations">'
            . join( ' <span class="separator">|</span> ', $links )
            . '</p>';
        return $content . $links;

    The result should look like this: Screenshot

    Theme integration

    You can use such a function in other places too, of course. In a theme you should add a custom action wherever you need it and assign a callback handler to that action. This way, your theme will not break when the user deactivates MultilingualPress.

    So in a template file add this line:

    do_action( 'translation_box' );

    And in your functions.php create a callback function and register it for that action:

    add_action( 'translation_box', 'show_mlp_translation' );
    function show_mlp_translation() {
        // find and print translation links

    Any questions or suggestions? Or do you have used this tutorial successfully? Please let me know.

  • Thorsten Frommen 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.

  • Thorsten Frommen 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 wpkrauts.com.

    The results are:

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

  • Thorsten Frommen 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!

  • Thorsten Frommen 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    http://make.multilingualpress.pro/?p=167
     * @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. :)

    • roberto 8:51 pm on 2015/02/10 Permalink | Reply

      Hi, i’ve tried many things but i’m getting confused. Please could you help me???. what I’m trying to do is to move both language buttons (with their icons) away from the “Primary Menu”, i would like to put it in the header or somewhere else.

      Here is the URL of my web project: http://vidaurrereisen.com/plasticwebs/

      Sorry if my english is a little poor, please try to explain it as simple as you can.


  • Thorsten Frommen 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.
  • Thorsten Frommen 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.
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