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 21: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

  • Andrew Nacin 7:35 pm on April 1, 2015 Permalink |
    Tags: 4.3, 4.4,   

    Release leads for WordPress 4.3 and 4.4 

    Since WordPress 3.5, we’ve had a rotating release lead. Because of the ever-present demands of the current release’s development cycle, we’ve found it tough to make these appointments well in advance. We’ve always wanted to give leads opportunity to prepare, so they can hit the ground running. (Long term, we’d love for release development to overlap pretty significantly, aided primarily by feature plugin development, but also by branching.)

    A release lead determines all important parameters for a release, like schedule, deadlines, which feature plugins are merged; and more generally, scope, goals, vision, and process. They take point when it comes to holding meetings, shepherding contributions, and writing announcement posts and updates. A release lead is a connector and facilitator, identifying bottlenecks and friction wherever they may be. They’re in frequent communication with the developers and plugin teams that are aiming to have something in a given release. The release lead follows what’s being committed, and sets the tone for prioritizing and gardening tickets. Given the constraint of time in hitting deadlines, help with prioritization and ensuring good communication lines are two of the most valuable things a lead can contribute.

    Today, I’m excited to announce release leads for both WordPress 4.3 and 4.4.

    Konstantin Obenland will lead WordPress 4.3, currently planned for August. Many of you may know @obenland (twitter) from his early work on default themes, but his contributions span across WordPress core. More recently, he shipped the new WordPress.org theme directory. Obenland is a native of Germany and lives in southern California. He’s a code wrangler at Automattic, which donates all of his time to WordPress core and WordPress.org.


    Scott Taylor will lead WordPress 4.4, due at the end of the year. A committer since 3.7, @wonderboymusic (twitter) has been plowing through major changes to media and pretty much everything else he can get his hands on. Scott is a Tennessee native and lives in New York City. He’s a senior software engineer on the interactive news team at The New York Times.


    You’ll hear from both of them in the coming days and weeks as they start to plan out their releases, including potential features, deputies, and strategies. Congratulations 🎉 and best of luck to both!

    Not an April Fools’ joke.

  • Drew Jaynes 6:05 pm on April 1, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda, April 1, 2015 

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

    • Beta 3 was tagged last week as scheduled and we’re heading toward tagging Beta 4 this week.
    • The soft string freeze is targeted to coincide with tagging Beta 4 this week, so we need to wrap any tickets with string changes (save for the About page).

    Time/Date: Wednesday 21:00 UTC 2015:

    DST reminder: The dev chat time has moved up an hour to 20:00 UTC following the European DST change.


    1. Congrats if you got ’em for @obenland and @wonderboymusic, release leads for WordPress 4.3 and 4.4!
    2. Task/Enhancements Review [List]
    3. String Ticket Scrub [List]
      One string:

      • #29958 – collapse menu keyboard accessibility
      • #31233 – Dismissable admin notices
      • #31769 – Prevent navigating away while plugins are updating via shiny updates
      • #31836 – Press This: Clean up text on tools.php

      Two or more strings:

      • (2) #31144 – Options general screen, accessibility improvements
      • (2) #31770 – Better feedback after bulk updating plugins via shiny updates
      • (3) #31722 – Shiny Updates: the aria-label should be updated to reflect the current status

      Various string changes:

      • #26600 – Search installed themes input has no submit button – New help text, one string split into two, new strings
      • #31832 – Add an Emoji section to the Help tab on post edit screen – New help text, replaced string
      • #27115 – HTTPS links to wordpress.org – Strings adjusted for links, may not need re-translating

    No Open Floor this week – Due to time constraints, we won’t be holding an open floor period during the regularly-scheduled dev chat this week. If you have a ticket on the 4.2 milestone you’d like to get dev feedback on, leave a note in the comments.

    Testing Stages Progress
    • Beta 1
      • Punt/convert all non-essential enhancements to tasks
    • Beta 2 (120 tickets on Report 6)
      • Get first run of FTP credentials modal in trunk
    • Beta 3 (90 tickets on Report 6)
      • Start finishing up tickets with string changes
      • Start About page
    • Beta 4 (50 tickets on Report 6)
      • Soft string freeze (all string changes completed save for the About page)
      • Start finishing up the About page
    • RC 1 (0 tickets on Report 6)
      • About page finished
      • Hard string freeze
  • Drew Jaynes 3:10 pm on April 1, 2015 Permalink |
    Tags: ,   

    This Week in 4.2: March 30 – April 5 

    This is the jump-start post for the eleventh week of the WordPress 4.2 release cycle. Posted just a little bit late this week, sorry folks.

    We entered the Beta 3 stage of development last week. We need to wrap up any tickets with string changes and transition to Beta 4 this week.

    Thrice-weekly scrubs will continue this week on Tuesday, Wednesday, and Friday using Report 6.

    Core Meetings this week:

    Core meeting times have been adjusted following the DST change in Europe over the weekend. No joke!

    Priorities this week:


    • Committers: please take a look at the list of tickets you own. Many of those tickets are simply waiting for you to follow up on commit or patch feedback and are stalled without it.
    • #31794 – Theme Switcher: Improve mobile experience – Needs a patch based on feedback


    • #30468 – wplink modal accessibility
    • #31722 – Shiny Updates: the aria-label should be updated to reflect the current status
    • #31233 – Dismissable admin notices
    • #26601 – Inappropriate content in headings on admin screens

    Make Flow:

    • #29906 – Submenus can’t be dismissed on mobile.
    • #31611 – Scroll bleed in the attachment details modal on iOS
    • #31609 – Scroll bleed through and scroll position loss in the view plugin details modal on iOS
    • #31612 – Scroll bleed in the link modal on iOS

    Recent posts seeking feedback

    Notable updates from the last week:

  • Daniel Bachhuber 1:30 pm on April 1, 2015 Permalink |
    Tags: meetings, ,   

    Shortcake (Shortcode UI) has a weekly meeting time: Mondays at 7 pm UTC 

    The title says it all. Our next weekly meeting is Monday, April 6 at 19:00 UTC

    We also have a channel on Slack. Come join us in #feature-shortcode

    Shortcode-curious? Check out this recent WP Tavern post for the details on our latest release.

  • Drew Jaynes 5:20 pm on March 31, 2015 Permalink |
    Tags: dst   

    Reminder: Core meetings move up an hour starting this week (DST) 

    Following the Daylight Saving Time change in Europe over the weekend, all core meeting times will move up an hour, bringing those in North America and surrounding areas back in sync with those in Europe.

    Contributor team and development meetings are held in Slack.

    Updated Meeting Times

    What Where When Was (UTC)
    4.2 Core Bug Scrub #core Tuesday 15:00 UTC 16:00
    4.2 NUX Working Group #core-flow Tuesday 18:00 UTC 19:00
    Multisite Weekly Chat
    Starting April 7th
    #core-multisite Tuesday 19:00 UTC 20:00
    4.2 Core Bug Scrub #core Wednesday 16:00 UTC 17:00
    Core Dev Chat #core Wednesday 20:00 UTC 21:00
    Dashicons Weekly Chat #design-dashicons Thursday 17:00 UTC 18:00
    4.2 Core Bug Scrub #core Friday 15:00 UTC 16:00
    Customizer Component Weekly Chat #core-customize Friday 18:00 UTC 19:00
    • Samuel Wood (Otto) 1:51 pm on April 1, 2015 Permalink | Log in to Reply

      I edited your post to remove the time shortcode, as it wasn’t able to parse those times and was showing incorrect information. Hope you don’t mind.

      When using the time shortcode, it only works for specific date/times, not recurring ones. “Tuesday 15:00 UTC” is not specific enough for it to figure it out so it was displaying the wrong thing..

  • Ryan Boren 5:01 pm on March 31, 2015 Permalink |
    Tags: ,   

    We must be our own beta audience. 

    Using the beta tester plugin, I follow trunk through every phase of development via five devices (iPhone 5, iPhone 6+, Nexus 5, iPad Air, Macbook). With the plugin installed, select “Bleeding edge nightlies”. Every day, your site will auto update to the latest nightly build. We committed long ago to ensuring that trunk is continuously dogfoodable and quickly fixed in the rare event that something nasty happens, like a fatal error. I have never once experienced loss of content while following trunk.  If you follow this blog, consider putting the beta tester plugin on a real site that you use regularly. We must take this small extra risk with our own sites so that we truly see what we’re making before releasing it.

    We desperately need mobile beta testers. WordPress will be a champion of the open mobile web. We will work around the iOS Safari bugs that hamper us. We will make the mobile web a better place. With the beta tester plugin installed on a public site, testing betas from any touch device is as straightforward as testing from the desktop. Despite this ease, 4.2 in its current state is a regression from 4.1 on mobile, particularly on iOS. We’ll work through these problems before release, but we really need mobile beta testers as well as mobile patch testers. Mobile patch testing (and patch testing in general) is not so easy to set up. We need better tools and documentation here.

    Check out the Beta Testing section of the Core Development Handbook for help setting up the Beta Tester plugin. I’m always hanging out in the #core-flow Slack channel as @boren if you have questions. Let’s build a mobile beta audience.

    • Shapeshifter 3 6:26 pm on March 31, 2015 Permalink | Log in to Reply


      I agree with the direction you are going with this and have been using the Beta Tester Plugin myself for over 1 1/2 years. The possible stumbling block you are going to run into (from non-developers), is the perceived reaction that they will not receive response from the plugin’s developer when forum requests are posted. Maybe more Core Developers could add that agenda to their current schedules. Here’s an answer that I provided to a frustrated user back some time ago: https://wordpress.org/support/topic/what-the-4?replies=2#post-

      I myself still continually use the plugin, but it would be nice to have more frequent, current responses to questions.

      • Ryan Boren 6:47 pm on March 31, 2015 Permalink | Log in to Reply

        Indeed. The beta tester plugin needs reinvigoration and support. I’ll find a developer to adopt it, update the tested up to version, and breathe a sign of life into it.

  • Aaron Jorbin 3:52 pm on March 31, 2015 Permalink |
    Tags: ,   

    Screen Reader Text in output of comments_popup_link 

    As of WordPress 4.2, the output of comments_popup_link now uses .screen-reader-text in themes using the default strings in calls to comments_popup_link. The accessibility team has put together a post on hiding text for screen readers that includes sample code to use in your themes.

    I recommended that all themes include the .screen-reader-text class. This change was announced by the on the theme team blog in January. In the future, there may be more changes to output that relies upon the presence of the .screen-reader-text class.

    Related Ticket:

  • Pascal Birchler 9:48 am on March 28, 2015 Permalink |
    Tags: ,   

    WordPress Core Weekly 

    Hi Everyone!

    It’s time for another run-down of what’s going on in WordPress core. This edition covers March 20, 2015 [31845] through March 20, 2015 [31915].

    If you want to write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

    This week’s highlight is WordPress 4.2 Beta 3, which was released on Thursday. There were many accessibility and emoji improvements and bug fixes. Also, shiny installs functionality was removed.


    • Improve newly added strings for i18n. [31905] #31776
    • Remove <code> tags from translatable strings. Uncomment deprecation notice for get_bloginfo( 'text_direction' ). [31899] #30614


    • Theme Switcher: Opening themes details modal shouldn’t require two clicks on touch devices. [31914] #31794
    • Theme Switcher: Reset font size of theme names in overlay. Apply left position only to themes section. [31892] #31303
    • Theme Switcher: Don’t hide action buttons on narrow screens. [31912] #31794
    • Use proper preview URL for Live Preview links. [31911] #31782
    • Avoid SecurityErrors when the Customizer is embedded in an origin other than wp-admin. [31885] [31893] #31687
    • Use responsive button styles if screen is max-width 640px. [31913] #31794, #28784


    • [31864] changed emoji image’s inline style from height to max-height. Unfortunately, anything using feedparser.py (for example, NewsBlur) strips out max-height, which gives us massive emoji in feeds. This re-adds height, and also reminds us why we can’t have nice things. [31909] #31719
    • When we’re replacing emoji with <img>s in email, we can only do that if the Content-Type is text/html – otherwise, they’ll show up in the email as the HTML string. [31860] #31720
    • Instead of loading the emoji JS files automatically, we now include a small JS shim in the header, to test if the user’s browser needs Twemoji. It then loads the emoji JS files only if they’re needed. [31875] [31877] [31879] #31701
    • Set the emoji image protocol with set_url_scheme(), instead of defaulting to HTTPS. [31861] #31735

    Press This

    • Remove role="application" from the Categories list wrapper. This doesn’t make it work better in screen readers. [31907] #31443
    • On sites that support oEmbed, if the user has selected some text, quote it below the embed. [31894] #31763
    • Fix the links on inserted images to point to the source site. Fix inserting of images above the blockquote when the editor has not been focused. [31868] #31745



    • Remove ambiguity in the time display format in core, switches to using 24hr notation where am/pm isn’t specified. [31862] #31121
    • Comments List: Don’t let “Quick Edit” break on smaller screens. [31889] #31482
    • Admin menu: Revert [31720] for swipe open/closed. This is problematic on any device that uses swipe for history navigation, particularly iOS. [31910] #31187
    • Do not output empty name and id HTML attributes in get_submit_button(). [31880] #31749
    • When altering the admin URL to reflect the canonical location, keep the existing hash (if present) in the URL. [31882] #31758, #23367
    • WordPress 4.2-beta3 [31902] [31903]


    • When saving post, ensure that non-hierarchical taxonomy input is defined before attempting to parse it. [31895] #30859
    • Taxonomy List Tables: On mobile devices, hide the slug column, to avoid cramping the action links into two rows. [31865] #29992
    • Supplement hook documentation for the get_terms_fields filter to more clearly explain the expected consequences of using it to modify the fields to select in a terms query. [31855] #31174


    • Make sure the editor is not completely empty before checking if the user clicked above or below a wpView. [31888] #31765
    • Pad empty paragraphs with <br> in Chrome to stop it from inserting non-breaking spaces in them. [31878] #31255
    • Fix error and PHP warning when adding more than one instance in RTL mode. [31874] #31578
    • Fix the icon for the wp_code button. [31858] #31733
    • When pasting an URL, check if the node it is pasted at is empty and remove any empty inline child elements. [31856] #31158

    Script Loader

    • Avoid a PHP notice in wp_enqueue_script() if $handle is an array. Calling wp_enqueue_script() with an array as the first argument is a “hidden feature” and should be avoided. Use dependencies instead. [31887] #31636, #14488


    • Text Widget: Use !empty() for checking if the filter setting is set. [31886] #31690
    • Trigger _doing_it_wrong() if register_sidebar() is not passed an id. [31850] #31675

    Login and Registration

    • Implement an aria-describedby attribute for login screen errors, and improve the “Forgot password?” anchor text. [31871] #31143


    • Introduce attachment_url_to_postid filter to let plugins manage the uploads location better. [31867] #31717
    • Show filename instead of extension in the list table. [31857] #30943

    Bundled Theme

    • Update editor styles to better display images and captions in small screens. [31849] #31250

    Build/Test Tools

    Thanks to @A5hleyRich, @afercia, @aferica, @atimmer, @azaozz, @boonebgorges, @Cheffheid, @dd32, @dkotter, @DrewAPicture, @ericlewis, @extendwings, @HarishChaudhari, @helen, @ianmjones, @iseulde, @jacklenox, @janhenckens, @johnbillion, @johneckman, @jorbin, @kraftbj, @lamosty, @lancewillett, @magicroundabout, @maimairel, @markjaquith, @mattheu, @mattwiebe, @MikeNGarrett, @nerrad, @obenland, @ocean90, @pento, @ramiy, @rianrietvel, @SergeyBiryukov, @sorich87, @stephdau, @swissspidy, @tschutter, @tyxla, @valendesign, @valendesigns, and @westonruter for their contributions!

    • Piet Bos 10:27 am on March 28, 2015 Permalink | Log in to Reply

      There is another open ticket for Emojis and that is #31651 with the request to switch the CDN from the .com domain to the .org domain

  • Drew Jaynes 4:00 pm on March 25, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda, March 25, 2015 

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

    » Beta 2 was tagged last week as scheduled and we’re heading toward tagging Beta 3 this week.

    Time/Date: March 25 2015 21:00 UTC:

    Reminder for those on Daylight Saving Time – If you’re already on Daylight Saving Time, the core dev chat will be an hour later for you until next week, though still 21:00 UTC. The above time link should give you the correct time and date for your local timezone.


    1. Decisions
      • Shiny Updates: Auto-activation behavior
      • wpLink modal: Behavior for working links lacking source text
      • Pursue or Punt: #26601 – Inappropriate content in headings on admin screens
      • About page highlights
      • Make/Core Posts – Ideas: Schema change, query class changes, TinyMCE views changes, twemoji front-end loader, update on HTML5 widgets revert, etc.
    2. Upcoming Milestones overview
      • Beta 3 (90 tickets on Report 6)
        • Start finishing up tickets with string changes
        • Start About page
      • Beta 4 (50 tickets on Report 6)
        • Soft string freeze (all string changes completed save for the About page)
        • Start finishing up the About page
      • RC 1 (0 tickets on Report 6)
        • About page finished
        • Hard string freeze
    3. Open Floor – Looking for dev feedback on a ticket? Use this part of the meeting to let us know!
    • Aaron Jorbin 5:03 pm on March 25, 2015 Permalink | Log in to Reply

      RE: Shiny Updates –

      24 hours ago I wouldn’t be advocating this, but there are a couple of really good reasons that we shouldn’t do auto-activates.

      1) Plugins that require after activation steps (such as connecting for jetpack or google analytics, updating permalinks for buddypress, etc) aren’t obvious. We need a way for plugins to provide a notice upon activation of next steps
      2) Since the menu isn’t updated, users still need to do a page refresh in order for the changes to actually go in affect and for them to utilize the features of many plugins.
      3) There are plugins such as maintenance mode ones that users will not want to be activated right away.

      I really like the idea of auto-activating since I think it helps to discourage users from having code that isn’t actually being used from being on the server and also saves the user a step, but in reality, they aren’t saved a step.

      We have at least two options for what to do instead.

      1) We remove shiny installs from the release. This is fairly easy to do as we just need to remove the js bindings on that page and remove the ajax actions. Since much of the infrastructure code is in place now, I think that it’s possible to continue development of shiny installs in a plugin. This would enable us to work on things such as:

      • Adding the ability for plugins to register “notifications” for users on what they need to do after installing.
      • Add the ability for plugins to “opt-out” of auto installs
      • Work on adding in menu items or at least a link to a plugins setting screen.

      2) Turn off auto-activation and instead do some UI changes when a user installs a plugin. I’m thinking a notice banner inside the plugin card giving the option to activate. This can either be a shiny (ajax) activation or a traditional activation. We also could change the “install” button to be “activate”.

      At this point, I recommend option 1. Shiny updates is still a solid MVP and a win for the users. It also sets us up for some bigger wins down the rode.

      • Eric Lewis 5:21 pm on March 25, 2015 Permalink | Log in to Reply

        I’m in favor of option 1 as well. It’s late in our release cycle to be making user-facing decisions that bear such heavy impact.

        Shiny Updates is a great improvement, let’s focus the rest of our effort there and follow-up on Shiny Installs later.

      • Gary Pendergast 10:47 pm on March 25, 2015 Permalink | Log in to Reply

        I’m strongly in favour of option 1. Providing an Activate option gives us one of two problems:

        • If it’s a Shiny Activate, it’ll have most of the same problems we’ve run into with auto-activate.
        • If it directs to the old activate screen, it’ll interfere with currently running Shiny Installs, and probably other things.

        I’m also in favour of seeing if we can turn this into a plugin. I think the Shiny Updates dev process has well and truly shown that the trunk dev model is totally broken.

      • Shailesh 9:14 pm on March 26, 2015 Permalink | Log in to Reply

        What if we convert Install button in Activate It after plugin is downloaded?
        If user click on activate button, page will open in new window something like target=”_blank”. So current other progress will not affected.

        Same for already activated plugins. We can put Deactivate It button and onclick we can deactivate it in new window.

      • Chuck Reynolds 2:31 am on March 27, 2015 Permalink | Log in to Reply

        agreed. glad the auto-activation was stopped.
        Something to consider going forward… a filter to disable the auto-activate after install.

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