We just released version 2.4.2 of MultilingualPress. This is a patch release including two bug fixes introduced in MultilingualPress 2.4.0. Thank you very much for your contributions!
Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts
We just released version 2.4.1 of MultilingualPress. This is a patch release including two bug fixes introduced in MultilingualPress 2.4.0. Thank you very much for your contributions!
- Fix potentially incorrect type hint.
Today, we released version 2.4.0 of MultilingualPress. This is a regular release including both bug fixes as well as new features. Thank you very much for all your contributions.
- Fix term relation not being deleted when term is deleted.
- Fix dynamic CPT permalinks (due to regression during merge).
hreflanglinks and headers.
- Refactor and improve the post translator’s “Copy source post” functionality.
- CPT translator: allow translation for all editable post types.
- Use the full slug when copying post data.
- Use the new
network_site_new_formaction hook (where available) instead of injecting markup with jQuery. Yay!
- When creating a new site, the MultilingualPress language follows the site language (but can be set individually).
- Fire the
switch_themeaction when a site has been duplicated.
- Add the MultilingualPress settings page link to the plugin list in the WordPress Network Admin.
- Implement selective refresh support for the Language Switcher widget.
- Delete the according Language nav menu items when a site is deleted.
- Add filter for remote post search minimum input length.
- Sort remote post search results by relevance.
- Lots of late escaping.
- Improve (i.e., prepare/escape/cache) several MySQL queries.
- There are lots of other, minor improvements, too many to list them all.
Developers: As mentioned in the previous release, we change the plugin text domain from
multilingual-presswith this release, so we are now able to use the official WordPress.org GlotPress for translating MultilingualPress.
Today, we released version 2.3.2 of MultilingualPress. This is a patch release that fixes four (potential) bugs. Thank you very much for all your contributions.
- Fix leftover entry from site option included in languages data.
- Fix potentially invisibe plugin activation row on Add New Site page.
urldecodeto account for non-ASCII characters.
- Fix incorrect
ml_typevalue of duplicated custom post type posts.
Developers: As we would like to use the official WordPress.org GlotPress for translatingMultilingualPress, we will (have to) change the plugin text domain from
multilingual-presswith the next (major) release. So, in case you are doing crazy things with our translations (which you basically should really not), please be informed.
Even though MultilingualPress is available on WordPress.org and its SVN server, we use GitHub (i.e., Git) for development and version control. While the WordPress.org SVN repository and the generated ZIP file only contain what the end-user really needs for using MultilingualPress, the GitHub repository also includes additional development files (e.g., resources, and tests). In this article, I would like to present and discuss the file organization of MultilingualPress’s development repository.
The Development Repository
In the GitHub repository root, you can find individual folders for assets, resources, sources, and tests. And then there is a bunch of files, for instance, several config and markdown files, and a
multilingual-press.phpfile. None of them is required to use the plugin—yes, not even the PHP file.
So, let’s have a closer look at the folders and files. For the sake of a better understanding, however, we don’t do this in alphabetic order, but in a somewhat logical order.
srcfolder contains what is required to use MultilingualPress, and thus will be shipped to and by WordPress.org. In this folder, we currently find assets (images, scripts, and styles), language files (which soon will be removed in favor of the official WordPress.org GlotPress project for MultilingualPress), the license and readme files, and the actual PHP source files.
assetsfolder in the root (not to be confused with
src/assets) contains the assets for the WordPress.org SVN repository (i.e., banner and icon images, and screenshots). These files are not required for using the plugin, but only for the official plugin page in the WordPress.org plugin repository.
For both the back end and the front end, there is only a single CSS file (in a minified version, and in an unminified, debugging-friendly version). The CSS development, however, does not happen by using a single large unminified file, and then compressing it. Instead, the basis for the plugin styles consists of several
.scssfiles that are structured in the
resources/scssfolder. We use a few reusable modules, and split individual styles into partial files according to their individual context (in terms of plugin features or modules).
Similar to styles, the shipped plugin scripts are just a single file for each back end and front end (again, in minified and unminified versions). The development of the script files happens on the basis of a base file (e.g.,
resources/js/admin.js) and several other independent files in a folder named after the base file (i.e.,
Both the WordPress.org assets as well as the plugin images are all shipped in a compressed and web-optimized version. The high-resolution/high-quality originals live in the
tests/phpunit/integrationcontains PHP integration tests using PHPUnit.
The Proxy File
To make working with the development repository as easy as possible, there is a proxy (main plugin) file living in the root. It is named exactly like the (real) main plugin file located in the
srcfolder, and it pretty much only calls (i.e.,
requires) the real thing. By doing this, you can just clone the GitHub repository into a project’s plugin directory and simply use the plugin as if installed from WordPress.org—no need to copy the contents of the
srcfolder to a new
multilingual-pressfolder, or anything like that.
There are several advantages of organizing a plugin like this. Here are the most obvious ones:
Apart from possible config files, which are located in the root, you always know where to look when you search something. If you want tests, look inside the
testsfolder. If you don’t want tests at all, you only have to remove the
We can have an
assetsfolder in the root that contains the WordPress.org assets, while the actual plugin assets are located in
src/assets. No name conflict, no need to make up a name for what actually should be assets anyway.
Publishing a new release on WordPress.org is as simple as this:
- clone the repository (GitHub);
- remove everything from trunk (SVN);
- copy the contents of the src folder to trunk
- add a new tag folder (SVN), in case you use tags (which you should);
- add all new files to SVN;
So far, we’re unaware of disadvantages. Are there any?
Today, we released version 2.3.1 of MultilingualPress. The release is a patch that fixes fixes two potential bugs in case the
wp-includesdir has been customized.
- Fix potentially invalid semi-hard-coded paths.
Today, on Saint Nicholas’ Day, we released version 2.3 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.
- Hide Redirect UI if the Redirect feature is disabled.
- Fix missing
noredirectquery var for all URLs of linked elements.
- New setting: Fire plugin activation hooks for active plugins when a site has been duplicated.
- Feature: Show sites with their alternative language title in the admin bar.
- There are lots of other, minor improvements, too many to list them all.
Today, we released version 2.2.3 of MultilingualPress. The release is a patch that fixes a bug with the Translation meta box. Thank you very much for all your contributions.
- Bugfix Translation meta box not visible.
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.
- Bugfix term auto-selecting, again.
realpath()for plugin file in requirements check to allow for symlinked plugin folder.
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.
- 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).