MultilingualPress 文档

What’s new in MultilingualPress 3?

What’s new in MultilingualPress 3?
MultilingualPress 3 is here! It is the brand new version of our multilingualism plugin. Well, let’s say it is a refactored version of the previous one. It improves the features of version 2 considerably.

Table of Contents

Why should we buy Version 3 when Version 2 is still available for free?PHP7, new power to the codeRefactoringBetter UI and Gutenberg compatibilityEnhanced support: version 3 wants to speak to the worldI love V2What else?
1. Why should we buy Version 3 when Version 2 is still available for free?
This is a valid question that we would like to illustrate with an example of a car purchase.
We can choose an excellent car produced a few years ago. It is reliable and carries out its task of transporting in a safe and comfortable way.
But it is not the new model.
On the contrary, the new model offers the latest generation features. It contains new and more resistant materials. This model has advanced safety and protection abilities, and features that allow a more comfortable ride. With the advanced technologies you have the latest navigation and sound system, and a better fuel efficiency with more engine power. Last but not least, utilising the latest connectivity standards, you have the possibility to connect all your current and future devices such as your smartphone and laptop with your car. In addition, you get the latest updates, whereas the older car only gets required updates (for security or forced by law). This new model is MultilingualPress 3!
So, ask yourself! What do you want to achieve in the long term?
2. PHP7, new power to the code
MultilingualPress 3 works on PHP7. It takes advantage of all benefits according to a state-of-the-art implementation. It leverages the power of PHP7 at its best.
Thus, it shows a faster response and has a faster site execution speed compared to web calls.
Even the consumption is reduced. As known, this version of PHP requires fewer resources. And as a result, you save memory to run processes for the happiness of your website’s performance.
If you have no idea and wonder what PHP stands for, well, better check this little summary about What is PHP and why you should migrate to modern PHP.
3. Refactoring
We rewrote MultilingualPress with a specific goal in mind: more efficiency. This includes the code’s maintainability as well as to fully exploit the advantages of PHP7.
That’s why we optimised the features of version 2, streamlined some of them and made everything more intuitive for the user. This means, we have not only focused on increasing the power of the product, but also on the simple usage of it.
Having all of you – our users – in mind, we need and want a performing, powerful plugin and happy users. But we didn’t stop there. We want MultilingualPress to be simple and we want it to be enjoyable. As a result, we improved the tools by simplifying the use of MultilingualPress.
Let’s give you a better picture of what we have done. Compared to the previous version, MultilingualPress 3 is set up by default with a complete set of languages. Hence, it automatically meets what you as our user ask for without requiring further settings. But don’t worry, if you want more you will get more. The Language Manager allows you to set and customise your own language.
4. Better UI and Gutenberg compatibility
Furthermore, version 3 is ready for Gutenberg. Along with a bunch of other new features, Gutenberg brings a new concept of editing content, which will be extended to the whole WordPress system in the coming years. Curious? Have a look at Gutenberg Editor changes User Interface in WordPress.
Are you ready for the imminent change? MultilingualPress 3 is!
For example, unlike version 2 the boxes under the posts relating the content translations no longer contain the translated content of the article. Instead, they only keep the relationship functionalities and the main attributes. Still, the boxes allow you to define translations of the main parameters (title, excerpt, etc.) and manage the functional characteristics (relationship features, related taxonomies), but the body of the article is kept in the original site.
5. Enhanced support: version 3 wants to speak to the world
Unity is strength and MultilingualPress 3 knows it very well.
MultilingualPress must be able to communicate with other major plugins in the construction of a professional site. Especially, the interface with the most famous e-commerce system WooCommerce is essential. With this thought in mind, we are proud to introduce the translation support for custom post types, slugs, taxonomies, Advanced Custom Fields.
6. I love V2
Still in love with MultilingualPress version 2? Or just afraid of your current projects?
The good news is that you can relax and feel comfortable, as the support for version 2 will continue to be available to help you in any eventuality.
But please note: currently switching from version 2 to version 3 is not trivial. For this reason we built a Migration Tool (more info available at Multilingualpress 2 to 3 Migration Tool), which currently is in alpha version, so actually migration could be not easy to achieve. Hence, if you start a new project, set a plan and consider, that in long term, version 3 is the best choice.
7. What else?
Of course … this new version is a beginning.
When we started working on the new version, we clearly focused on the user experience, performance and scalability. And voilà, we improved the tools, simplified the use and increased the efficiency. All of this packed in the new version 3 of MultilingualPress.
But the reengineering process is just the first step. We constantly work hard to offer new features. So, be ready for new surprises and stay connected!

MultilingualPress and WordPress 5.0 (Gutenberg)

MultilingualPress and WordPress 5.0 (Gutenberg)
We are almost there: on 27th of November WordPress will change its editor and it will not be a small change. In fact the new WordPress 5.0 will include Gutenberg in the core. If you are wondering what Gutenberg is, the answer is: a completely new way of writing and processing content in WordPress.

Table of Contents

