Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Aaron Jorbin 2:40 pm on September 15, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: September 14 (4.7 week 4) 

    This post summarizes the dev chat meeting from September 14th (agenda, Slack archive).


    As of this meeting, we are 5 weeks from the final deadline to merge major features.
    There are a lot of tickets in the milestone and owners / people who milestoned them need to make sure they are active and moving, or else punt. You can use this report see tickets in the milestone grouped by who moved it there:https://core.trac.wordpress.org/report/61.

    Components and features

    Twenty Seventeen (@davidakennedy, @melchoyce)

    Make sure to checkout both the Announcement post and the latest update. There is no formal meeting this week. Development has started on GitHub. Like many feature projects, it will live on GitHub until it is ready to come into SVN (within the next 5 weeks).

    REST API (@krogsgard, @kadamwhite, @joehoyle, @rmccue)

    Core patches, documentation, and reducing the issue backlog have been the primary focuses. There is a settings registry up (https://github.com/WP-API/wp-api-site-endpoints/pull/13) with a corresponding core patch (https://core.trac.wordpress.org/ticket/37885).

    Feedback is needed on #37885.  Please take a look.

    #38056 is needed for password posts. (update: it has landed).

    The next dev chat is Monday September 19 1400 UTC.

    Media (@mikeschroder, @joemcgill)

    • Still looking for feedback/testing on #22744, but planning to commit soon.
      • If you have a large media library, your help in testing would be particularly helpful.
    • @paaljoachim continued researching UI flows in other platforms and posted a bunch of screenshots in #core-images.
    • Joe shared an outline of what we’re trying to accomplish longer term here in#core-images and would like to talk more about it design side of things during the #design meeting tomorrow, if possible.
    • Still waiting to hear back from folks who were involved in starting up the Core Media Widget #32417 work, but travel has been an issue. Hopefully we’ll have a better update there next week.

    Customize (@westonruter, @celloexpressions)

    • @boone is thinking about/investigating ⁠⁠⁠⁠term_status⁠⁠⁠⁠ for #38015. We have some time to think about it, and could potentially use shadow/draft taxonomies as a workaround for #38014 in 4.7 if needed.
    • tracking the ability to add page stubs or create pages directly from the static front page controls along with this project to facilitate creating pages for initial site setup within the customizer. @westonruter is leading the way on #38013.
    • #34391 is a significant refactoring of code that themes and plugins are encouraged to extend. A corresponding make/core post will follow soon after.
      • Already working with some plugin, theme, and framework authors to minimize breakage.
    • We need some feedback now on #35395 – Custom CSS – @johnregan3 is making great progress.  Please check out the ticket.

    i18n (@swissspidy)

    • #29783 (User Admin Language): in good shape, but not much testing happening so far. We could do much more when #26511 is in core though…
    • #26511 (switch_to_locale()): needs some much needed performance testing. If anyone runs a large WordPress site, I could use your help!
      Also since there are some similarities with switch_to_blog(), I’ll open a new ticket to suggest adding a WP_State interface for such switching functions. Think WP_Site_State, WP_Locale_State, WP_Post_State (see #19572), etc. Not a blocker, but worth keeping in mind for future compatibility.
    • #20491 (JS i18n): I documented the current state in the tasks with responsibilities etc. As of tomorrow I’ll have more time to work on it (mainly on the GlotPress side of things). Also have been thinking about a switch_to_locale() function in JS via Ajax…

    Editor (@azaozz, @iseulde)

    • Post your wishlist items for the editor.

    HTTPS (@johnbillion)

    • Plan of attack for HTTPS work will be published on Make/Core.

    Open floor for tickets and any lingering 4.7 ideas.

    Please review and comment on these tickets:

  • Mike Schroder 1:53 pm on September 15, 2016 Permalink |
    Tags: , ,   

    Media Weekly Update (September 9) 

    This post summarizes the most recent media meeting, which takes places weekly in #core-images on Slack.

    Our next meeting is Friday, September 16 at 19:00 UTC and the agenda for these meetings include moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    It was brought up that the current meeting time is not great for @swissspidy or @flixos90, and they’d prefer to meet earlier, which we would start next week at Friday, September 23 at 17:00 UTC or alternatively on Thursday, September 22 at 17:00 UTC. Please sound off in the comments as to whether you’d be able to make either of the above to help decide on whether the meeting time will change.

    Agenda for the next meeting

    This week, we will check in on the priority projects for the 4.7 release. If you have specific tickets that you’d like to have discussed, please leave a comment on this post or reach out on Slack in the #core-images channel.

    Recap of the last meeting

    Our last meeting was Friday, September 9. You can read the conversation log in #core-images on Slack.

    Attendees: @mikeschroder, @markoheijnen, @flixos90, @adamsilverstein, @swissspidy, @paaljoachim, and @achbed.

    Media library organization improvements

    • @joemcgill and @swissspidy are working on adding the ability to search the media library by filename (#22744).
    • Following the meeting, @joemcgill posted some great notes on his thoughts regarding process for forming a roadmap for these improvements. You can read them on Slack.
    • Separately, we would like to engage members of the design team in initial conversations about what UI/UX improvements can be made to the media library to make it easier for people to organize and find their media. It’s likely that any UI changes in 4.7 would be relatively light, but we want to begin planning now and focus work during this release on getting as much infrastructure in place as we can.

    Improved full size image optimizations (#37840)

    Good conversation around ways to solve or work around the issue of increased CPU time/HTTP failures for image resizing.

    • Proposed closing #36534, and creating tickets from the issues found. It was great for gathering information, but has become a dropbox for all HTTP Error related tickets.
    • This is related closely to the full size image task because we want to avoid making the timeout issue worse when adding another resize.
    • In addition to running additional profiling to find what’s now taking the most time, one thing @joemcgill and @mikeschroder discussed in particular is a “try again” or “continue” button as a first jump into making it easier to recover when these failures happen. At the moment, this isn’t a thing because WP only saves meta after creating all sizes is completed successfully, and also because the code doesn’t support creating “the sizes that are left” (related: #15311).
    • @mikeschroder would also like to see investigation into making the HTTP Error more specific, but this could be part of the above project or solved without users needing to know the details, when WP can recover by itself.

    Core Media Widget (#32417)

    No Update. Reached out to @designsimply and @fab1en.

    HTTPS fixes

    No Update. Reached out to @johnbillion to see what plans are for 4.7.

    PDF Thumbnails (#31050)

    No time last week due to travel. @markoheijnen to send update this week.

    Accents in attachment filenames should be sanitized (#22363)

    @gitlost provided great feedback on the ticket (thanks!), but it looks like it’s going to need additional work before an initial commit.
    @mikeschroder looking into this with @markoheijnen at WC Tokyo this week.

  • Helen Hou-Sandi 5:25 pm on September 14, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for September 14 (4.7 week 4) 

    This is the agenda for the weekly dev meeting on September 14, 2016 at 20:00 UTC:

    If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

    • Pascal Birchler 6:11 pm on September 14, 2016 Permalink | Log in to Reply

      I might not be able to attend today’s dev chat, so here’s an update on i18n:

      #29783 (User Admin Language): in good shape, but not much testing happening so far. We could do much more when #26511 is in core though…

      #26511 (`switch_to_locale()`): needs some much needed performance testing. If anyone runs a large WordPress site, I could use your help!
      Also since there are some similarities with `switch_to_blog()`, I’ll open a new ticket to suggest adding a `WP_State` interface for such switching functions. Think `WP_Site_State`, `WP_Locale_State`, `WP_Post_State` (see #19572), etc. Not a blocker, but worth keeping in mind for future compatibility.

      #20491 (JS i18n): I documented the current state in the tasks with responsibilities etc. As of tomorrow I’ll have more time to work on it (mainly on the GlotPress side of things). Also have been thinking about a `switch_to_locale()` function in JS via Ajax…

    • Ronald Huereca 6:24 pm on September 14, 2016 Permalink | Log in to Reply

      I’d like https://core.trac.wordpress.org/ticket/38024 discussed as I believe it to be a fairly major bug in regard to automatic updates for plugins and themes.

  • Aaron Jorbin 3:27 pm on September 12, 2016 Permalink |
    Tags: ,   

    The Upcoming Week in 4.7: 12 September – 18 September 

    This is the jump-start post for the third week of the WordPress 4.7 release cycle. This release is off to a 🚀 start, and there are 5 weeks remaining for feature projects to be merged. 

    Priorities this week:

    #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call landed recently.  Please make sure to read the associated post and test.

    42 tickets currently milestoned for 4.7 need a patch or unit tests.

    A Media Widget is a commonly requested feature; get involved with #32417 if you would like to make it a reality.

    Core meetings this week:

    All meetings in the WordPress Slack #core channel unless specified otherwise.

    Things to do this week:

    • Nick Halsey 4:09 pm on September 12, 2016 Permalink | Log in to Reply

      Don’t forget about the weekly customize meetings on Mondays at 17:00 UTC in #core-customize (for 4.7). It’s on make/meetings, but missing from the sidebar and these posts.

  • Jeff Paul 2:24 pm on September 12, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: September 7 (4.7 week 3) 

    This post summarizes the dev chat meeting from September 7th (agenda, Slack archive).

    Update on 4.6.1

    Updates on Components and Features

    • Media via @joemcgill
      • #22744 – a few approaches on this ticket that are pretty close, but some feedback that would be helpful
        • To enable searching for filenames, we have to add a JOIN for the meta table, which has performance implications
        • so a) we could use more eyes/testing and b) I want to make sure we’re ok to add this if we limit it to only the media library
        • We have a couple approaches in patches. The latest limits it only to the media modal and WP_Media_List tables.
        • on a site with ~14k attachments and ~18k posts, this change increased the main query time from 60.7ms to 187.6ms
        • Plan is to drop it in for including titles in library searches and see how that goes
      • Looking for interest in getting the media widget started back up
        • @sheri has expressed interest and it seems like previous efforts got fairly close. Would love to see folks interested jump back onto that project during this release.
        • discussion will be in our weekly meeting in #core-images on Fridays at 19:00 UTC. There is a jump-start post so people can comment there or jump into the #core-images channel.
    • Customize via @celloexpressions
      • Two items needing review:
        • 1) ability to preview terms in the customizer, which would enable users to build menus incorporating their new taxonomy term structure on initial site setup in the customizer. See #37914 and #37915. We need to come up with a plan with those interested in the taxonomy component, and @boone in particular. First step there is to decide if we want to try to target 4.7 for first steps there.
        • 2) #37661 needs feedback. Working on a user testing plan together with @karmatosed soon. Looking for specific feedback or testing.
    • REST API via @krogsgard
      • Notes from Monday’s meeting
      • Calls for help would be participation in our next weekly meeting, 1400 UTC on Monday, and a bug scrub 1400 UTC on Thursday, both via #core-restapi
      • some in-flight work this week that’s being a bit delayed by the participation of Ryan and Joe in A Day of REST
      • We have big documentation needs in the v2 docs repo if anyone wants to play along, especially anybody who wants to set up a multi-language-code-snippet thing that we could use
      • meta and options are both moving well but we’ll need to start getting beyond theory and into code pretty soon
      • We really, really want to talk to component maintainers! It’s my job to reach out to you all, and you can also reach out to me (@krogsgard).
    • I18N via @swissspidy
      • #26511 (switch_to_locale()) and #29783 (User Admin Language)
        • Those are currently in development and after I upload new patches today/tomorrow, I’d love to see some testing.
        • Think of possibilities like: The admin bar is shown in Dutch while the rest of the site is shown in English.
      • #20491 (Introduce some JavaScript i18n functions)
        • We want to make translating strings in JavaScript files easier. Like in PHP files, one should be able to use gettext functions to translate strings. This involves changes to the translate.wordpress.org platform and therefore requires thorough discussion, planning, and testing.
        • After tackling this topic many times and attending the GlotPress meeting yesterday, it’s clear that it’s a task covering not just 1 release. Thus, we’ll likely have to do regular meetings here in Slack to get there.
    • Fields API via @sc0ttkclark
      • looking into slimming down our Fields API proposal into a MVP form for our core proposal
      • blocked by lack of time because i’m also lead organizing WCDFW this month
      • I could use lots of eyes on it, we want to identify anything that might be out of scope, as well as look into what our plan will be for the Javascript side of things for fields like the Media modal
    • #36964 (Show/hide the tag-cloud on `edit-tags.php` admin pages using a filter) via @ramiy
      • it has a patch, ready to be commited
    • #17817 (do_action/apply_filters/etc. recursion on same filter kills underlying call) via @ocean90
      • Landed!
    • #37198 (Use `WP_Term_Query` for `wp_get_object_terms()`) via @flixos90
      • Would like some eyes on this.
      • The patch is two months old now, but generally worked and passed unit tests when I did it – I think feedback is needed before this moves forward though.
    • Topics & folks with no updates this week:

    Twenty Seventeen

    • Announcement post is up
    • This will be a call for help on both the theme and theme API fronts as noted last week, and thoughts on what sorts of theme API things will be needed to support the theme (there will be a number noted in the post).
    • For a little bit of a preview, some of the things that should be looked at are better page-on-front flows, making it easier to figure out where to edit something while live previewing (aka customizer), and how we can help people see how the theme can really serve their needs well (when relevant).
    • There will be *a lot* of opportunity for UX and UI when it comes to the core side of things, and of course front-end development with the theme itself. And lots and lots of our traditional PHP and JS development.
  • David A. Kennedy 10:57 pm on September 9, 2016 Permalink |
    Tags: , ,   

    Twenty Seventeen Kickoff Meeting Notes 

    Today, we had a kickoff meeting for Twenty Seventeen! See the introductory post for some details.

    A few housekeeping notes:

    • Slack archive of meeting.
    • This meeting was short notice, but I plan on posting an agenda each week prior to the meeting.
    • No meeting next week, but watch out for posts here about tasks related to Twenty Seventeen.
    • Next meeting is Sept. 23rd.
    • Meetings are every Friday at 18:00 UTC in #core-themes in Slack.

    Our agenda was:

    Introduction to Twenty Seventeen

    • This meeting really has two main focuses: Gather help, and a design review.
    • Twenty Seventeen aims to show that the one-page look and feel is possible in a WordPress theme.
    • And the bullet points in the announcement post get directly to that:

    A better flow for using a static page as your front page.
    Visible edit icons in the Customizer, replacing the current hidden shift+click method.
    Expanding custom header images to include video (think: atmospheric video headers!).
    Dummy content for live previews.

    Ways to help

    We discussed a few of the above bullet points in more details but tried to stay out of talk of implementation. We focused on how to best break the work up and what the first steps would be. There’s many ways to help with Twenty Seventeen this year that don’t involve the theme itself or code.


    • #19627 Themes should be able to opt-in to a static front page: Document what other services, platforms and themes do to help inform a bunch of things, including page-on-front changes. @melchoyce will take a look at the WordPress.com flow for front page setup and related things to get this started.
    • Dummy content for live previews: @helen described this as: “So, dummy content would be something like a text widget with business hours appearing in live preview (currently known in the form of the customizer) if there are no widgets in that area yet. That shows users a) there’s a widget area there (otherwise it’s just empty right now, or maybe has like, a search box and a login link at best), and b) what content might work really well there and what it’s going to look like.”
    • #37974 Add multi-panel feature to pages through add_theme_support: @karmatosed created this ticket and has ideas on how to move forward with it.

    Who wants to help?

    • Front page flow: @mor10, @aaroncampbell offered to help here.
    • Video headers: Myself, and @celloexpressions have interest here.
    • Dummy content: @helen will help get this moving.
    • Visible edit icons in the Customizer: We need help here, but should have details soon on this. See: #27403.

    If you want to help on any of these, and missed the meeting, no problem! Comment here and I’ll do my best to get you pointed in the right direction.

    Design review/feedback

    @melchoyce lead the design review:

    Here are the current mockups, for reference: https://cloudup.com/cR_df4xfeeG

    Mel’s to-dos she’ll be working on in the next week: https://cloudup.com/cRPc_k7MnIb

    Points discussed:

    • Extremely wide screens + what happens to images that are not wide enough to be full-bleed.
    • Make sure color contrast requirements are met.
    • Mel wants to explore pull-quote styles and color schemes.
    • Really rock-solid support for non-latin alphabets should be explored.

    Questions, Next Steps, Etc.

    • The schedule is listed above.
    • What about browser support? See this issue from Twenty Sixteen, which Twenty Seventeen will follow.

    The theme is now on GitHub. A few things to keep in mind:

    • The theme is a fork of Lodestar, a theme designed by Mel and built by @laurelfulford. It’s an excellent base to start with and what you’ll see on GitHub.
    • The design isn’t implemented.
    • A lot of other work remains too, and issues will be created in the coming week to help guide the process.

    Again, if you want to help, comment here. If you have questions, just ask. It’s time to get to work! 🙂

    • Torsten Landsiedel 11:42 pm on September 9, 2016 Permalink | Log in to Reply

      Just a quick reminder: Please consider using version numbers for all PHP files:
      This would be great for all child theme users. Thank you! 🤗

    • Samuel Wood (Otto) 12:48 am on September 10, 2016 Permalink | Log in to Reply

      Go ahead and change the readme.txt to a readme.md for github. Make it friendly. The themes directory doesn’t care about readme files at the moment anyway.

    • hazephase 2:14 am on September 10, 2016 Permalink | Log in to Reply

      I want to help, but I am not the best coder. Is there I can do?

    • mburridge 2:20 pm on September 10, 2016 Permalink | Log in to Reply

      Hi, I’d love to get involved and help too – though I missed the meeting yesterday. I’m mainly interested in the Front Page flow area, but willing to help elsewhere if that is oversubscribed.

    • Christi 6:57 pm on September 10, 2016 Permalink | Log in to Reply

      Howdy! I’m interested in helping out, any way I can. My strengths are in HTML, CSS, troubleshooting, design, and documentation. I’m working on my PHP skills. I also have a 27″ screen I can test on, if that helps 🙂

    • WPDevHQ 5:51 am on September 11, 2016 Permalink | Log in to Reply

      I’m in too. Let me know where I can help.

      Had a look at the design screenshots and the code on GitHub and I think I can chip in the overall workflow but can also concentrate on a specific workflow if need be.

      A rough working copy is here: http://www.wpdevhq.com/seventeen/ – need some polishing but can get to that as soon the final design is released and we are ready to go at it 🙂

    • smartpixels 11:32 am on September 11, 2016 Permalink | Log in to Reply

      I wish to help with Customizer side of things… I have also implemented sweet alert system through Customizer API into this theme https://themes.trac.wordpress.org/ticket/35788 which I thought improved overall user experience in customizer with feedback for every wrong action.

    • Nick Halsey 6:58 pm on September 11, 2016 Permalink | Log in to Reply

      @davidakennedy please reference the existing core ticket for visible edit icons (or whatever the UI ends up being) in the Customizer: #27403 when discussing it.

      For the static front page discussion, #16379 is probably more relevant than #19627, and #16379 may be superseded by #38013 for the customizer. It’s somewhat unclear what the objective here is. The multi-part homepage discussion should probably be treated as a separate issue and we have #37974 for that now (although it may not require core changes depending on the decisions made).

      We could probably broaden the video headers project to include explorations for other types of media in headers throughout the theme, as @melchoyce had mentioned, with video header being the first priority and additional wish list items following the work on that.

  • Helen Hou-Sandi 3:03 pm on September 9, 2016 Permalink |
    Tags: , ,   

    Say Hello to Twenty Seventeen 👋🏽 

    It’s that time again: time to build a new default theme for WordPress!

    WordPress 4.7 will launch with a brand new theme – Twenty Seventeen. Designed by Mel Choyce (@melchoyce), Twenty Seventeen sports a modern look and will make a good base for any business website or product showcase.


    Check out the gallery below to preview our next default theme at full-size:

    (Higher resolution mockups)

    In addition to having a wide appeal, Twenty Seventeen will focus on providing a seamless initial theme setup so anyone can set up a website for themselves or their business with minimal hassle.

    Twenty Seventeen aims to show off some new core features and enhancements, such as:

    • A better flow for using a static page as your front page.
    • Visible edit icons in the Customizer, replacing the current hidden shift+click method.
    • Expanding custom header images to include video (think: atmospheric video headers!).
    • Dummy content for live previews.

    Mel will keep an eye on all things design during the creation of Twenty Seventeen. Laurel Fulford (@laurelfulford) and David Kennedy (@davidakennedy) will assist her, leading the theme’s development. Lots of opportunities exist this year for getting involved with Twenty Seventeen – we need your help, and lots of it! 🙏🏽

    Backing up the Twenty Seventeen team will be a team focusing on the core Themes API. This team is looking for new and experienced core developers with theme experience to help lead and contribute to specific features.

    Similar to feature projects, the initial development of the theme will be on GitHub. Once it’s usable and stable, the theme will be merged into core and the GitHub repo will be deprecated. After it’s merged, all issues should be reported to Trac.

    Twenty Seventeen will also use plain CSS — it won’t use preprocessors in the development of the theme. This will keep it simple, making the theme easier for everyone to understand, quicker for anyone to modify and better to maintain in the long run.

    Throughout the process of building Twenty Seventeen, the team will be collaborating with the Theme Review Team and the core development team to make sure it is up to core standards.

    How can you get involved?

    There will be weekly meetings every Friday at 18:00 UTC in #core-themes starting today. During that time, the focus will be on the theme itself. If you are interested in contributing, keep an eye out here for updates or join us in #core-themes in Slack.

    If you have some early thoughts on what would make this a great WordPress experience, or if you’re generally interested in participating, sound off in the comments. Please hold any design feedback for Friday’s meeting. where we can have a conversation about it in greater depth.

    Want to know more about default themes?

    Here are some links where you can find out more about past default themes:

  • Grant Palin 6:19 am on September 9, 2016 Permalink |
    Tags: ,   

    Week in Core, August 31 – September 7, 2016 

    Welcome back the latest issue of Week in Core, covering changes [38456-38570]. Here are the highlights:

    Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

    Code Changes






    • Fix php warning due to WP_Customize_Manager::prepare_setting_validity_for_js() incorrectly assuming that WP_Error will only ever have arrays in its $error_data. [38513] #37890
    • Introduce paneVisible state and ensure pane is visible when a construct is expanded (or focused). Fixes #36678. [38492] #27403, #36678
    • Fix i18n by re-using the add_new_item post type label instead of using a post type name in a generic string. [38479] #34923, #37895
    • Use new $status_code parameter for wp_send_json_error() instead of calling status_header() separately. [38478] #35666, #37897
    • Improve handling of active state for dynamically-created controls/sections/panels. [38464] #37270


    • Find the correct table names in DELETE queries with table aliases [38507] #37660


    • Update the $message parameter for _default_wp_die_handler() to notate that it can also accept a WP_Error object. [38518] #37770
    • Correct @since entry for the smilies filter added in [38504]. [38505] #35905
    • Move term_description() reference from filter docblock to get_the_archive_description() function docblock. [38495] #37259


    • fix jumpiness on pressing backspace and delete in the Text editor. Merge of [38426] to the 4.6 branch. [38487] #37690


    • Clarify some assertion failure messages and correct a test URL for Twitter timelines. [38514] #32360
    • Update the oEmbed provider test suite. [38512] #32360



    • Handle an edgecase within the URI parsing library included in Requests, where if a double slash exists at the start of the path the URL is passed to cURL malformed. Merge of [38429] to the 4.6 branch. [38485] #37733
    • Accept non-string values in cookies, fixing a regression since 4.5. Merges [38430] to the 4.6 branch. [38461] #37768


    • Revert changes to wp_parse_url() while PHP 5.2 errors are investigated. [38456] #36356


    • revert [38386], functions.php was probably too tempting for some people to not load by itself. [38469] #36335
    • revert [38467], wp_is_IE() should not exist. [38468] #37699
    • use a new function, wp_is_IE(), instead of the $is_IE global in a number of places. [38467] #37699
    • use get_bloginfo( 'version' ) instead of global $wp_version in several locations – excluding those locations which reload version.php mid-flight. [38459] #37699


    • Remove an outdated help sentence on “My Sites” screen. [38474] #37896


    • Add translator comments for XML-RPC strings with placeholders. [38510] #37792

    Login and Registration

    • Change login label to Username or Email Address for clarity. [38477] #37871


    • Sanitize upload filename. [38538] #



    • Deprecate wp_get_network(). [38515] #37553
    • use get_current_site() instead of $GLOBALS['current_site'] (stop yelling!) in a few remaining spots. [38458] #37699
    • use get_current_blog_id() where applicable, in lieu of plucking the $blog_id global from outer space. [38457] #37699

    Post Thumbnails

    • Prevent post thumbnail previews from spilling into other images. Merge of [38433] to the 4.6 branch. [38476] #37697

    Press This

    • don’t check for already-hoisted global in press-this.php. [38466] #37699
    • in wp_ajax_press_this_save_post() and wp_ajax_press_this_add_category(), don’t check for a global instance. WP_Press_This is a Controller, but not really a Singleton. This also keeps it from being a pluggable class, which it is right now. [38465] #37699
    • in get_shortcut_link(), just check a class constant on WP_Press_This instead of instantiating the object and reading an instance prop. [38462] #37699


    • ‘orderby=include’ should support comma-separated lists. [30052] assumed that ‘include’ would be an array. [38500] #37904
    • Use AND in a SQL query rather than &&. [38491] #37903
    • r38356, you were not long for this world. [38471] #37830
    • in wp_old_slug_redirect(), use get_query_var() instead of importing and touching the global $wp_query directly. [38463] #37699


    Script Loader




    • Introduce some taxonomy capability tests in preparation for introducing more fine grained capabilities for terms. [38516] #35614
    • Introduce wp_insert_term_data and wp_update_term_data filters for altering term data before it is inserted/updated in the database. [38484] #22293
    • Correct the function description for wp_ajax_add_link_category(). [38490] #37770
    • Update various docs for parameters which are now WP_Term objects. See #14162 [38489] #37770, #14162


    • After [38486], actually use the $description variable in get_the_archive_description(). [38493] #37259
    • In get_the_archive_description(), add support for author archives. [38486] #37259

    Text Changes

    • Improve Error messages in XML-RPC [38509] #37792
    • Improve the timezone setting description in General Settings. Makes more clear users can set either a city or a UTC timezone offset. [38483] #34789


    • fix toolbars alignment in RTL. Merge of [38349] to the 4.6 branch. [38488] #37760
    • change the default font for the vi locale to the same stack as he_IL. Merge of [38427] to the 4.6 branch. [38472] #37755



    • After [37687], fix the number of params passed to the upgrade hooks. Merge of [38415] to the 4.6 branch. [38475] #37731
    • Sanitize file name in File_Upload_Upgrader. [38524] #



    • After [33766], don’t reset the password when clicking “Show Password” and then “Cancel” on Add New User screen. [38494] #37902, #33419

    Pass $profileuser parameter to user_profile_picture_description filter on “Edit User” screen. [38481] #37379


    • Make the Delete/Remove links red. For consistency and accessibility, all the UI controls that perform destructive actions should be red. [38536] #35622, #37016

    ## Props

    Thanks to @afercia, @Akeif, @akibjorklund, @andrewp, @atimmer, @azaozz, @batmoo, @boonebgorges, @celloexpressions, @Chaos, @curdin, @dd32, @deremohan, @dlh, @DrewAPicture, @Engine, @flixos90, @Frank, @fronaldaraujo, @GaryJ, @geminorum, @gitlost, @GrantDerepas, @henrywright, @ibachal, @ideag, @ionutst, @jeremyfelt, @joemcgill, @johnbillion, @johnjamesjacoby, @johnpgreen, @jorbin, @Klein, @lukecavanagh, @monikarao, @mte90, @netweb, @nmt90, @patilswapnilv, @pento, @peterwilsoncc, @PieWP, @Presskopp, @ramiy, @Rarst, @sayedwp, @scrappy@…, @SergeyBiryukov, @smerriman, @swissspidy, @TimothyBlynJacobs, @turtlepod, @westonruter, and @wonderboymusic for their contributions!

  • John Blackbourn 1:14 am on September 9, 2016 Permalink |
    Tags: ,   

    New Functions, Hooks, and Behaviour for Theme Developers in WordPress 4.7 

    WordPress 4.7 will introduce some new goodies for theme developers, and you can test them out now in trunk. These changes make powerful new functionality available to themes and plugins. It would be great to see theme developers testing this functionality and providing feedback, either in the comments here or on the individual tickets linked below.

    Note: Note that these functions and hooks are subject to further change!

    The get_theme_file_uri() Function, and Friends


    The get_template_part() function, introduced way back in WordPress 3.0, is a fundamental one to theme developers and child theming. The function looks in the child theme for the specified file, and falls back to the parent theme if the file doesn’t exist. This allows a template part to be easily overridden by a child theme, simply by means of the file existing.

    The new get_theme_file_uri() function introduced in WordPress 4.7 enables this child theme behaviour for theme file URLs, for example when a CSS or JavaScript file is enqueued. Here’s an example of its use:

    wp_enqueue_script( 'my-script', get_theme_file_uri( 'js/my-script.js' ) );

    The above code enqueues the URL of the js/my-script.js file from the child theme if it exists, falling back to the URL of the file in the parent theme. Now your parent theme can enable each of its enqueued assets to easily be overridden by a child theme. And of course, if no child theme is in use then the function simply uses the parent theme URL, just like get_template_part().

    The companion function get_theme_file_path() has also been introduced. This is the file path equivalent of get_theme_file_uri(). One use case for this function is if you like to dynamically generate the version parameter for your enqueued assets based on the last modified timestamp of the file (using filemtime()). You can continue to do so by using this function:

    	get_theme_file_uri( 'js/my-script.js' ),
    	filemtime( get_theme_file_path( 'js/my-script.js' ) )

    Finally, get_parent_theme_file_uri() and get_parent_theme_file_path() are also introduced, which specifically reference the file URL or file path to the file in the parent theme (and regardless of whether or not the file exists). For consistency, these functions can be used as replacements for when you may have otherwise used get_template_directory_uri() and get_template_directory() respectively.

    The {$type}_template_hierarchy Filter


    This new dynamically-named filter allows the complete template hierarchy of a given request type to be filtered by a plugin or theme. Although it’s technically possible for the template hierarchy to be filtered using the existing template_include filter, this new filter allows it to be done in a much more clean, simple, and future-proof way, and without the need to reimplement the entire hierarchy logic within the filter’s callback function.

    The filter names available by default are:

    • embed_template_hierarchy
    • 404_template_hierarchy
    • search_template_hierarchy
    • frontpage_template_hierarchy
    • home_template_hierarchy
    • taxonomy_template_hierarchy
    • attachment_template_hierarchy
    • single_template_hierarchy
    • page_template_hierarchy
    • singular_template_hierarchy
    • category_template_hierarchy
    • tag_template_hierarchy
    • author_template_hierarchy
    • date_template_hierarchy
    • archive_template_hierarchy
    • paged_template_hierarchy
    • index_template_hierarchy

    Here’s an example of the usage of this new filter to add a year-based file to the top of the hierarchy for date archives:

    add_filter( 'date_template_hierarchy', function( array $templates ) {
    	$year = get_query_var( 'year' );
    	array_unshift( $templates, "year-{$year}.php" );
    	return $templates;
    } );

    Here’s a slightly more complex example of adding a file to the hierarchy for a category archive based on the value of its term meta field:

    add_filter( 'category_template_hierarchy', function( array $templates ) {
    	$format = get_term_meta( get_queried_object_id(), 'format', true );
    	if ( $format ) {
    		$new = "category-format-{$format}.php";
    		$pos = array_search( 'category.php', $templates );
    		array_splice( $templates, $pos, 0, $new );
    	return $templates;
    } );

    More usage examples can be seen in the comment thread on the ticket: #14310.

    This filter also allows debugging plugins to access and display the complete template hierarchy for each request, so you can see which files WordPress is looking for in your theme. The latest version of Query Monitor already supports this functionality.

    Alert: It’s important to remember that the consistency of the template hierarchy in WordPress is what makes standardised theme structures possible. It’s highly recommended that you do not remove templates from the candidate hierarchy using these new filters, unless you’re absolutely certain of what you’re doing.

    Simpler Template Names for Content with Non-ASCII Slugs


    Given a post or term with a non-ASCII name, such as hello-world-😀, the URL-encoded form of the name is used in the template hierarchy. For example, on the single post view the hierarchy looked like this prior to WordPress 4.7:

    • single-post-hello-world-%f0%9f%98%80.php
    • single-post.php
    • single.php
    • singular.php
    • index.php

    This isn’t very user-friendly, so WordPress 4.7 adds a new, higher priority template to the hierarchy which uses the non-encoded form of the name:

    • single-post-hello-world-😀.php
    • single-post-hello-world-%f0%9f%98%80.php
    • single-post.php
    • single.php
    • singular.php
    • index.php

    This makes it much clearer what a template file refers to when building templates for specific posts or terms that include non-ASCII characters in their name.

    • Tran Ngoc Tuan Anh 2:25 am on September 9, 2016 Permalink | Log in to Reply

      `get_theme_file_uri()` and `get_theme_file_path()` are great! Much more convenient than `get_template_directory_uri()` and `get_template_directory()`.

    • Sami Keijonen 5:49 am on September 9, 2016 Permalink | Log in to Reply

      Looks great. But I was confused of last Non-ASCII filter.

      This explains it’s purpose to me much better:

    • Nicolas Juen 7:45 am on September 9, 2016 Permalink | Log in to Reply

      This is very good, but can’t we have a filter on the folders to scan for the ressources ?
      This can be VERY interesting for making a parent framework theme and the filter can be added to the locate_Template function too.

    • ThemeZee 8:06 am on September 9, 2016 Permalink | Log in to Reply

      Allowing child themes to override JS and CSS files easily is a really really great feature, I like it.

      Why do we need get_parent_theme_file_uri() when it does basically the same as get_template_directory_uri() ? Just for consistency? So it is only a wrapper function?

      • John Blackbourn 10:01 am on September 9, 2016 Permalink | Log in to Reply

        Yep, mostly for consistency in the way you call the functions. `get_parent_theme_file_uri()` and `get_parent_theme_file_path()` accept a parameter for the file name, whereas `get_template_directory_uri()` and `get_template_directory()` don’t.

      • Justin Tadlock 12:30 pm on September 9, 2016 Permalink | Log in to Reply

        Plus, there’s an associated filter hook.

    • Omaar Osmaan 2:07 pm on September 9, 2016 Permalink | Log in to Reply

      Thanks so much for all of it- can’t wait to use the filters, and the functions in a theme/plugin! 😀

    • lkraav 8:59 am on September 13, 2016 Permalink | Log in to Reply

      I’ve been long wondering, is it possible to do cache busting in a more DRY inline manner (without noisy variable definition)?

      `wp_enqueue_script( ‘my-script’, get_theme_file_uri( ‘js/my-script.js’ ), array(), filemtime( get_theme_file_path( ‘js/my-script.js’ ) ) );`

      `wp_enqueue_script( ‘my-script’, get_theme_file_uri( ‘js/my-script.js’ ), array(), filemtime( get_theme_file_path( SOME_MAGIC_HERE ) ) );` where this magic is some known marker/value that is automatically converted to the same value given to `get_theme_file_uri()` – in this case `js/my-script.js`

  • Brian Krogsgard 9:25 pm on September 8, 2016 Permalink |
    Tags: ,   

    WordPress REST API update 


    There’s a renewed push going on right now to try and get what is being termed “content endpoints” into WordPress core with the 4.7 release.

    In the first core development meeting of the 4.7 cycle, @helen identified a series of tasks that would need to be analyzed and acted upon to be able to make a new proposal for core inclusion, including identifying existing blockers. There is a team of people actively working on these items, and your participation is wanted!

    New meeting times

    Regular meetings have been changed to take place at 14:00 UTC Mondays, with bug scrubs at 14:00 UTC Thursdays — all in #core-restapi. So the next meeting is Monday, September 12th, 14:00 UTC.

    Fuller story and action items

    If you are not caught up on the state of the WordPress REST API, the infrastructure for the API went into WordPress 4.4. Since that time, several prominent plugins are using the infrastructure to create their own REST APIs.And now the feature project (not in core) consists of core endpoints and authentication mechanisms. The four primary types of resources that have been developed are for: posts (and other post types), users, comments, and terms. There is also a Google spreadsheet where you can list sites you know of running V2 of the REST API plugin in production.

    The proposal, if the various criteria are met, would request core inclusion for what we’re calling “content endpoints”, and “management endpoints” would be part of a subsequent release cycle. With the content endpoints, website developers would have tools at their disposal to build websites in whatever programming language they choose, using data from WordPress. Additionally, certain types of applications would also be able to create experiences for managing WordPress content — though not complete WordPress site management the way you can from the WordPress admin.

    The primary focus areas for core inclusion of the WordPress REST API — as initially defined by Helen, and then expanded on in the core dev chat meeting — are as follows:

    1. Rigorously test 4.6 and trunk compatibility and resolve any issues that may be found.
      1. Includes reviews by current component maintainers for existing endpoints.
      2. For example: WP_Post_Types and other new objects, need compatibility.
    2. Identify and resolve some of the final “quirky” issues (e.g. password-protected posts).
    3. Create support for meta.
      1. By “meta support” in the API, we refer to meta values that have been registered by a developer. Ideally via register_meta( ...., array( 'show_in_rest' ) ). For clarity, this excludes arbitrary meta storing (i.e. a client arbitrarily using the WordPress database)
    4. Create support for options – this is not “content” per say, but imagine an app where you can’t change your site title and tagline.
      1. Needs significant clarification, definition of what should be achieved
      2. Repo for site endpoints: https://github.com/WP-API/wp-api-site-endpoints
        1. Discuss architecture for how this would work (like, site endpoints w/ object of settings) https://github.com/WP-API/WP-API/issues/816
    5. Establish a forward compatibility plan, particularly around how to avoid/minimize plugin and theme conflicts. IE: namespacing and documentation / protected stuff. Relate to current general WP best practices (IE: custom field named “likes” – possible vs good idea). Need document to outline our views.
    6. Dedicated reviews from developers with deep experience in security and REST APIs, ideally including some of the non-WP PHP community.
      1. Identify and request reviews by specific developers & subjects.
        1. Security
        2. Core compatibility
        3. Integration
        4. Consumption
        5. Non-WP developers / fresh eyes
    7. Identify current authentication options, and their viability for inclusion in 4.7. Document flows of implementing and using each.
      1. Cookie auth
      2. Basic auth
      3. oAuth 1
      4. oAuth 2
    8. Establish and document data with performance comparisons – speed, bandwidth, etc – against admin-ajax, XML-RPC, etc. (Might just require education, as really all these are pretty similar). Identify and address performance related issues on project GitHub repo.
    9. Recruit and assign new / excited contributors
    10. Align existing docs with primary project. Outline documentation needs, and create them.
      1. Get volunteers to take on specific tasks
      2. Decide where these docs go, both now and in the future

    Specific initiatives

    There are several more specific initiatives to work on, many of which we’ve tasked out and assigned, but plenty that could use more input.

    Docs Initiatives

    • Inline docs will eventually be merged into core inline docs, so any prep there should be roadmapped along with the rest of the 4.7 planning
    • User docs on consuming the API (e.g. doing things with the routes it provides from external systems, like uploading media) are needed and should live in the docs-v2 repo for now. See issues list for current user-facing documentation needs.
    • User docs on extending within the context of the API plugin (how to add routes, how to lock down access to auth’d users) are needed and should live in the docs-v2 repo for now
    • Docs on making endpoints with the infrastructure currently in core should live within the developer handbook

    Task Assignments

    • Ping component maintainers to see what testing they’ve done w/ API (@krogsgard)
    • Password game plan: relies on #16483: Blank content, rendered string, title however it is done in core now, 401 for individual posts, content to include protected:truein return object, and (maybe) give users that can edit posts access to content in response, consider Authorization header options. (@rmccue)
    • A pass at registered settings. @joehoyle has tackled this with a first draft, along with #37885.
    • Document feature detection as it works today (http://v2.wp-api.org/guide/discovery/). Establish best practice for extending with new endpoints. Establish best practice for modifying existing objects.
    • Documentation needed: compare register_rest_field() vs register_meta() and document best practice for when register_rest_field() may still be preferable. But generally encourage usage of register_meta()
    • Consideration: With register_rest_field, maybe force a namespace a la register_rest_route
    • Contact implementors from @joehoyle‘s API-in-use list to get feedback on their experience with the API (@krogsgard)
    • Document that name, description, url and home are the options already available in index as read-only. Consider change of this with global options endpoint.
    • Develop personas for user groups that interact with the API (@jorbin)
    • Interface testing for cookie and oauth1 implementations. Recruit UI/Design help. (@krogsgard and @kadamwhite)
    • Determine auth_callback (needs different name, has a conflict right now) necessity within register_meta(), as someone may want meta exposed, but only for authenticated users, and there is no cap system for read_meta.>
    • Review https://github.com/WP-API/WP-API/issues/2558 for performance gain.
    • Review https://github.com/WP-API/WP-API/issues/1625 for awkward data handling w/ client-js

    Bug scrubs

    The first bug scrub of this cycle took place today, and we were able to go through all open issues on GitHub that do not have a label, and label them, plus add at least some level of context. Our priority for future meetings will be to ensure that we have assigned bugs to appropriate people, and go back through and ensure we have milestones assigned to various tickets. We’ll have an open floor period during each regular meeting to discuss particular issues.

    Get involved

    If you have any interest in the API, your help and insights are wanted! You can join Chat.WordPress.org in the #core-restapi room to sit in and watch, or jump in to various discussions. Also, if you just want to play with the plugin and report back your experience, that’d also be super helpful.

    One group of core contributors we really need feedback from are component maintainers. The team working on the REST API would like your input on how well the API currently interacts with your component, how it can improve, and to identify trouble areas that would need to be addressed both for initial core inclusion of the API, and down the road.

    Thanks for listening!

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