Make WordPress Core

Welcome to the official blog of the core development team for the WordPress open source project.

Here, we make WordPress core. Follow our progress with general updates, status reports, and the occasional code debate.

We’d love for you to help out.

Looking to file a bug?

It’s easy to create a ticket on our bug tracker.

Want to contribute?

Get started quickly. We have some tickets marked as good first bugs for new contributors. There’s more on our reports page, like patches needing testing.

We also have a detailed handbook for contributors, complete with tutorials.

Weekly meetings

We use Slack for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day.

We have a project meeting every Wednesday at 20:00 UTC in the #core channel on Slack. (Find out more about Slack.)

You can find meeting agendas on this blog. You’re welcome to join us or listen in.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Daniel Bachhuber 7:46 pm on June 29, 2015 Permalink |
    Tags: , ,   

    Shortcake (Shortcode UI) chat summary – June 29th, 2015 

    Present: @danielbachhuber, @samuelsidler, @matth_eu

    • Sam shared with us the possibility of getting Shortcake committed to WordPress core. While he can’t make any guarantees, this is the direction he suggested:

      • Better first-run experience with the plugin so people can evaluate it better. He recommends adding a few “example” shortcodes, and mention that they’re examples / not to be included in core. Pull quote and PDF could be a good start.
      • Decide on the appropriate UX for inserting new shortcodes. The experience is currently tucked away under “Add Media”. We’ve been exploring a “Add Post Element” button alongside “Add Media”, or dedicated buttons in the editor for some post elements.
      • Inline editing would be really nice. We should see if we can make it the default experience for most shortcodes, and all existing core shortcodes. We should also experiment with content blocks, and see what other editors are doing.
    • Matt lost his internet, so we didn’t talk about any code things.

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1435604506000006

    Next chat: same time and place

    Next release: v0.5.0 – Tuesday, August 4th

  • Simon Wheatley 4:43 pm on June 29, 2015 Permalink |
    Tags: localisation, multilingual, translation   

    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.

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

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

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

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

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

  • Konstantin Obenland 11:30 am on June 29, 2015 Permalink |  

    This week in 4.3: June 29 – July 5 

    This is the jump-start post for the ninth week of the WordPress 4.3 release cycle.

    Beta1 is happening this Wednesday. I’ll start moving enhancement tickets out of the milestone that have not made it in until then before dev chat. We should then be ready to tag after the chat.

    Priority Tickets this week:

    Core Meetings this week:

    4.3 Feature Chats this week:

  • designsimply 10:47 pm on June 27, 2015 Permalink |
    Tags: call for testing, , , needs testing   

    Call for Testing: Customizer Menus 

    First, thank you so much if you help out by taking the time to test new features!

    Customize > Menus will be one of the new features in WordPress 4.3. It is being added in addition to the Appearance > Menus page and the Appearance > Menus page will not be changed as part of the new feature.

    How to Setup for Testing

    1. Always backup first or test on a site that was made for testing (see warnings below).
    2. Go to Plugins > Add New and search for “WordPress Beta Tester”
    3. Click the “Install Now” button for the WordPress Beta Tester plugin
    4. Go to Tools > Beta Testing
    5. Select the “Bleeding edge nightlies” option
    6. Click the “Save Changes” button
    7. Go to Dashboard > Updates
    8. Click the “Update Now” button

    You should see the a message similar to this in the footer in wp-admin pages:
    “You are using a development version (4.3-alpha-123456).”


    How to Test Customizer Menus

    Test creating menus including adding, removing, and editing menus. You may just poke around and test on your own to see if you can find any bugs, or you can use the following checklist as a guide:

    Before you begin:

    Sample testing checklist (time estimate: ~20 minutes for new users):

    1. Make sure you have installed the latest nightly WordPress release (see setup steps above).
    2. Go to Appearance > Customize and then click on Menus.
    3. Add a new menu named “Main Menu.”
    4. Add all of the pages already saved on the site to the menu.
    5. Save the changes you’ve made so far, exit the Customizer, then navigate back to the menu you just created in the previous step.
    6. Set the “Main Menu” as the primary menu so it shows in the live preview.
    7. Reverse the order of the menu items.
    8. Add the “Travel” category to the menu.
    9. Move “Travel” so it is a child of the first item in the list.
    10. Add a link to Twitter and make it a submenu item next to Travel.
    11. Move Travel and Twitter from the first item so they are submenu items under the About page. Save changes.
    12. Create a new menu for social media with at least one social media link in it and find a way to make it show up in the live preview on the right.
    13. There is a way to use advanced menu settings to enable descriptions for menu items. Try to find it and add a description for the “About” page.

    Other testing ideas:

    1. Test using a very large menu with a lot of items. (Also see #32769.)
    2. Test using a menu that is 10 levels deep.
    3. Test with various themes and other types of menus.
    4. Comment on this post with any other testing ideas!

    If you want to dig in deeper and get involved with usability testing with others, that would be so cool! Please comment on this post or in the #core-customize Slack channel if you’re interested in doing more.

    What to Look For

    Look for blockers! A blocker is a very bad bug that blocks people from using the feature. At this stage, the biggest problems are the top priority and you should look for those first and foremost. Be aware of the known issues (see below).

    If you do find a bug, report it in Trac or ask about it in the #core-customize Slack channel.

    Known Issues

    Here are a few key issues still being worked on:

    /cc @jimmysmutek @lisaleague @kevinwhoffman @dinamiko
    (because you expressed interest in helping with testing somewhere along the way) :)

  • Jeremy Felt 4:47 pm on June 24, 2015 Permalink |

    Multisite Office Hours Recap (June 23, 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 (and this week’s) objectives:

    • More flow, more tickets, more observations to aid with Network Admin UI improvement.
    • Get a good patch up for #31240, possible commit.
    • Ongoing iterations, progress, discussion on `WP_Network` and `WP_Site` (and friends).
    • Write post, generate discussion around HTTPS in multisite for real (lower priority).

    It was a super light weight week for multisite, so not much progress. There was some traffic on existing tickets, but not much new activity. Summer lull… 🌞

    @hugobaeta gathered a few UI/UX tickets for WCEU contributor day – #32525, #32645, and #32647. We also have the general Admin UI screen sweep spreadsheet. Another ticket in that vein via @johnjamesjacoby is #32754, which is a string change but goes along with UX.

    If anyone has other UI/UX tickets, please make note. I’ll be poking around on Saturday. For anyone attending WCEU contributor day, a server with multisite is available for you to test on. I’ll hook some others up with super admin access beforehand.

  • Konstantin Obenland 1:15 pm on June 24, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for June 24 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    Time/Date: June 24 2015 20:00 UTC:

    1. Feature Updates
      1. Admin UI – @helen
      2. Menu Customizer – @westonruter
      3. Passwords – @markjaquith
      4. Site Icon – @obenland
    2. Component Updates
    3. Open Floor

    Feature Leads: Let’s review last weeks goals and set new ones for next week.

  • Daniel Bachhuber 8:27 pm on June 22, 2015 Permalink |
    Tags: , ,   

    Shortcake (Shortcode UI) chat summary – June 22nd, 2015 

    Present: @danielbachhuber, @goldenapples, @davisshaver

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1434999676000006

    Next chat: same time and place

  • Konstantin Obenland 7:01 am on June 22, 2015 Permalink |
    Tags: ,   

    This week in 4.3: June 22 – 28 

    This is the jump-start post for the eighth week of the WordPress 4.3 release cycle.

    Beta1 is only one week away.

    Priority Tickets this week:

    Core Meetings this week:

    4.3 Feature Chats this week:

  • Konstantin Obenland 8:56 am on June 17, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for June 17 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    Time/Date: June 17 2015 20:00 UTC:

    1. Feature Updates
      1. Admin UI – @helen
      2. Menu Customizer – @westonruter
      3. Passwords – @markjaquith
      4. Site Icon – @obenland
    2. Component Updates
    3. Open Floor

    Feature Leads: Let’s review last weeks goals and set new ones for next week.

    [EDIT]: Please test https://wordpress.org/plugins/wporg-site-icon/ in preparation for today’s chat.

  • Jeremy Felt 9:20 pm on June 16, 2015 Permalink |

    Multisite Office Hours Recap (June 16, 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:

    • New tickets to address found issues in flow. These issues logged in the screen sweep spreadsheet.
    • Iterations on `WP_Site` and `WP_Network`. Discussion around iterations.
    • #22383 and #32503 committed.
    • Write post, generate discussion around HTTPS in multisite.

    Today’s meeting agenda:

    • Progress on capturing, observing, ticketing flows.
    • Next steps to combined domain/path UI – Add New site flow #31240
    • `WP_Network`, `WP_Site` progress – @jjj
    • Open floor for tickets, thoughts, etc…

    Topic Details:

    Progress on capturing, observing, ticket flows:

    Tickets #32647, #32645, #32643, #32644
    chat log

    • @earnjam added iPad flows.
    • @sharonaustin captured a bunch of flow data/notes and will be posting it to Make/Flow soon.
    • Some great progress was made over the weekend during the WCPHL contributor day. #32643 was opened and committed as an example of the process. #32644, #32645, #32646, and #32647 were also opened.
    • @earnjam is going to take the lead on getting #32647 and #32645 ready for next week as part of a My Sites overhaul.
    • The bugs from #32643, #32644, and #32646 are likely found in other places throughout core as well.
    • We should collaborate on a flow/design/admin ui/network admin ui contributor doc for WCEU with some basic “here’s what we need” guidelines. @helen @boren @sheri

    Objectives for next week: #32645, #32647 committed. More flow, more tickets, more observations. :)

    Next steps to combined domain/path UI

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

    • #22383, #32434, #32503 are all committed and closed. 👍
    • Originally #31240 seemed kind of off the table for 4.3, but it seems very possible now. @jeremyfelt will take a shot at getting that prepped for next week.
    • Once these are both in, we should start having some validation questions pretty soon.

    Objective for next week: Patch and/or commit for #31240.

    Progress on `WP_Network`, `WP_Site`

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

    • @earnjam is going to open a ticket to track `WP_Site_Query` and take a stab at that.
    • We need to iterate some more on the other existing patches.
    • Completely comfortable with progress on this continuing through 4.3 for a target of 4.4 early. It would also be nice just to get it in now. :)

    Objective for next week: Iterations, progress, discussion.

    Other items:

    • @jeremyfelt owes an HTTPS in multisite post still. Maybe by tomorrow?
    • No other items. A pretty quiet chat today.

    See you next week!

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