The Gutenberg revolutionGutenberg ready!Is MultilingualPress Gutenberg ready?Is MultilingualPress version 2 Gutenberg ready?Is MultilingualPress version 3 Gutenberg ready?How to upgrade from version 2 to version 3?Get in touch!
1. The Gutenberg revolution
The Gutenberg editor is based on the concept of blocks: an elementary content unit through which it is possible to build your contents. Therefore, everything can be rethought as a composition of blocks of different types. Intriguing? If you want to know more, have a look here: Say Hello to the New Editor
If you cannot wait to start playing with it, you can also install Gutenberg separately: in fact currently it is available as a plugin, while in the new WordPress 5.0 it will be integrated in the core. Here is the link if you want to immediately test it: Gutenberg Plugin
Why do we talk about a revolution? Because Gutenberg has potential to go beyond WordPress. Gutenberg implies a new way of thinking and building content. An innovative change that could spread beyond the boundaries of WordPress if it shows to be a more efficient approach in editing content than the traditional one.
In this case we would be facing a significant change involving the technologies of the digital edition, and therefore the web in general. Are you ready?
2. Gutenberg ready!
It is also important to understand that all the software developed for the WordPress ecosystem, and therefore plugins and themes, will have to manage this change.
So, in some cases, to be Gutenberg compatible will require proper software updates for themes and/or plugins.
But what if my software is not Gutenberg ready, or if I just prefer to continue using the classic editor? Don’t worry: this will still be possible.
Let’s see it from the MultilingualPress point of view.
3. Is MultilingualPress Gutenberg ready?
Do you remember that MultilingualPress is available in two flavors? We have MultilingualPress version 2 and the new refactored and enhanced MultilingualPress version 3. Hence the question requires to be formulated in a more appropriate manner.
4. Is MultilingualPress version 2 Gutenberg ready?
Version 2 was not originally designed to work with Gutenberg. We know, it’s a pity.
But we set a proper workaround to allow you to continue your work without problems.
The issue is that MultilingualPress, to work correctly, needs the classic editor. So, to overcome the problem, we set the __block_editor_compatible_meta_box parameter to false, implementing the solution described here: Metabox in Gutenberg
In this way, installing MultilingualPress version 2, your WordPress will automatically use the classic editor.
At the time of writing this article, WordPress 5.0 has not been released yet. So, to test the workaround described in the above paragraph, we used the WordPress 5.0 beta, which is currently available. Unfortunately, we saw that for the beta version the workaround does not work. We expect that in the official 5.0 version it will work properly. But in the meantime we followed a second way to solve the problem: install the classic editor plugin available at the following link: Classic Editor
The plugin must be Network installed and Network activated. This will disable Gutenberg for all your network sites allowing MultilingualPress version 2 to run as usual.
5. Is MultilingualPress version 3 Gutenberg ready?
Yes! If you are a user of the new version you do not have to think about anything, because Gutenberg will work in complete harmony with MultilingualPress version 3. You just have to worry about your content, learn how to make the most of the innovative editor, and focus only your business without thinking about anything else. Cool!
Now perhaps you might be a bit confused, especially if you are still using version 2, and especially if you are eager to enter the digital editing future.
As it is true that it is still possible to work with MultilingualPress 2, as we saw in the previous section, in the same way it is equally true that the possibility of evolving your platform and your skills remains limited and bond to a type of technology that is about to be surpassed.
All this can be remedied, as version 3 is Gutenberg compatible. But it would not be enough to simply say this. Version 3 is much more: it is the natural evolution of MultilingualPress version 2, able to incorporate continuous technological advances, satisfy users’ requests and expand its range of action, including new features and optimizing those already present. Do you want to know more? Here are some links:

Getting started with MultilingualPress 3
MultilingualPress 3: common questions and answers

The partnership with WooCommerce is one of the examples of the current process of strengthening our product, which aims to become the best multilingual solution on the market at enterprise level, with a special focus for WooCommerce Multisite Shops. We are proud to also share with you the WooCommerce marketplace link about MultilingualPress 3: WooCommerce MultilingualPress
Interested? Jump to our shop and have a look to the available MutilingualPress 3 licenses!
6. How to upgrade from version 2 to version 3?
Well, one easy way to get this is use our tool that executes the update automatically. Refer to this doc for further details: MultilingualPress 2 to 3 Migration Tool.
As an alternative, instead, we can provide you with a short tutorial to help you to upgrade MultilingualPress manually. Here is the link: How to manually migrate from MultilingualPress version 2 to version 3
But at the same time we wonder if the manual solution can be sufficient, and if indeed an automated solution is something necessary and what urgency our users have in this regard.
7. Get in touch!
We need your opinion, that’s the truth! Why not contact us, using the link below, and inform us about the version 2 to version 3 migration needs you have, and even if you have ideas or requests for new features in MultilingualPress 3. Your words are the best guide for us, we always consider your directions as very valuable. So, don’t wait any longer, get in touch with us now!

MultilingualPress site duplication issue: a solution

MultilingualPress site duplication issue: a solution
One of the powerful features available in MultilingualPress is the so called “Based on” option. Through this option you can create a  new site as a duplication of an already existing other sub site.
Hence this feature let you to create a new sub site as a copy of another, copying also the source site content , the configurations and the translation connections.
But in a particular case one or more third party plugins could interrupt the process. Let’s see what the problem is and how MultilingualPress solves it.

Table of Contents

