Make WordPress Core

Updates from October, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Morgan Estes 1:45 am on October 13, 2015 Permalink |
    Tags: ,   

    Week in Core: Sept. 28 – Oct. 11, 2015 

    Welcome back to the latest issue of Week in Core, covering changes from Sept. 28 – Oct. 11, 2015, changesets [34659][35029]. Here are the highlights:

    See that ↑ right there? That’s an oEmbed. And it’s loaded from inside this site.

    Feature Plugins Merged

    The Responsive Images, oEmbed Provider, and the “baby” REST API feature plugins have been merged into core. Grab the latest version of trunk and test them out.

    WordPress logo with wordmark below

    Responsive images in your posts. Just upload and insert!

    Potent Notables

    These changes were big enough to merit their own blog posts:

    Deeper Reading

    Some commits pack in a lot of info, from detailed background to best practices in using hooks. Here are a few worth reading the entire commit message:

    (More …)

  • Morgan Estes 7:37 pm on September 29, 2015 Permalink |
    Tags: ,   

    Week in Core: Sept. 21-27, 2015 

    Oh Snap!, it’s time to usher in a new edition of Week in Core! If you have the time, throw a house party with some friends and read the full force of changes on Trac; if not, don’t sweat it — take simple pleasure in these highlights.

    This post covers changesets [34362][34658], committed during Sept. 21–27, 2015. Let’s give a hi-five and some TLC to the 102 contributors for a combined 296 updates! Together, we’re making WordPress nice & smooth.

    (More …)

  • Morgan Estes 9:08 pm on September 21, 2015 Permalink |
    Tags: ,   

    Week in Core: Sept. 13-21, 2015 

    Welcome to the Week in Core — Week Four, with super-exciting news from around WordPress-land, and Core changes and updates for Sept. 13–21, 2015 (commits [34093][34361]). This week’s core contributors number 106! I’m especially jazzed about the number of new names on the list, and want to thank everyone for your effort this week.

    News you can use

    The WP REST API team submitted a proposal to merge the plugin into core, with a two-phase integration plan. The merge proposal blog post also does a nice job of presenting the history of the plugin and some use cases.

    Do you use my-hacks.php in your site? Don’t. (A quick search through the plugin and theme repos shows only 10 plugins and 3 themes that mention the file.)

    Multisite is making some pretty big changes, including the addition of the  WP_Network class. Check out this blog post, which outlines some of the changes and a roadmap for future updates for 4.4.

    Interested in the user-focused part of WordPress? Of course you are! Join in the conversation about “Potential UI/UX projects in core.”

    Code changes

    Here are some highlights from the 268 change sets published to Trac; the complete report is available online in plain-text format for a bit more in-depth coverage.

    (More …)

  • Morgan Estes 9:04 pm on September 16, 2015 Permalink |
    Tags: ,   

    Week in Core: Aug. 31 – Sept. 12, 2015 

    Welcome to the Week in Core, with updates from weeks 2 & 3: Aug. 31 – Sept. 12, 2015, changesets [33821][34092].

    It’s been a busy couple of weeks in Core, with almost too many changes to count (for the record, this one covers 271 commits!). I’m going to keep this update shorter than usual and highlight some of the bigger changes.

    If you’re interested in helping write this weekly post, ping @morganestes in #core-weekly-update on Slack.

    Special Note: WordPress 4.3.1 was released this week, with three security-related fixes. Be sure to update your sites!

    Here’s some highlights of recent changes in core, along with some future plans and ongoing initiatives. Remember, Core moves pretty fast. If you don’t stop and look around once in a while, you could miss it.

    • WordPress will support PHP7 when it’s released. Huzzah!
    • HTTP/2 is coming! Here’s a list of tickets that need attention to get WordPress ready.
    • Get involved in Twenty Sixteen, which is in active development on GitHub.
    • Write better commit messages. The world will thank you for it. :)
    • As described in this post by @johnbillion, the show_ui flag for post types now gets fully honored. See #33763 for the ticket discussion.
    • A new helper function, wp_validate_action( $action = '' ), was introduced in [34059] and is used throughout admin instead of directly accessing $_REQUEST['action'].
    • A new file, wp-admin/includes/noop.php, was created to load all of the noop functions for load-script|styles.php and is only loaded by those files. DRYs in the process. [34037] #33813
    • Schema change introduced in [34030] to increase the length of wp_options.option_name to 191 chars. #13310
    • Implement a priority system for Help Tabs to add them at specific positions. [33985] #19828
    • Multisite: Don’t allow sites to be created with the following reserved slugs: wp-admin, wp-content, wp-includes [33952] #33615
    • Updated recommendations for minimum versions of PHP (5.6) and MySQL (5.5), with a special note that Oracle only actively supports MySQL for 5 years after a General Availability release. [33937] [33946]

    For the full report, visit https://core.trac.wordpress.org/log/?verbose=on&format=changelog&rev=34092&stop_rev=33821&limit=400&mode=stop_on_copy.

    Thanks to @adamsilverstein, @afercia, @amereservant, @ankit-k-gupta, @antpb, @austinginder, @azaozz, @BdN3504, @benjmay, @boonebgorges, @bradt, @brettz95, @celloexpressions, @cgrymala, @Cheffheid, @chriscct7, @codeelite, @CoenJacobs, @danielbachhuber, @daniellandau, @dannydehaan, @dd32, @dimadin, @dipeshkakadiya, @dlh, @DrewAPicture, @dustinbolton, @egower, @enshrined, @ericdaams, @ericlewis, @extendwings, @figureone, @filosofo, @gaelan, @GaryJ, @gitlost, @gnaka08, @gradyetc, @gregrickaby, @hauvong, @helen, @imath, @ippetkov, @iseulde, @ixkaito, @jazbek, @jeffstieler, @jeremyfelt, @jesin, @jobst, @johnbillion, @joostdevalk, @jorbin, @juliobox, @JustinSainton, @kevinlangleyjr, @khromov, @kitchin, @kraftbj, @lancewillett, @liljimmi, @lukecarbis, @macmanx, @MatheusFD, @mehulkaklotar, @mercime, @metodiew, @michielhab, @MikeHansenMe, @miqrogroove, @mitchoyoshitaka, @mordauk, @morganestes, @mrahmadawais, @mrmist, @Mte9, @nacin, @netweb, @nikeo, @nikolovtmw, @nofearinc, @obenland, @ocean90, @OriginalEXE, @Otto42, @paulwilde, @pavelevap, @pento, @peterwilsoncc, @racaseh, @rachelbaker, @rajnikmit, @rmccue, @rommelxcastro, @sc0ttkclark, @scribu, @SergeyBiryukov, @sillybean, @solarissmoke, @stevehenty, @swissspidy, @tmatsuur, @trepmal, @tyxla, @umeshnevase, @utkarshpatel, @wen-solutions, @wenthemes, @westonruter, @wojtekszkutnik, @wonderboymusic, @yoavf, and @zeo for their contributions!

  • Scott Taylor 5:37 pm on September 2, 2015 Permalink |

    Deputies for 4.4 

    In lieu of picking one “backup lead” for WordPress 4.4, I have decided to recognize two of the hardest working devs in show business as my deputies for the release. They have both been crushing it in Core for as long as I can remember and are essential to making this release run smoothly for me.

    Dominik Schilling

    Sergey Biryukov

    Excited to be working on another release with Dominik Schilling and Sergey Biryukov!

    I have peace of mind when making bold changes to WordPress, because they keep us all honest and watch our changes closely. They know the codebase and have the experience to inform us of the implications of our changes related to the back end, front end, i18n, and browser compatibility. I dare you to stump @SergeyBiryukov on WordPress trivia, and I dare you to name a Beta period where @ocean90 wasn’t an All Star.

    Look out for them to lead bug scrubs and help me manage the release.

  • Ryan Boren 4:43 pm on September 2, 2015 Permalink |
    Tags: , maintainership   

    Component Page Updates for 4.4 

    Now that 4.4 is underway, let’s update the component pages to reflect 4.4 activity. The Customize, Editor, and Press This pages serve as good templates, though they all need 4.4 updates. The component pages are targeted at beta testers. They should describe the component, list milestones (roadmap), and explain what needs testing and how to test it. Good component pages assist triage. For details, see the previous round of component page updates.

    Also, if your component has a corresponding Slack chat, link to the component page from the chat’s channel topic. This assists using Slack in beta testing flows.

    Component maintainers, here are your component pages…

    (More …)

  • Dominik Schilling (ocean90) 8:38 pm on July 30, 2015 Permalink
    Tags: , ,   

    get_transient() is now more strict in 4.3 

    WordPress 4.3 includes a change to get_transient(). As reported in #23881 and #30380, get_transient() had a check for get_option( $transient_timeout ) < time().

    Because get_option() can return false and false is always < time() 😖, get_transient() could delete transient timeout options in an unexpected way or cause two more unnecessary queries.

    WordPress 4.3 now checks the return value first before comparing with the current time. This means that WordPress will no longer delete broken transients via get_transient() if you have only deleted the timeout option. See [33110].

    If you have to delete a transient manually, please make sure that you’re deleting _transient_timeout_$transient and '_transient_' . $transient. (Hint: Transients can be stored in an external object cache too.)

    See also: the Transients API Codex page.

    • webaware 2:09 am on July 31, 2015 Permalink | Log in to Reply

      Delete Expired Transients will delete those orphan transient timeouts automatically, which might be an easier option for some.

    • 99robots 8:58 pm on August 18, 2015 Permalink | Log in to Reply

      Great Stuff :)

    • Steve Truman 5:39 am on September 4, 2015 Permalink | Log in to Reply

      @ocean90 – just letting you know (if you do not already) that the change to get_transient is a very big problem for Premium Plugin and Theme developers and a potential timebomb for WordPress users of Premium products.

      Our plugins like most Premium Licensed plugins and themes auto check for new versions using transient to call to the a3api once each 24 hours.

      The obscure change to the transient has deleted that. We alone now 9,000 plus licensed plugins that no longer call to the a3api (if they have upgraded to WP 4.3) and can never know that there is a new version. I know that this affects many developers premium plugins.

      This of course is a massive security issue over time.

      It is an easy enough fix by adding this code

      `// Fixed for work compatibility WP 4.3 when transient_timeout is deleted
      if ( false !== $respone_api ) {
      $transient_timeout = ‘_transient_timeout_’ . ‘wc_psad_update_info’;
      $timeout = get_option( $transient_timeout, false );
      if ( false === $timeout ) {
      $respone_api = false;

      That is not the issue – because adding that in a new version is of no help as the user never sees an upgrade notice to get the code if they have already upgraded to WP 4.3

      I do not know how many WP users will be affected by this as just about every Premium Plugins has the issue now – example Gravity Forms and All WooThemes WooCommerce plugins

      There is not much point in emailing customers to tell them about it and ask them to deactivate and reactivate the plugin or theme (which will trigger a manual call to the a3api and get the new version for auto upgrade via core updates) as email open rates on mass mail outs are low.

      I have absolutely no idea what you can do about it or if you are even interested in rectifying the situation – but just be aware that there will be many 100,000’s of thousands of Premium plugins and themes sitting on WordPress sites that will never be updated again and that is a massive security issue.


      • Ipstenu (Mika Epstein) 2:39 pm on September 4, 2015 Permalink | Log in to Reply

        I think @mordauk may be better equipped to explain it, but can’t you hook into wp’s update checker and just add your own API to it? That was always the preferred method as I understood it, and uses WP-cron. I know EDD does that to look for updates to my add ons.

        • Pippin Williamson 2:46 pm on September 4, 2015 Permalink | Log in to Reply

          Yes, hooking into the standard update API is a much better solution, but even without using it, this change should not break update checks added to commercial plugins.

          The only time (correct me if I’m wrong) that this change will break custom update checks is if one is forcing an update check to run by deleting the transient timeout in the wp_options table.

          A transient that has naturally expired still functions exactly the same as it always has. Yes?

    • Steve Truman 6:42 am on September 5, 2015 Permalink | Log in to Reply

      Hi Mika and Pippin – thanks for your replies. We used to use the standard update API of WP but it caused issues as the API call not only checks for new version but also checks the “SERVER_ADDR” to verify the License key. This was failing due to a known and unresolved WP_CLI bug – wp doesn’t fully populate $_SERVER array https://github.com/wp-cli/wp-cli/issues/1734

      As a work around for the issue we created a fall back cron that if the “SERER_ADDR” fails then the call is scheduled for every 2 hours for 10 retries. Doing this completely resolved the issue.

      This is the code
      //Getting version number
      $respone_api = get_transient(“wc_psad_update_info”);
      if ( ! $cache ) {
      $respone_api = false;
      // If transient is expired or is not existed then connect to a3api server to get new version and save to transient as cached with timeout is 24 hours or 2 hours for some way can’t connect to a3api server
      if ( ! $respone_api ) {
      //connect to a3api server to check new version

      on WP 4.2.4 or older
      if ‘_transient_timeout_wc_psad_update_info’ is deleted by any reason
      $respone_api = get_transient(“wc_psad_update_info”);
      will return ‘false’
      and is correct to our plugin connect to a3api server for check new version

      With WP 4.3
      if ‘_transient_timeout_wc_psad_update_info’ is deleted by any reason
      $respone_api = get_transient(“wc_psad_update_info”);
      will not return ‘false’, it return cached value ( this cached value is never removed if ‘_transient_timeout_wc_psad_update_info’ is deleted )
      and it never go to
      if ( ! $respone_api ) {
      //connect to a3api server to check new version
      to get new version

      Hence the plugin can never call for new version – user has no idea and just thinks there is no updates. We have a developers License for Gravity Forms and know it has the same issue as well as WooThemes WooCommerce plugins

      As I wrote the fix is easy – what is not easy or clear is how let License holders know that there is an updated version with the patch.

      I note the update was “get_transient() is now more strict in 4.3”

      I am not aware of any issues with the old get_transient function? Was there security or other issues that required the change?

      As I wrote we are not the only Premium plugin developers who have this issue and unless it is addressed there will be 100,000’s of wp site with plugins or themes that never show new version upgrades and hence over time will become a security issue.

      • Pippin Williamson 1:27 am on September 6, 2015 Permalink | Log in to Reply

        aWhat you’ve described makes sense as a way for update detection, but doesn’t follow what core has changed.

        The only reason your transients would no longer be working is if you (or someone else) is deleting the _timeout value without deleting the rest of the transient.

        One possibility for you.

        Don’t do: if ( ! $cache ) {

        Do: if ( false !== $cache ) {

      • Ipstenu (Mika Epstein) 4:36 am on September 6, 2015 Permalink | Log in to Reply

        The issue with the old get_transient was they weren’t deleting properly. They could “could delete transient timeout options in an unexpected way or cause two more unnecessary queries.” In the race for speed, the queries were killing some heavy sites.

        Looking at your explanation:

        > This was failing due to a known and unresolved WP_CLI bug – wp doesn’t fully populate $_SERVER array

        Without looking at the code that was failing I can only ask “Why did you chose to do this instead of not using $_SERVER?” Looking at that bug (https://github.com/wp-cli/wp-cli/issues/785 is the current one), using dirname(__FILE__) was a good fix, and FWIW, I’ve actually had $_SERVER in my wp-config and it does ‘break’ wp-cli but how does that break your code? My updates have trucked along just fine with wp-cli being weird. I don’t get how they’re related.

        Also where was the SERVER array in your code, what was it being used for, and were there other alternatives? I’d love to see if we can fix this the ‘right’ way … Though IMO the ‘wrong’ is because wp-cli is borked because PHP (yeah, it’s PHP) is stupid. I’ll drop a note to wp-cli about it.

        See http://stackoverflow.com/questions/626416/php-server-name-from-command-line

        The answer for “How do I inform my users?” is one presumes you have their contact information? So … email. It sucks but a “Hey, sorry about this but we didn’t notice a change in WP conflicted with our update checker. You need to manually update. We’re REALLY sorry. Here have a free orange.” Or something like that.

  • Simon Wheatley 4:43 pm on June 29, 2015 Permalink
    Tags: , ,   

    WordCamp Europe 2015 – Multilingual Discussion 


    Drupal Multilingual Overview

    Christian López Espínola is a Drupal contributor to the multi-language features in that project, and gave us this overview of the multi-language features in Drupal 7 and upcoming in Drupal 8:

    In Drupal we have different modules bundled with core. The language module was added in Drupal 7, which gives support for assigning languages to content. Drupal already had Interface translation support as WordPress does.

    Drupal 8 adds content translation, with a UI.

    At first the problem was that there are two different strategies for doing this. Drupal 7 gave support for translating a node by creating copies; having multiple posts for one piece of content. This made it hard to select the content required for display in case other modules were not aware of or not interested in multilingual support. Moved to translations to the field level, so stored in the equivalent of post meta. One content node now contains all the translations, so fields attached to the node have translations of the title, content, etc, into all languages if those fields are translatable, this way content is not duplicated (i.e. fields are not duplicated between nodes if they are not translatable).

    Q: How does Drupal connect languages into groups of translations of one piece of content.
    A: If one post is a translation of another, there is a field which links it. D7 two nodes. D8 has one node, and translated content is stored in fields (with language attribute).

    Q: What issues did the adding of content language cause?
    A: At some level we had two different posts, one for each language. So if your plugin doesn’t consider internationalisation, then this causes issues because you are considering translations different content, and mix languages in the UI. For example if we want to rate a post from a rating plugin, we may want the rating to be “shared” between all translations of that content.

    Some Approaches to Attributing Language to Content

    We looked at just a few multi-lingual plugins, to see how they addressed the issue of storing language content.

    <caveat>This is by no means an exhaustive list, and only reflects the solutions that the people in the discussion have had experience with :) Please feel free to add other examples or corrections in the comments.</caveat>

    • WPML table structures – to attempt to synthesise this link: each translated content object is stored as a post, and a WPML database table links the content into groups and specifies the language of each content object.
    • Babble puts each the translation for each content object into a custom post type or custom taxonomy, e.g. `post`, `post_fr_fr`, `post_pt_pt`, and uses a taxonomy to group translated content objects together, so you can say “this post is a translation of this other post”. A disadvantage of this approach is that translated content does not have an expected post type, e.g. post, but instead a Babble translation post type, e.g. `post_pt_pt`.
    • Multilingual Press stores content from each language in a separate site in a WordPress multisite. There is a database table which links translated content across sites.
    • Polylang does not create any additional database tables at all. It creates 4 taxonomies: `language`(to hold all the languages you configured), `term_language` (the terms in each language ex. EN: Uncategorized, DE: Allgemein), `term_translations`(connects the translated terms in each languages) `post_translations` (connects translated posts). The plugins seems to be fairly lightweight compared to others and works well with many additional plugins too.


    There are lots of varied issues which multi-language, translation, and/or localisation plugins and projects seek to solve. WordPress core should not provide a translation or localisation UI and/or workflow, we should continue to rely on the plugin space to address different user scenarios.

    We do believe that there are some things which core could provide which would facilitate translation in the ecosystem for this type of plugin.

    Proposal one: core could provide a minimal way to mark content (e.g. posts, terms) as a particular language.

    • In the simplest case, a single language site, all posts would be implicitly assumed to be in the selected front end language for that site.
    • When a translation/localisation plugin is added, the plugin has the duty to set the language for each piece of content (post, term, etc).
    • If this shipped, it would be, by design, “invisible functionality”, and an example plugin would be useful.
    • How would this affect the WordPress exporter and the importer? The translation/localisation plugin would have the duty to add any UI to the importer/exporter, and core would need to provide the necessary hooks, etc.
    • Should we consider special locales like “no language” and “unknown language” (Drupal does this)? Perhaps core specifies these “locales” as a standard, but doesn’t use it.
    • This might be implemented as an additional column on the `wp_posts`and `wp_terms`tables, with associated post and taxonomy API additions and enhancements, which is available for plugins to use.

    Proposal two: core could provide a method or standard for translating strings stored in content objects like widgets

    In some contexts it is hard for a translation or localisation plugin to know what requires translation, e.g. in widgets when the data is stored in a blob in the database. It would be useful if core provided a pattern for others to follow to mark particular strings of text as translatable.

    Taking the example of a plugin providing a text widget, with user editable title and body fields, this plugin could follow the same standard to make these strings available to translation plugins. A possible implementation might be a filter or set of filters to pass the string for translation, and perhaps also the nature of the string to give a hint for the translation UI required, e.g. “rich text” (perhaps the translation plugin would provide a TinyMCE instance), “plain text” (perhaps a simple text area), etc.

    Other things discussed:

    • Setting the admin area language differently to the front end language, including showing the admin bar in the admin area language – being addressed in #26511
    • Supporting variants on locale, e.g. Portuguese informal, as these cannot be defined within the ISO standard currently – being addressed in #28303
    • dejudicibus 4:57 pm on June 29, 2015 Permalink | Log in to Reply

      You forgot to mention QTranslate X, one of the best fre plugin for multi-language sites.

      • jennybeaumont 5:01 pm on June 29, 2015 Permalink | Log in to Reply

        As Simon states above, this is not an exhaustive list, but simply the plugins that were discussed by (because used by) those who attended this meeting.

      • Simon Wheatley 5:11 pm on June 29, 2015 Permalink | Log in to Reply

        If you have knowledge of how QTranslate X stores and manages translations, please do add those details here.

        • MSTannu 7:51 am on June 30, 2015 Permalink | Log in to Reply

          The qTranslate family of plugins store multilingual content in the same database field, wrapped in special markup to differentiate each language. While this seems like extra work to pull content in all languages every time, in practise it’s considerably faster than queries with increased complexity to link different fields / tables to language information stored elsewhere.

        • Mike Manger 9:17 am on June 30, 2015 Permalink | Log in to Reply

          It stores all the language content in the post content areas with wrappers for each language (e.g. [:en]Title[:fr]Titre[:]). It has hooks to filter the content and return the requested language. There is no interface for widget support (although you can manually use the tags).

          Not a very clean implementation but I do like the tab interface for changing language.

        • Ihor Vorotnov 3:37 pm on October 13, 2015 Permalink | Log in to Reply

          I use qTranslate X on some projects, as well as Polylang, WPML and Multilingual Press. The qTX stores all traslations in the same fields, with a special markup. It has pros and cons. However, the biggest con for me always was its incompatibility with other plugins. Currently, I’m trying to make it work with ACF Pro and bbPress. Damn, it’s a pain in the a$$. Possible, but still lots of work and debug.

    • Pascal Birchler 5:12 pm on June 29, 2015 Permalink | Log in to Reply

      As this is a very complex topic where we need to consider lots of details and exceptions, I suggest starting a working group with weekly meetings etc. I’m very willing to help out.

      • Nick Weisser 10:59 am on June 30, 2015 Permalink | Log in to Reply


      • Simon Wheatley 10:11 am on July 1, 2015 Permalink | Log in to Reply

        @swissspidy This sounds good to me. I am free in the evenings on Monday and Thursday, EU hours, or during the day, EU time, most days. No time is good for all the world, but evening might be better?

        • Silvan Hagen 12:34 pm on July 2, 2015 Permalink | Log in to Reply

          Same here, could do Monday or usually during the day in the afternoon. Would love to put this into a working group.

          • Simon Wheatley 11:48 am on July 8, 2015 Permalink | Log in to Reply

            Sounds like Monday afternoon or evening, EU time, is a good option. I’m going to suggest we start the week after next (20th July), purely because I want to be there but I’m away next Monday. :)

            I’ll see what Slack channel we can find for these weekly conversations, and report back.

    • wycks 5:19 pm on June 29, 2015 Permalink | Log in to Reply

      You should really engage the folks over at WPML and Multilingual Press (Toscho), once you get into the details lots of little problems crop up, for example this has been bounced around for years and is a big pain for multi-lingual sites: https://core.trac.wordpress.org/ticket/18962

      At the end of the day if WP can help define relationships between content (taxonomy, posts, etc) it would go a long way to facilitate the already available plugins and other non translation plugins being able to work with complex content.

      • Francesco Di Candia 5:23 pm on June 29, 2015 Permalink | Log in to Reply


      • Misamee 6:17 am on June 30, 2015 Permalink | Log in to Reply

        @wycks, WPML is already engaged.
        Unfortunately, due to flight schedules, we couldn’t manage to attend the contributors day, but the day before we did share already some thoughts with Simon.

      • Frank Bueltge 12:22 pm on June 30, 2015 Permalink | Log in to Reply

        We (Inpsyde Company an the MLP team, include @ocean90 ) will help. We discuss the topic very often, also on contributor days. Our MultilingualPress is a result, dev and and maintain since 2007. But always with focus solid, stable, fast, no changes on core or content tables. I’m willing to help.
        Import for me is, that the WP core should provide the foundation/data, plugins should provide the details/UI.

      • Simon Wheatley 10:22 am on July 1, 2015 Permalink | Log in to Reply

        @wycks Thanks for the ticket reference.

        Everyone is welcome to contribute. :) As @bueltge says, Multilingual Press are involved. Robert (@nullbytes), who is a colleague of @toscho, was in the discussions at WCEU. The second proposal builds on a conversation with @amirhelzer and @sciamannikoo from WPML on Saturday at WCEU, and it was good to get their input.

        Regarding relationships and groupings: core already supports grouping posts and terms via taxonomies (e.g. to group all the translations of one post together), and this seems (to me) to be sufficient to the requirement here. Further, the taxonomy roadmap (update post) may offer a different way of linking posts together in the future, providing another route plugins could take advantage of.

        /cc @francescodicandia @paddyullrich

    • Michel - xiligroup dev 6:13 pm on June 29, 2015 Permalink | Log in to Reply

      Just to contribute in this multilingual context (well known and studied since 2009), before I will translate them in english, please find below two links to short recent articles.

      As data-designer, the very first thing to consider is to choose a monosite (standalone) WP install and a multisite (network) install. Secondly the main thing, in each type of install, is to consider standards so each developer can decide what type of plugin (easy to use for newbies or flexible full customizable for developer). In previous WordCamp in Paris and Lyon, I have done some analysis… and solution is not unique…



    • Matt Mullenweg 7:42 pm on June 29, 2015 Permalink | Log in to Reply

      Both proposals seem to assume that core should do something and this is no longer plugin territory. I haven’t seen anything yet that makes the case definitively for that.

      • nikolov.tmw 10:46 pm on June 29, 2015 Permalink | Log in to Reply

        Well, I guess there’s also the possibility of creating a working group that would be given the task of coming up with a proposal and then standard for how plugins should handle the content to language/locale association. This can be created as a feature plugin and if there’s an obvious benefit it could land in core in the future.
        In any case, having a standard way of creating that would be a great benefit in terms of plugins being compatible with each other and switching from one to the other would be a painless transition.

        It’d definitely be interesting to see if we can figure out how many sites actually use more than one language(although there are also those sites that don’t use a plugin, but instead just create separate sites for each locale).

      • Caspar 4:32 am on June 30, 2015 Permalink | Log in to Reply

        Both proposals do in fact assume this should continue to be plugin territory and core should do something about it in order to provide basic means of production.

        • Frank Klein 1:09 pm on June 30, 2015 Permalink | Log in to Reply

          That’s my understanding from reading the write up as well. It’s about Core being conscious of the existence of multilingual plugins, and accommodating them as much as possible.

      • Pascal Birchler 1:26 pm on July 1, 2015 Permalink | Log in to Reply

        Both proposals do in fact assume this should continue to be plugin territory and core should do something about it in order to provide basic means of production.

        The same was done with the REST API for example, where lots of new functions were introduced in WordPress to better support it. And core definitely needs better support for multilingual content.

      • Silvan Hagen 12:47 pm on July 2, 2015 Permalink | Log in to Reply

        In my opinion core should at least be aware of the language the content is written in and therefore provide some form of support towards storing the language of any type of content within core (all post types, taxonomies, widgets, user meta could be plugin stuff as it’s handled differently with different multilingual solutions).

        The problem with multilingual stuff in general is that not only does it add a huge layer of complexity to the solution, but also to the people using it (editors for example). For example Typo3 has multilingual baked into core and sadly it’s tied to a main language tree, so let’s say you have English as your main language and French as a secondary language, you can’t create content that is only available in French as languages are tied to the tree of pages for the main language.

        So for WordPress it’s clear that if we get some basic support in core, the means for translating the content and how to do it needs to stay plugin territory. For example I know sites where they display comments from all languages on translated posts and use basic machine translation for it. Others have a singular discussion stream per language and post. User meta for example is dealt with differently, if your site has a content team per language, the author bio doesn’t need translation and will be filled in the language the specific author is writing for, but if an author gets translations for their posts, a plugin needs to handle translations for the user meta.

        Here are some thing that could use basic support in core to make it easier:

        • Portability and content migration
        • Best practices and easy transition between multilingual plugins
        • Simple API in core to allow plugins to be aware of multilingual content

        We are far from a solution for this, that’s why I’m in favour of forming a working group for the topic as I think this is something that needs a lot of testing and experiments before a bullet proof minimal solution would be possible at all.

      • Simon Wheatley 3:02 pm on July 3, 2015 Permalink | Log in to Reply

        @matt Neither proposal intends to move the problem out of plugin territory; we are proposing that core provides some additional or enhanced APIs, and that core leads with some new hook standards or patterns. Plugins would still provide the UI and workflow, and would address different use cases. Any additions to core would be designed to make it easier for plugin authors (and ultimately better for users). We would obviously want to ensure that any changes do not break existing solutions, other plugins, or user sites, as is The WordPress Way.

        In relation to the first proposal, for core to provide a way to mark a post as in a particular locale: to my mind, all the approaches used by plugins described so far in this post and the comments have drawbacks. There is work required to integrate with other plugins. There are additional queries or query complexity. For me, ideally, adding multiple languages to a WordPress install should have little performance impact, and should not cause the need for workarounds with other plugins; currently this is not the case.

        • Matt Mullenweg 5:22 pm on July 3, 2015 Permalink | Log in to Reply

          But at least with a pure-plugin (no core changes) approach the added complexity and overhead of queries is only borne by sites running that plugin, not every user regardless of whether they’re multilingual or not.

          • Frank Klein 5:32 pm on July 5, 2015 Permalink | Log in to Reply

            So far I’ve seen no precise architecture proposal, or even code.

            Yet we’re dismissing the proposal outright for some vague fear that this might be too complex or not performant enough?

          • Benny 3:48 am on July 15, 2015 Permalink | Log in to Reply

            I guess for most of us living in a country where it’s natural to have sites with multilingual content it’s a no brainer that the content language should be a core field of any database table that stores content.

            On the other hand I can understand that someone who only has to deal with single language sites is not eager to see core to become multilingual when that means more complexity/overhead for common queries. But that same argument is also true for us who have to deal with the daily fact of sites being naturally multilingual, the sites of our clients, just like non-multilingual sites, should also function with a minimum of complexity/overhead.

            Maybe this difference in point of view can be overcome by introducing an core option or wp-config setting ‘IS_MULTILINGUAL’ and an related API conditional $is_multilingual.

            Core queries would then only execute the somewhat more expensive multilingual variant of a query (i.e. with an added WHERE language = %s clause/clauses) of any core query when the $is_multilingual query is set to true.

            To make these ml queries as fast as possible (i.e. no extra JOINs) we should concider to add a language field to any relevant table. This would bring the fastest possible solutions to both single language sites AND multilingual sites!

            I know you are not keen on db schema changes but I think the language column on relevant tables makes perfect sense.

            The user interfaces side of this could stay in the plug-in territory.

      • FolioVision 1:43 pm on July 9, 2015 Permalink | Log in to Reply

        Matt, may I remind you about the socio-economic phenomenon called Globalisation? I know Americans tend to hang out in monolingual environments but here in Europe almost every website needs to be bilingual at least. A bog-standard example would be a site like Czech computer vendor Alza.com which comes in Slovak, Czech and English. Our European issues with multilingual extend to Canada (French, English), China (Cantonese, Mandarin), much of South America (Spanish, Portugese for sites which traverse more than one territory). English speaking monolingual territories are a tiny minority (USA, England). Among other large nations, Russia is a similar monolingual environment but even Ukraine needs two languages on most websites. France, Germany and Holland most often want their native language with an English option.

        Leaving multilingual in plugin territory means there is no standardised solution to accelerate multilingual development. Every time one takes on a multilingual site one is reinventing the wheel. I’ll grant you Google’s games going back and with with ranking and demoting content on subdomains and Google’s confusion about multilingual articles on the same domain do not help at all with standardisation. Still many of the SEO bonuses and penalties for different languages on one site have been retired now.

        Plugins should be ENHANCING multilingual, not building it from scratch. At the very least, WordPress.org should add all the key building blocks. I would suggest you talk to the three or four top multilingual plugin authors, whether WPML and Polylang and ask them what additional syntax they would like to see in core to make their plugins faster, lighter and more reliable.

        Again just improving core support for multilingual is still a second best solution. Basic, reliable multilingual should really be in core.

        • Ihor Vorotnov 4:20 pm on October 13, 2015 Permalink | Log in to Reply

          +1 on this from Ukraine. I’ve built many multilingual sites for clients from Ukraine, Russia, Europe and even US (some US regions in fact have 2nd working language, spanish). Used Polylang, WPML, qTranslate X, Multilingual Press, tried and tested ALL available solutions (xili, Bogo etc), even built custom lightweight solution for one of the projects from scratch.

          I keep saying “there’s life outside US”. Because it is.

    • Alvaro Gois dos Santos 2:40 pm on July 2, 2015 Permalink | Log in to Reply

      First of all, let me congratulate @simonwheatley and all who were involved in the discussions we had in Seville regarding this subject.

      I second the notion that giving core the ability to identify content language could eventually be useful to all multilingual plugins and, hopefully, to make the switch between them easier. In a way, it would give the infrastructure, plugins would do the rest, UI included. It would also account for different approaches and I guess all the work that has been put into this solutions wouldn’t be lost.

      Another discussion is about locales and variations. Several locales have variations that, for now, WordPress doesn’t recognise. This makes it hard (if not impossible) for the common user to change his language variation from the default to a different one, even if it’s included in GlotPress. For instance: in Portugal (pt_PT) we have three versions, default (formal), informal and the Ortographic Reform version (not yet in GlotPress). We’ve tried to make it easy for the user with our PT Variants plugin, but I’m certain there could/should be a more efficient approach.

      • Simon Wheatley 11:03 pm on July 3, 2015 Permalink | Log in to Reply

        @alvarogois I believe the locale variants, e.g. Portuguese formal/informal, is being looked at actively in ticket #28303 :)

        • Alvaro Gois dos Santos 11:07 am on July 6, 2015 Permalink | Log in to Reply

          Thank you @simonwheatley, and thank you @ocean90 for being so active on this. I was not aware that we were so close 😉

        • Alvaro Gois dos Santos 4:27 pm on July 7, 2015 Permalink | Log in to Reply

          Hi again @simonwheatley: I’m having this idea about variants and managing variants translation through GlotPress, I’m not really sure where I should post it or if it has something to do with this discussion.

          Anyway, my idea (regarding GlotPress) is this: some variants are very close to the default language, only some of the strings actually differ, at least in Portuguese. I’m thinking of the formal vs. informal but also the orthographic differences like our own pre and post Orthographic Reform. There should be a way, in GlotPress, to link variants to the default translation. This would allow to have only one translation flow, and changes to be simultaneous in all variants. Now we have different flows, which makes it inefficient.

    • Vadym Volos 3:01 pm on July 7, 2015 Permalink | Log in to Reply

      I did not understand what the problem is?
      See how it is implemented on this engine: opencart.com

      You can take as a basis the plugin Polylang.

      • FolioVision 8:33 pm on July 14, 2015 Permalink | Log in to Reply

        I’m with you Vadym. Polylang would be a very good start. It’s lightweight clean code, the best of the current solutions.

        • Ihor Vorotnov 4:54 pm on October 13, 2015 Permalink | Log in to Reply

          I love Polylang, use it for most of the projects, however, it’s not the only way to go. It’s good, fast, but not perfect. And to make it better, we really need some Core changes. Ask Polylang’s author, @chouby, check WordPress.org Polylang support forum threads and some GitHub repos, related to Polylang, like this and this.

    • Vadym Volos 3:17 pm on July 7, 2015 Permalink | Log in to Reply

      When you do language support.
      Should work plugin “Page Builder by SiteOrigin” (https://wordpress.org/plugins/siteorigin-panels/)
      This ingenious plug! It helps make any page.

      Then I wrote about it: https://wordpress.org/support/topic/page-builder-by-siteorigin-only-works-for-one-language?replies=16

      • Ihor Vorotnov 4:58 pm on October 13, 2015 Permalink | Log in to Reply

        Having some basic API in WordPress Core, then multilingual plugins built over this shared API, will allow other plugin developers (including Page Builder) to add ML support easily. This whole discussion is about establishing some standard and following it by other plugins too.

    • Benjamin Lupu 10:28 am on August 10, 2015 Permalink | Log in to Reply

      First thank you for addressing this painful issue. I am still surprised that WordPress doesn’t provide a minimal multilingual support. I am working with since 2008 and at every project, it’s a problem. I also hear complains at every WordCamp (and not only French). There’s a huge need for that! IMO it could be a huge competitive advantage for WordPress providing a way its users to expand their businesses and publish globally. It would be also a selling point for enterprises. This is one of the first question asked when selling WordPress to an enterprises. I totally agree with what have been said earlier in this thread: we have to go further than an API and provide a minimal ready to use UI. It’s also a good idea

      • Benjamin Lupu 10:32 am on August 10, 2015 Permalink | Log in to Reply

        Shot too fast… So it’s also a good idea to be able to activate the multilingual in the wp-config settings. Anyway, correctly addressing the multilingual issue in WordPress would be a huge improvement and a sign that WordPress is really going global.

    • starise 1:00 am on September 8, 2015 Permalink | Log in to Reply

      Multisite Language Switcher is the best plugin for multilanguage so far.

      • Ihor Vorotnov 5:00 pm on October 13, 2015 Permalink | Log in to Reply

        Why it is? Can you list it’s pros from your point of view / experience?

        • starise 11:29 pm on October 26, 2015 Permalink | Log in to Reply

          I use multisite language switcher in production.
          Pros: fast and compatible, easy to use, good apis
          Cons: need the use of multisite.

          I have to say that i like the approach of “sublanguages” plugin too, in particular because it doesn’t need multisites. It uses most of core functionalities and marks post_type field as “translation_{ID}” to identify translations.

          Unfortunately this kind of “all-in-one” approach for my experience, can cause compatibility issues, where multisites is much more safe for production imho.

    • Vadym Volos 1:14 pm on September 23, 2015 Permalink | Log in to Reply

      Hi guys!
      What news?
      What progress?

  • Jeremy Felt 10:07 pm on June 9, 2015 Permalink

    Multisite Office Hours Recap (June 9, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    Today’s chat log
    Overall 4.3 Release Objectives

    Last week’s objectives:

    • Have all 3 of these tickets closed and committed. #22383, #32434, #32503
    • Additional iterations on `WP_Network` and `WP_Network_Query`.
    • Generate discussion around HTTPS on #14172. @jeremyfelt will gather a list of HTTPS related tickets.
    • Nexus and iPad flows. Tickets created for bugs found in existing flows. Volunteers needed! :)

    Today’s meeting agenda:

    • Status on additional flows/visual records and next steps toward ticket creation.
    • New thoughts/discussion on `WP_Network`, `WP_Site` and friends?
    • Status of #22383, #32434, and #32503
    • Open floor for tickets, thoughts, etc…

    Topic Details:

    Status on additional flows/visual records. Next steps toward ticket creation.

    chat log

    We have new flows captured. @kraftbj posted the Nexus 6 results and @earnjam will be posting iPad shots within the next couple days. @topdown volunteered to capture screens for Samsung Note 8 and possibly other devices as well.

    To date, our device list includes: Nexus 6, iPhone 5s, iPhone 6, and Desktop, with additional screens specific to network upgrade.

    We posted some info late last week on how someone could help test and capture the network admin UI. Test installations of multisite are available for anyone to use if you have a device but just have no way of accessing a multisite installation. Please leave a comment on the post or in #core-multisite if you’d like to get started.

    As we create tickets and find bugs, we need to populate this spreadsheet as part of the overall screen sweep effort.

    Objective for next week: New tickets to address found issues. These issues logged in the screen sweep spreadsheet.

    New thoughts/discussion on `WP_Network`, `WP_Site`, and friends?

    Tickets: #31985, #32450, #32504, #31148
    chat log

    Not much discussion here. @johnjamesjacoby is going to have iterations of `WP_Site` and `WP_Network` this week. We should have a chat in #core-multisite soon after.

    Objective for next week: Iterations on `WP_Site` and `WP_Network`. Discussion around iterations.

    Status of #22383, #32434, and #32503

    Tickets: #22383, #32434, #32503
    chat log

    Objective for next week: Let’s cross our fingers that these are closed by tomorrow.

    Other items:

    Tickets: #14172, #32602
    chat log

    • @jeremyfelt still needs to generate discussion around HTTPS for #14172
    • @ipstenu found an issue with the plugin details modal when viewing plugin details on a sub site that has a different domain/scheme from the network admin. The switch to `network_admin_url()` that causes this came in #17902. A new ticket #32602 is open.

    Thanks everyone!

  • Jeremy Felt 6:08 am on June 3, 2015 Permalink

    Multisite Office Hours Recap (June 2, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    Today’s chat log

    Overall 4.3 Release Objectives

    Last week’s objectives for dev chat:

    • Wrap-up #22383, #32434, and #32503 and then take a look at the add site flow and validation in `update_blog_details()`.
    • Continued progress on `WP_Network`, `WP_Site`, `WP_Network_Query`, and `WP_Site_Query`.
    • More thoughts on tracking scheme in `wp_blogs` for sites. #14172
    • More flows and network admin UI tickets from those flows.

    Today’s meeting agenda:

    • Status of #22383, #32434, and #32503
    • Status of `WP_Network` #31985, `WP_Site` #32450, `WP_Network_Query` #32504, and `WP_Site_Query` (likely #31148)
    • Tracking scheme for a site in `wp_blogs` is still looking for feedback, owner, etc.. #14172
    • More flows and network admin UI tickets from those flows.

    Topic Details:

    Arbitrary domain/path combinations in edit site:

    Tickets: #22383, #32434, #32503
    chat log

    • #32503, removing the home/siteurl mirror checkbox, is either ready to go in or very close. @jeremyfelt will take a closer look for commit.
    • #22383 is close, though the latest patch tracks scheme, domain, and path. We can leave scheme out for another ticket in the future. @earnjam is going to take another look, @jeremyfelt will also take a look for commit.
    • We talked through #32434 and decided to try using a URL (combined domain/path) column and converting the users column to a total count rather than a list of the first 5 users. @ocean90 is working on this.

    Objective for next week: Have all 3 of these tickets closed and committed.

    Progress on `WP_Network`, `WP_Site`, `WP_Network_Query`, and `WP_Site_Query`:

    Tickets: #31985, #32450, #32504, #31148
    chat log

    We chatted through the approach we’re using with `WP_Network` and `WP_Network_Query`. @johnjamesjacoby built the first patch by pulling most current network related code into the `WP_Network` class with the intent to break pieces out into `WP_Network_Query` once we have more of a handle on things. @jacobsantos had some good feedback on possible design approaches as he’s seen some common looking patterns/properties in `WP_Widget` and `WP_Customizer`.

    Objective for next week: Additional iterations on `WP_Network` and `WP_Network_Query`.

    Tracking scheme for a site in `wp_blogs`:

    Tickets: #14172
    chat log

    @johnjamesjacoby had some good concerns about possible approaches with tracking scheme. We’d like to generate a larger conversation around this topic. A few specific questions are:

    • Things that the current code prevents or prohibits. Or what does/doesn’t work in core now.
    • Exactly how capable do we want this to be.
    • Does the oncoming “TLS everywhere” of HTTP/2 change this discussion?
    • What concerns are there around introducing a new field on `wp_blogs`. How are large networks affected?

    Please leave any thoughts in the comments here or directly on the ticket.

    Objective for next week: Generate discussion. @jeremyfelt will gather a list of HTTPS related tickets.

    Network Admin UI flows for Make/Flow:

    chat log

    @ubernaut added many iPhone 5s flows, so we’re up to a handful now. @kraftbj is going to do Nexus flows and @earnjam is going to handle iPad.

    Objective for next week: Nexus and iPad flows. Tickets created for bugs found in existing flows. Volunteers needed! :)

    Thanks everyone!

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
Skip to toolbar