Duplicate your site in one clickDuplication issue due to third party plugins redirectionThe solution: uncheck plugin activation option
1. Duplicate your site in one click
Suppose you have a shop in your own language, but you wish also to create a new one in another language.
The two shops should be quite similar, only languages will be different.
In that case would be much faster for you if the new site is created as a duplication of the former one. No manual settings, just get what you need in one click.
That’s what you can achieve with MultilingualPress!
What you need to do is to select the “Based on” option on the new site creation page. For further details on this feature please have a look to our Getting Started with MultilingualPress guide.
2. Duplication issue due to third party plugins redirection
Unfortunately if the source site has installed some third party plugins whose activation includes also redirection, this  could interrupt the duplication process .
What happen is this: when you create a new site as a copy of another, depending on the settings, MultilingualPress will activate all the plugins of the source site also in the new one.
But if any of these plugins perform a redirection within the activation, this would lead to a process interruption. The redirection will stop the duplication process.
3. The solution: uncheck plugin activation option
How to solve this? Luckily MultilingualPress has another option that prevent this issue to happen right before to start the creation process.
You just need to uncheck the “Activate all plugins that are active on the source site“ as reported in the picture here below.
Create a new site preventing redirects on activation
This way MultilingualPress duplicates the source site, but it also does not activate all the plugin in the remote site during the process.
So no redirection happens, and the duplication completes properly.
Of course, after the creation, all the needed plugin need to be manually activated.

Connect and Translate WooCommerce Attributes

Connect and Translate WooCommerce Attributes
MultilingualPress is built to perfectly integrate with the WooCommerce environment. And hence it can also properly connect and translate the WooCommerce Attributes.
Let’s check how this works in this brief tutorial.

Table of Contents

Create an attribute, an exampleSame attribute on different sub site: set the connectionMultilingualPress attribute connection established
1. Create an attribute, an example
Before connecting WooCommerce attributes in MultilingualPress, we first need to create one.
So, let’s create an attribute in our WordPress Multisite Network Shops: for example we create a color attribute in the English sub site.
To achieve that we go to Products->Attributes . From here we set the attribute name as color and the related slug as color.
After that we can then configure some Terms using the Configure Terms link shown in the picture below.
Create WooCommerce Attributes and Terms
Hence we have some Terms (Blue, Gary, Green, Red, Yellow) for the color attribute.
2. Same attribute on different sub site: set the connection
Suppose now to set a similar attribute on another sub site, let’s say a Spanish version of the English one described in the previous section.
In that case we can similarly proceed in creating an attribute, but this time the Terms will be properly translated in Spanish language.
Let’s focus on the “Blue” Term. This in Spanish language is “Azul”. We proceed and create this Term.
At this point we need to understand how to connect the Attribute between the two sites.
We want that the color attribute in the English site is connected via MultlingualPress to the color attribute in the Spanish site. To achieve that they have to share exactly the same slug: color in this case.
As we can see the slug in the English site is color .
WooCommerce Attribute slug in English language site set as “color”
And similarly in the Spanish site the slug is still color.
WooCommerce Attribute slug in Spanish language site set as “color”
In the following picture we see again that the color attribute in the Spanish version site with the slug set as color but we also show that the Azul Term is configured.
Create WooCommerce Attributes and Terms in Spanish language site
3. MultilingualPress attribute connection established
Now that the color WooCommerce Attributes share the same slug, it is easily possible to set the language relations of the Terms of through the translation metaboxes.
In fact, as reported in the picture below, when you edit one of the terms and search for related term in the other language site,  MultilingualPress will try to find the term within the attribute with the same slug.
In that case and will not look for term in attribute called Size for example. Instead it will check for the slug color .
The Translation Metabox is now able to properly find and connect the related Terms
Filling the form with the “Az” values, will let MultilingualPress search within the English color Attribute, and retrieve the Azul Term.
If you want to know more about how to properly set your MultilingualPress environment have a look at our Getting Started with MultilingualPress tutorial.

How to translate custom post types and taxonomies

How to translate custom post types and taxonomies
In this document we explain you how to translate custom post types and taxonomies in MultilingualPress. To demonstrate it, we’ll create a WordPress Multisite installation with two connected sites.
We are going to use the Custom Post Type UI plugin to create a custom post type and a taxonomy. Just keep in mind that the process is the same for any other plugin that creates custom post types or if you register them manually using register_post_type and register_taxonomy.

Table of Contents

Setup a WordPress Multisite with 2 connected sitesInstall and setup Custom Post Type UI pluginCreate a new custom post type and a taxonomyEnable Custom Post Types and Taxonomies in MultilingualPress SettingsEnter Post Type slug value on each siteCreate some custom posts and taxonomy termsConnect Taxonomy Terms with MultilingualPressConnect Custom Post Types with MultilingualPressCreate a menu on each site to navigate through languagesSetup Permalinks structureVisit a Custom Post page and switch language
1. Setup a WordPress Multisite with 2 connected sites
To setup a WordPress Multisite you can follow our tutorial How to install and set up a WordPress Multisite. Our guide Getting started with MultilingualPress 3 explains how to create the sites and connect them with MultilingualPress. We created 2 sites, one for English and one for German and connected them as you can see in the screenshot below.
Two sites in a WordPress multisite for English and German connected with MultilingualPress
2. Install and setup Custom Post Type UI plugin
In the next step we install and activate the Custom Post Type UI plugin. Regarding plugin activation we need to decide if it should be network activated or activated in each site individually. The decision will depend on the plugins ability to support Multisite or not. In this case Custom Post Type UI does not have Multisite support (at least in the free version) so we activate it on each site. To do so, go to the Dashboard of each site and activate the plugin on the Plugins page.
Install the plugin Custom Post type UI which we want to use for creating our custom post type and custom taxonomy.
3. Create a new custom post type and a taxonomy
We first create the custom post type and taxonomy on site 1 and afterwards we will copy them to site 2. We will call our custom post type Recipes and the taxonomy Ingredients.
Create a custom post type Recipes
Create a custom taxonomy Ingredients.
To copy the custom post type and taxonomy we use the Export/Import functionality in the Tools page of Custom Post Type UI.
Copy the content of the Export Post Type settings field from site 1…
… And paste into the field Import Post Types of  site 2.
In the next step we do the same export/import for taxonomies via Taxonomies tab.
4. Enable Custom Post Types and Taxonomies in MultilingualPress Settings
Now that we have custom post type and taxonomy created in both sites, we can configure MultilingualPress in order to be able to translate them. To do so go to My Sites → Network Admin →  Settings →  MultilingualPress and enable the custom post type and the taxonomy in the corresponding tabs, in our case Recipes and Ingredients.
Enable Recipes in Translatable Post Types tab.
Enable Ingredients in Translatable Taxonomies tab.
5. Enter Post Type slug value on each site
Before to proceed, please note that MultilingualPress does not translate custom post type slugs, that should be done at registration time via rewrite parameter from register_post_type (e.g. ‘rewrite’ => [‘slug’ => esc_html__(‘my-cpt’, ‘text-domain-here’)] ) and with language files (.po/.mo, .pot). When you have the slugs properly translated then you can tell MultilingualPress which slug to use on each site.
In case you need  to also set the archive page for your custom post type, and then be able to translate it, then you should also have the has_archive parameter set to true when registering the post type; and any custom slug for archive pages should not be specified.
Besides, if the language set in your profile and the one selected in a particular subsite are not the same, the solution above described will be not enough.
In this case, if your profile language and the subsite language are different, you have also to add the following snippet to your code, for example in the functions.php file:
/**
* Updates the rewrite => slug argument when registering a post type.
*
* Will use the option from the “Post Type Slugs” tab the
* Network Settings of a website, in case it’s not empty.
*
* @see register_post_type()
*
* @param array $args An array of arguments that will be passed to register_post_type().
* @param string $postType The name/slug of the post type.
*
* @return array Updated arguments.
*/
add_filter( ‘register_post_type_args’, function( $args, $postType ) {

if ( ( isset( $args[‘_builtin’ ] ) && $args[‘_builtin’] )
|| ( isset( $args[‘public’] ) && ! $args[‘public’] )
) {
return $args;
}

$slugSettings = get_network_option(
0,
InpsydeMultilingualPressCoreAdminPostTypeSlugsSettingsRepository::OPTION,
[]
);

$siteId = get_current_blog_id();

if ( empty( $slugSettings[ $siteId ][ $postType ] ) ) {
return $args;
}

$args = array_merge( $args, [
‘rewrite’ => [
‘slug’ => $slugSettings[ $siteId ][ $postType ]
],
] );

return $args;
}, 10, 2 );
With that filter, doesn’t matter what language is selected in your language settings: the right Custom Post Type slug will be used.
Now we can go on to set our Post Type Slug.
To do so go to My Sites →  Network Admin →  Sites and edit each site. In Post Type Slugs fill in the value of the custom post type slug for our custom post type Recipes. In this case both sites use the same slug, but this feature allows you to setup a different translated slug on each site.
But consider also that when you register a custom post type and you don’t want to translate that post type’s slug, even in that case you should fill in the value in the Post Type Slugs tab in order to let the language menu work correctly.
Enter a slug for your custom post type on each site
6. Create some custom posts and taxonomy terms
We can start creating ingredients (taxonomy terms) and recipes (custom posts) in site 1 and then we use the MultilingualPress translation metabox to create the translations for site 2 from there. It is also possible to connect existing content in site 2 from the same translation metabox.
Create some Ingredients in site 1.
Create Recipes and assign Ingredients in site 1.
7. Connect Taxonomy Terms with MultilingualPress
After creating the taxonomy terms on the different language sites we need to connect them.  Go to the dashboard of site 1, select Recipes → Ingredients and edit one term. In the translation metabox you can choose Create a new term or Select an existing term. In this case we choose Create a new term. We can fill the fields in Term Data tab manually otherwise the values will be generated automatically for you.
Connect taxonomy terms in the MultilingualPress translation meta box
8. Connect Custom Post Types with MultilingualPress
Connecting the custom posts is similar to connecting taxonomy terms. Go to the dasboard of site 1, select Recipes in the menu and edit one.  In the translation metabox you can choose Create a new Recipe or Select an existing Recipe. We choose Create a new Recipe. You can setup the values manually and use advanced features like Copy featured image in Advanced tab.
Connect custom post types with MultilingualPress
Now if you go to site 2 you will see a new Recipe created. Edit it and select a translated taxonomy in the Ingredients metabox:
Select an Ingredients taxonomy term in the Ingredients taxonomy metabox
9. Create a menu on each site to navigate through languages
Now that we have some recipes and ingredients connected between both sites we create a menu on each site to allow the user to switch between languages. In the menu we will add MultilingualPress language items.
Create a language menu on each site to allow users to switch languages and add language items to it
10. Setup Permalinks structure
Before we check that switching languages works, we need to ensure that our permalinks structure is configured correctly. Depending on if it is a new Multisite installation it could be that our permalink includes a /blog/ slug added by WordPress. The best approach for now is to simply get rid of this part in the permalink:
Remove /blog/ from URLs
A quick tip for removing the /blog/ slug from the permalink is to select Plain and save. Then select Custom Structure and remove /blog/ slug there. You need to remove the /blog/ slug in both sites. Don’t forget to 301 redirect the old slugs to the new.
11. Visit a Custom Post page and switch language
Now that everything is setup correctly, its time to check that we can switch languages from a custom post type page. Go to site 1 and view one of the Recipes you’ve set up. Then switch languages in the menu. You should be redirected to the translated version. Do the same also for the taxonomy terms.
View a Recipes post …

… and switch the language
View an ingredient…

… and switch the language
That’s all you need to do regarding setting up custom post type and taxonomy translations in MultilingualPress. If you have doubts or need further assistance, just let us know.

The WordPress Multisite Overview with Examples

The WordPress Multisite Overview with Examples
You wonder what the WordPress multisite is about? With our WordPress multisite overview, we want to give a first impression about the WordPress multisite feature.
You can find even more details in the category WordPress Multisite 1×1 in our MultilingualPress documentations. As a beginning, we recommend our post Install and Set up WordPress Multisite.

Table of Contents

What’s the WordPress Multisite? – A Network of WebsitesSingle Site and Multisite: The DifferencesAdmin ScreensFilesDatabaseOverview of Multisite FeaturesWordPress Multisite Overview – Use Cases and Examples
1. What’s the WordPress Multisite? – A Network of Websites
The multisite is a WordPress feature with which users can create a network of websites in a single WordPress installation. This way, users can administrate websites professionally.
Multisite is available since WordPress 3.0 and was created out of  WPMU (WordPress MultiUser).
The great thing about a WordPress multisite is the fact that it looks very similar to a standard installation. The multisite installation has the same folder structure, the same basic files and the same code base. That’s what makes the installation of a multisite network nearly as easy as the installation of a standard WordPress site (WordPress Single Site). And updates of a multisite are a piece of cake, too.
2. Single Site and Multisite: The Differences
However, there are some differences between a WordPress Single Site and a Multisite . There are differences between the admin screens and their usage, between the files in your WordPress installation and between the database files.
2.1. Admin Screens
As soon as you activated the multisite, you see some more screens in the admin area to administrate the network.
WordPress Multisite Overview – Multisite Admin Dashboard
Only Super Admins see this admin area. They can install themes and plugins and create and administrate sites. Besides to the role Super Admin, you can assign the role “standard” admin for admins of websites within the network. Owners of this role cannot install themes and plugins but can only activate those which were installed within the network.
2.2. Files
The only differences between files of the standard WordPress installation and the multisite installation are those of the wp-config.php file, the .htaccess file and the wp-uploads folder. As soon as you installed the multisite network, there are a few more lines of code in the wp-config.php file, which tell WordPress how to run. The wp-uploads folder contains, in a WordPress multisite installation, sub folders for each single website. Files which have been uploaded to the websites are stored in the corresponding folder – with the same structure you have in the wp-uploads folder of the standard installation.
2.3. Database
The database of a standard WordPress installation contains of twelve database tables in which the page content and the settings are stored. In a multisite network, ten of these tables are duplicated for each website. This means: The more websites in the network, the more database tables. They separate the content of each website within the multisite network.
3. Overview of Multisite Features

You can create a network with a couple of blogs and websites out of only one single WordPress installation.
Moreover you can have a network of subdomains like http://multisite.domain.com or directories like http://www.domain.com/multisite/ or have top level domains.
Open a WordPress multisite network for other users to create accounts and blogs.
All themes and plugins are stored only once – independent from the number of websites on which you use them. This means that you need less server space than with a WordPress installation of each website.
There is the role of the Super Admin who is admin of the whole network and the website administrator role who administrates only one website within the network. As Super Admin, you can install themes and plugins and all admins of the websites within your network can activate them. Website administrators within the network don’t have the permission to install themes or plugins.
As Super Admin, you can make changes of the themes for all websites. Website administrators cannot change anything concerning the theme.
Create websites and shops for a couple of languages, regions, currencies and so on. The best plugin to use for multilingualism in WordPress is the plugin MultilingualPress, which is used with a WordPress multisite.

Well, all this means that different websites may have the same design – or not. It’s the Super Admin’s decision what kind of themes and plugins are available for the website administrators to design their websites. With the help of MultilingualPress you can build a multilingual network of websites which are more or less different: the same or a different design, the same or different features, completely different content or just a few different words, different products or just another currency.
4. WordPress Multisite Overview – Use Cases and Examples
A multisite network has many use cases. For example you can use it to create a network of websites or blogs for several people or a whole company. Moreover, agencies or developers can use the network to keep the customer websites they install and administrate at one place.
An example for the usage of WordPress multisite: A building materials company has a couple of stores with different corporate identities in an umbrella brand.  There, the company’s head quarter could make the administration of the whole WordPress installation, while each store can work on its own website within the network. Of course, each website can have the same elements to comply with the corporate design. The head quarters would do the WordPress updates and install plugins both for all websites and individual store requests. You can transfer similar approaches to universities with international focus: With the WordPress multisite, they can have multilingual websites in one installation. The use cases for the WordPress multisite feature are quite diverse.
Here some examples:

Inpsyde.com  – multilingual website
WordPress Multisite Overview – Example inpsyde.com
Multilingual online shop of Vectorcam
WordPress Multisite Overview – Example Vectorcam
Inpsyde product pages backwpup.com, backwpup.de, multilingualpress.de, and multilingualpress.org – here we have different products and different languages in one installation
WordPress Multisite Overview – Example Inpsyde Product Pages

However, there are some use cases in which the multisite isn’t the best solution. For example, if you’re not planning to have more than one website. Or in case you create several websites but your customers have different hosters.
Our WordPress multisite overview was convincing? It’s exactly what you need? Then just start with the installation. Here you can find the tutorial how to install and set up a WordPress multisite.

How to install and set up a WordPress Multisite

How to install and set up a WordPress Multisite
In this tutorial we explain how you can install and set up a WordPress multisite to build a network of websites. We assume that you already installed a WordPress Single Site. Moreover we assume you have FTP access to the directory of your WordPress installation, as you need to change some files.

Table of Contents

Install WordPress Multisite – the RequirementsAllow Multisite in wp-config.phpInstall the WordPress NetworkAdd some code to wp-config.php and .htaccessMenu network administration and the network settingsAdd a new website to the networkInstall Plugins and Themes in the WordPress multisite
1. Install WordPress Multisite – the Requirements
Before you start to install the WordPress multisite, please make sure that:

You already have a WordPress installation
Pretty Permalinks are activated. This means your URLs should not look like this  http://example.com/?p=2345, but rather like this http://example.com/my-page
All plugins are deactivated
Important: you have a backup of your WordPress installation
You have FTP access to your WordPress installation

2. Allow Multisite in wp-config.php
The first step is to activate the Multisite feature in the file wp-config.php.

Set up a FTP connection to your website.
Open the file wp-config.php, which is is located in the main directory of your WordPress, and add the line
define(‘WP_ALLOW_MULTISITE’, true);
above the line:
/* That’s all, stop editing! Happy blogging. */
Define WP_ALLOW_MULTISITE in wp-config.php to enable the Multisite feature.
Save the file wp-config.php.

Now you enabled the Multisite feature in your WordPress installation. But you haven’t finished yet. The next step is to install the network.
3. Install the WordPress Network

Refresh the page in your browser and log in to your website.
In the left sidebar under Tools you will find the menu tab Network Setup, where you can configure your WordPress Multisite.
Install a WordPress Multisite – Settings page “Create a Network of WordPress Sites”
Decide whether you want to use subdomains for the sites in your network (e.g. site1.example.com) or whether you want to have them installed in subfolders (e.g. example.com/site1).  This setting affects all the sites in your network, you cannot change that later on.  Do you need a site to be mapped to a top level domain (e.g. mydomain.com)? This is possible with domain mapping.

Enter a name for your network in the field Network Title in the section Network Details.

Enter the site admin’s e-mail address.

Click the Install button.

4. Add some code to wp-config.php and .htaccess
WordPress will now provide you with two snippets of code, which you need to add to the wp-config.php and .htaccess files. Both files are located in the root directory of your WordPress.

Set up a FTP connection to your website.
Add the first code snippet to your wp-config.php directly above the line
/* That’s all, stop editing! Happy blogging. */
The snippet looks like this, but adapted to your own site:
define(‘MULTISITE’, true);
define(‘SUBDOMAIN_INSTALL’, true);
define(‘DOMAIN_CURRENT_SITE’, ‘My Website’);
define(‘PATH_CURRENT_SITE’, ‘/’);
define(‘SITE_ID_CURRENT_SITE’, 1);
define(‘BLOG_ID_CURRENT_SITE’, 1);

Add the second code snippet to the .htaccess file and replace other WordPress rules.
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ – [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*.php)$ $2 [L]
RewriteRule . index.php [L]

Save both files.

5. Menu network administration and the network settings
When you changed the wp-config.php and the .htaccess, log into your WordPress admin area again. In the upper admin bar, you now see the new menu Network Admin. It’s displayed always, so you can always enter the admin area of the network, no matter on which site of your network you are. We take a look at the sub menues later on.
Below the network administration, all sites of the network are listed to which you were added. By clicking on the names, you enter the backends of these sites.
The menu Network Admin of WordPress multisite
And here’s the explanation of the menu tabs in the network administration:

Dashboard: Here you can find the widget to add new users and new sites to your network.
Sites: On this tab, you can see all sites of your network – similar to the posts and pages. By moving the cursor over the websites, you see for example links to edit, display the dashboard, view, delete, archive or deactivate the sites. Note that you have fewer functions for the main page of your network, as this one always needs to exist and you cannot delete it.
Users: Here you can administer the users of your network. In contrast to a single site installation, you can assign the super admin user role. The super admin has access to all sites and can make changes within the whole network. If you want a user to have access to the sites of your network, you need to add the user to each site via the user administration of the sites.
Themes: The theme administration. Here you can install and uninstall themes and activate or deactivate them for the whole network.
Plugins: Here you can find all installed plugins. You can add new plugins or delete them, you can activate or deactivate them for the whole network.
Settings: On this tab you can find and edit the basic settings for your site, for example: the network name and the admin E-Mail address, you can allow user registrations, add new users to the site admins, you can make the themes and plugins menu available for site admins or set the standard language of your sites.

6. Add a new website to the network
A WordPress multisite with only one website doesn’t really make sense. To a WordPress multisite, you can add as many websites as you want – always and any time, so, it needn’t be at the beginning. To enhance your website with a new site, take the following steps:

Go to My Sites → Network Admin → Sites and click Add new.
Add a new website to a multisite
Enter the desired website address. In this case, we decided for a network with sub directories. The domain is already given, we just add the sub diretory.
Settings for the new website in the multisite network
Define a title of the website. This one is displayed at several positions in your network, for example in the backend as website name in My Sites, but maybe also in the frontend or in meta data like the page title.
Choose a language for the new website.
Choose the admin e-mail address which must be different than the one for the whole network. If there is no user with this e-mail yet, a new user with admin role for this site will be created.
Click the button Add Site. Your new site is to be created and will be displayed in My Sites  → Network Admin → Sites. However, in order to let others than the current admin administer this new site, you need to add them as user with admin role to this site.

7. Install Plugins and Themes in the WordPress multisite
Install or uninstall plugins or themes in a WordPress multisite network is something only the super admin can do. The site admins within the network can only activate or deactivate them. Well, and site admins can only activate and deactivate plugins in case the super admin checked the box Enable administration menus in the network administration in Settings → Network Settings.
Enable administration menus to allow admins to enable/disable plugins.
You can find the plugins administration for the whole network under Network Admin → Plugins, the themes administration under Network Admin → Themes.
Install plugins in a multisite and make them available for the whole network
For the site admin, the whole thing looks like the next picture.
The plugins administration as site admin in a WordPress multisite
Hint: The admin can activate and deactivate plugins, but he cannot install or uninstall them.
For one of the plugins in our example you can read Network Only. This means the plugin is available only for all sites or for no site. Moreover, it’s the super admin only who can set the settings of this specific plugin, you need to make them in the network administration.
You can find further help to set up your multisite in our documentation category WordPress Multisite 1×1. In case you are setting up a multilingual website, take a look at: MultilingualPress getting started.

MultilingualPress License Update

MultilingualPress License Update
Starting from version 3.3.3 the licensing system of MultilingualPress has been updated, and the info needed to activate the license are now different, depending on the plugin version you currently use.

Table of Contents

Version minor or equal to 3.3.2 requires an Api Key and an Email AddressVersion above 3.3.2 requires a Master Api Key and a Product Id code
Version minor or equal to 3.3.2 requires an Api Key and an Email Address

The Api Key is available in your My Account page, in the Dashboard or Api Key section and it is now named as Deprecated.

The purchase Email is available in your My Account page, in the Account Details section.

You can use these information to activate your license, inserting them in your plugins settings license tab.

Version above 3.3.2 requires a Master Api Key and a Product Id code

The Master Api Key is available in your My Account page, in the Dashboard or Api Key section. This key can be used to activate any of the products you purchased.

 

The Product Id identifies the product purchased and it is available in the My Account page, in the Dashboard or Api Key section.

You can use these information to activate your license, inserting them in your plugins settings license tab.

How to translate Advanced Custom Fields (ACF) with MultilingualPress 3

How to translate Advanced Custom Fields (ACF) with MultilingualPress 3
Starting from version 3.5 MultilingualPress offers a new module that lets you easily manage the custom fields translation through the Plugin Advanced Custom Fields (ACF). To show how this feature works in your Multilingual site, here we provide a brief tutorial on the topic.
Note: For custom fields created by using other Plugins or the WordPress API for custom fields, we recommend this tutorial.

Table of Contents

Environment settings: WordPress Multisite and MultilingualPressACF installation and activationACF Module ActivationACF SettingsACF Translation
1. Environment settings: WordPress Multisite and MultilingualPress
First of all, create a Multisite WordPress installation and then install MultilingualPress version 3.5 or above. In case you need support to install a multisite environment, you can follow the instruction here reported: how-to-install-wordpress-multisite
When your Network is ready you can then proceed in installing and network activating MultilingualPress. Also in this case, if you need support you can refer to the following document: Installing-MultilingualPress-3
You are just a step far for creating your Multilingual site: proceed in creating two or more subsites as explained in Create-a-new-website-within-the-multisite-and-set-the-language-for-the-site, and connect them in MultilingualPress through the Relationships section.
If now we go to MySites→Network Admin→MultilingualPress we see that the ACF Module is disabled.
If ACF Plugin is not installed and activated the MultilingualPress module is disabled
This because we haven’t installed yet the ACF Plugin in the Network. To accomplish that let’s proceed to the next section.
2. ACF installation and activation
In this section, we can now proceed in installing the Advanced Custom Fields Plugin. To do so you can log into your WordPress installation back end and then go to My Sites→Network Admin→Plugins.
From there, search for Advanced Custom Fields By Elliot Condon Plugin, then install and activate the Plugin by clicking on the button.
Download, install and activate ACF Plugin
This way you activated the ACF Plugin on your site.
3. ACF Module Activation
The next step is to activate the ACF module in MultilingualPress. This can be easily accomplished by going into MySites→Network Admin and selecting the MultilingualPress link in the left menu.
This way you access the MultilingualPress settings page. From there, in the Modules tab, click on the ACF checkbox and finally press the Save Changes button to activate the ACF module.
ACF Module Activation in MultilingualPress
4. ACF Settings
In this section, we provide an example of how the custom fields should be set.
Suppose we want to add a proverb every time we create a post. To achieve that let’s create a group of new custom fields to be added to the standard posts called Proverbs Group.
Go to your main subsite Dashboard and then head to Custom Fields→Add New. Fill in the group text field the name Proverbs Group as shown below.
Create a group field using ACF Plugin
In the Location section, it is possible to specify to which post type the new fields will be added.
Right under the Field Group name, it is possible to add one or more custom fields pressing the Add Field button . Let’s create a text area field with label Proverb as shown below.
Create a custom field using ACF Plugin
The ACF Plugin lets you configure several types of fields, for further details you can refer to the official documentation
At this point the fields are ready in our main subsite, but now we also need to create the same custom fields in all the subsites where we want manage their translation through MultilingualPress.
To proceed, go to the main subsite Dashboard and there head to Custom Fields→Tools . In that section, it is possible to export the custom fields we want to replicate in other subsites.
Select the Proverbs Group checkbox in the Export Field Group meta-box, then press Export File to create the file with the data to export.
Export the custom filed through the ACF Tool
Similarly, from the Dashboard of a secondary sub-site related with the main one, the site it in our example, import the previously exported file: head to Custom Fields→Tools and in the Import Field Group section upload the file and then press Import File .
Import the custom filed through the ACF Tool
At this point, we have the same custom fields in two subsites connected through MultilingualPress.
Finally let’s check how MultilingualPress manages such fields.
5. ACF Translation
At this point we are ready to work with the custom field through MultilingualPress.
To do so, let’s create a new post in the main subsite and let’s fill the Proverb field with the sentence  “You can lead a horse to water, but you can’t make him drink.“, as shown in the picture below.
Insert a proverb in a new post
Then in the translation meta-box that relates the content with the connected subsite, it in our example, we select the radio button option in order to create a copy of our post.
Creating the post on the remote site via translation meta-box
After this selection, the other tabs are enabled: we can access the ACF tab and set the checkbox in order to overwrite the remote custom field content with the proverb sentence we previously inserted.
Copy ACF field option on translation meta-box
After that we can save our post and go to the second subsite, it in our case. There we will find the new post created via MultilingualPress with the same custom field filled with the expected proverb content.
In the remote subsite, the post is duplicated and the custom field content is duplicated too
Similarly, you will be able to propagate any custom field content to all the related subsites. Just working only on a single post, all the related ones will be then properly managed by MultilingualPress.

How to translate Custom Fields with MultilingualPress 3

How to translate Custom Fields with MultilingualPress 3
In this document, we’ll explain how to translate custom fields using MultilingualPress 3. For the sake of simplicity, we are going to use the Advanced Custom Fields Plugin to create the custom fields. Just keep in mind that the process described here is the same for any other Plugin that allows you to create custom fields or if you are creating them manually using WordPress Custom Fields API.
Note: MultilingualPress offers since version 3.5.0 full compatibility for Advanced Custom Fields. Therefore, Advanced Custom Fields can also be translated for connected pages within the WordPress editor. Here is a special Tutorial for translating Advanced Custom Fields explaining all functions.
There are currently two approaches about how to implement custom field translations.

Table of Contents

Creating a new site based on an existing oneCreating the custom fields manually in each siteInstall and Network activate Advanced Custom FieldsCreate a custom field in the main siteCreate the custom field in site 2Connect the posts that contain the custom fields
1. Creating a new site based on an existing one
The first one is setting up the main site, create the custom fields and the content. Once everything is created we can create a new site based on the existing one. Doing so will copy everything to the new site and we are only going to need to translate the content. Everything else including the custom fields will be automatically created in the new site.
Here is a quick video showing the process of creating a new site based on an existing one with existing custom fields:

Video Playerhttps://multilingualpress.org/wp-content/uploads/sites/12/2020/03/create-site-custom-fields.mp400:0000:0000:00Use Up/Down Arrow keys to increase or decrease volume.

2. Creating the custom fields manually in each site
The second approach is when you already have two or more sites connected and you want to include custom fields. In that case, the custom fields need to be created manually on each site.
In this article, we are going to explain the second approach. To do so we´ll create a new WordPress Multisite installation with two sites connected:
Two connected sites in a multisite using MultilingualPress 3
2.1. Install and Network activate Advanced Custom Fields
Install the Plugin Advanced Custom Fields
Go to My Sites -> Network Admin -> Plugins and install Advanced Custom Fields. In this case, we are network activating it, that decision will depend on the nature of each Plugin if it includes support for Multisite or not. If you are in doubt, the recommended way is to activate individually on each site, like you usually do in a single site.
2.2. Create a custom field in the main site
Advanced Custom Fields UI – create a new group and a field
In site 1 create a new group and a new field using Advanced Custom Fields UI.
Set value of the custom field in a post
In site 1 fill the value of the custom field in a post.
2.3. Create the custom field in site 2
In order to create the custom fields in site 2, we can use the export/import functionality provided by Advanced Custom Fields on the Tools page. But because in our example we are only dealing with one single group with one single field, we are going to create it manually in site 2.
Create the custom field in site 2
The most important thing to keep in mind here is to ensure that the field slugs are exactly the same across all connected sites. That way the code displaying the fields will grab the correct translation based on the site the visitor is currently in. So let’s say that you create a new field with the slug ‘some_field’ on site 1, you need to create a field with the same exact slug ‘some_field’ in site 2.
2.4. Connect the posts that contain the custom fields
Connect the posts with custom fields
Finally, in order to be able to connect custom fields across sites, you simply need to connect the posts containing the fields using MultilingualPress translation metabox.