Make WordPress Core

Updates from October, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Obenland 5:49 pm on October 20, 2015 Permalink |
    Tags: , ,   

    Document title in 4.4 

    WordPress 4.1 introduced a way for themes to support a new way of rendering the document title, letting Core handle its generation and output. The next step followed just recently (#31078), deprecating wp_title() and replacing it with a more comprehensive way to generate titles.

    UPDATE 12 November – wp_title has been reinstated until alternative usages have been identified and a path forward for them defined.

    Plugin authors can now check for theme support and have a few new filters available that will allow them to change or replace the title in a reliable way:

    • 'pre_get_document_title' short-circuits wp_get_document_title() if it returns anything other than an empty value.
    • 'document_title_separator' filters the separator between title parts.
    • 'document_title_parts' filters the parts that make up the document title, passed in an associative array.

    This latest change makes the new API (almost) feature complete and theme authors are discouraged from using wp_title() in the future. If it was decided to add a UI to let users choose the make up of their document title, or another improvement to how title generation works, we now have a forward compatible way to handle these things.

    To upgrade themes from using wp_title() to declaring theme support for core’s title-tag without breaking backwards compatibility with WordPress 4.0 and older, theme authors can check if the callback function exists and add a shiv in case it does not:

    if ( ! function_exists( '_wp_render_title_tag' ) ) :
    	function theme_slug_render_title() {
    <title><?php wp_title( '-', true, 'right' ); ?></title>
    	add_action( 'wp_head', 'theme_slug_render_title' );
    • Pippin Williamson 6:10 pm on October 20, 2015 Permalink | Log in to Reply

      As much as I love this improvement, I really don’t think a deprecated notice should be thrown here. The sheer number of themes using wp_title() is overwhelming and it will be a support / maintenance nightmare.

      • WebMan Design | Oliver Juhas 6:24 pm on October 20, 2015 Permalink | Log in to Reply

        I completely agree! This will be huge impact.

      • Konstantin Obenland 6:43 pm on October 20, 2015 Permalink | Log in to Reply

        At the point of release, theme support will have been introduced a year earlier, with the WPTRT adding it as recommended from the start. Two default themes will have been shipped with it, and it’s used in over 300,000 themes derived from _s since November ’14. And as Justin pointed out, it will have been required for the theme repo for more than a quarter of that time.

        While legacy themes will obviously still use it, there has been quiet a bit of theme developer education around this. The current landscape of document titles is really not as bleak as some make it sound.

      • Chuck Reynolds 2:15 am on October 21, 2015 Permalink | Log in to Reply

        I agree there will be a lot of questions but I also agree it’s time.

      • Coen Jacobs 10:08 am on October 22, 2015 Permalink | Log in to Reply

        If we’d go by that reasoning, there would be never any change possible. Production environments need to have debug mode switched off, so no notices there. Second, this change has been coming for so long, themes that have been actively maintained have had the chance to introduce their own way to deal with the deprecation already.

        • Samuel Wood (Otto) 9:32 pm on October 23, 2015 Permalink | Log in to Reply

          Like it or not, many live webhosts default to having the PHP display_errors flag enabled. Every time a new deprecated notice is added, sites all across the web break. Since this is going to affect themes, right on the front-page of the site and everywhere else, then that’s a lot of breakage. We cannot hope to upgrade all sites in time for this breaking change.

          Suggestion: Make the deprecated notice system not quite so stupid. Yes, users need to know things. However, if display_errors is on, and it’s the front end of the site (or the login page), and WP_DEBUG is not turned on, then we should probably shut it off if a deprecated notice is thrown. Throwing a notice out on login breaks logins (by breaking cookies), and throwing one on the main site makes for “broken” sites in the eyes of users. And all for a notice that a function, which still likely works okay, may not work in the future.

          I’m fine with the title change. But “deprecated” messages should not be so strong as to actually cause people to want to rollback WordPress versions.

          Yes, BTW, I do realize that _deprecated_notice only triggers when WP_DEBUG is explicitly on. Still, sometimes it is through auto-installers or something else. We should have some better way of warning people than displaying these notices right on the front end of the site.

          • FolioVision 3:13 am on November 3, 2015 Permalink | Log in to Reply

            We strongly agree here Samuel. While improving core structure is wonderful, transition should be gradual and over time. There’s no overwhelming benefit to breaking the web in this particular case. Gently gentlemen.

    • Justin Sainton 6:15 pm on October 20, 2015 Permalink | Log in to Reply

      +1 to not throwing a notice. this will be basically _every_ theme.

      • Pippin Williamson 6:15 pm on October 20, 2015 Permalink | Log in to Reply

        Including themes that are superbly built.

      • Simon Prosser 8:45 pm on October 20, 2015 Permalink | Log in to Reply

        Notices are only displayed with WP_DEBUG on, whats the issue?

        • Sybre Waaijer 6:29 am on October 22, 2015 Permalink | Log in to Reply

          The problem is that when a user wishes to turn it on to discover a nasty bug on a live site it will absolutely destroy the SEO value of the site if a search engine spider sees it.

          It would be better to enqueue the deprecation notice within the footer or any other part other than the tag.</p> <p>However, it’s suffice to say that I’ve been working for a good 40 hours to compromise the wrongly used wp_title tag within the header without using buffer rewriting.</p> <p>This update will force users to switch to a better theme, and it will also force theme developers to use the standards.<br /> From there it will also save a lot of developers heaps of time <img src="https://make.wordpress.org/core/wp-includes/images/smilies/simple-smile.png" alt=":)" class="wp-smiley" style="height: 1em; max-height: 1em;" /> So I’m pretty much all for the deprecation notice, wherever it actually may be.</p> <p>You know what, keep the deprecation notice within the title 😀 Hurray for standards!

    • Justin Tadlock 6:22 pm on October 20, 2015 Permalink | Log in to Reply

      I just wanted to note that WordPress.org themes are no longer encouraged to have the back-compat code. Title tag support is now required.

    • Aaron D. Campbell 6:49 pm on October 20, 2015 Permalink | Log in to Reply

      There is a fine line to be walked between backward compatibility and pushing ahead into better things. I think this is one of those cases where we’re walking that line very well. Themes are encourage (or in the case of .org, required) to push ahead into the newer/better way, and any theme that uses the older way **still works as it did before**. The notice deprecated function notice is not only just a notice (not an error or warning), but it’s only triggered by default if WP_DEBUG is on.

    • Drew Jaynes 7:12 pm on October 20, 2015 Permalink | Log in to Reply

      I see an inevitable question popping up: “What do I use instead?”

      The simple answer is nothing.

      If you add add_theme_support( ‘title-tag’ ); to your after_setup_theme callback, the title will just be handled. An internal core function adds it via the wp_head hook. No need to add anything to your theme’s header.php file, just remove the legacy wp_title() call.

      The ‘title-tag’ theme support was (as mentioned) added to core a year ago.

      Also, as @obenland alluded, there are several filters available for customizing the output:

      • pre_get_document_title – short-circuits wp_get_document_title() if it returns anything other than an empty value.
      • document_title_separator – Makes the separator between title parts filterable.
      • document_title_parts – Makes the parts that make up the document title filterable, passed in an associative array.
    • Jose Castaneda 8:47 pm on October 20, 2015 Permalink | Log in to Reply

      Sweet! One less thing for theme authors to maintain!

      • Ross Wintle 2:48 pm on October 22, 2015 Permalink | Log in to Reply

        So the simple answer is actually: “add `add_theme_support(‘title-tag’);` to your `after_setup_theme` callback! 😉

      • Ross Wintle 2:49 pm on October 22, 2015 Permalink | Log in to Reply

        Oh bother – that was a reply to @drewapicture above. Why is the reply button at the top of comments here?! You can tell I don’t comment on make blog very often.

    • catchmyfame 9:14 pm on October 20, 2015 Permalink | Log in to Reply

      Should https://codex.wordpress.org/Theme_Development#Template_File_Checklist be updated to *not* encourage the use of wp_title()? I didn’t see the equivalent checklist at https://developer.wordpress.org/themes/

    • simonrcodrington 9:51 pm on October 20, 2015 Permalink | Log in to Reply

      I’m all for moving forward with better things. As long as this is a developers notice when debugging is turned on and not an admin level notice that bothers users, I’m all for it.

    • Ahmad Awais 8:44 am on October 22, 2015 Permalink | Log in to Reply

      Fantastic! I just hope that theme authors will adopt this thing as quickly as possible.

    • Ross Wintle 2:47 pm on October 22, 2015 Permalink | Log in to Reply

      Confession: I’ve not been keeping up with developments in wp_title() in the last few releases. And I’m a developer who reads the make blog!! It’s only just now become clear that there is a new best practice from the one I started using several years ago. I suspect that there are many other developer like me, and many who don’t read the make blog!!!

      As a developer that creates custom themes for clients, I’m happy for a notice to be issued (to remind me to do it in future work!). I accept the need for (well documented and communicated) deprecation, but I’d really appreciate some guarantee on removal from core. I have a LOT of custom themes out there that I’ve built over the last four or five years. They all use wp_title somewhere. I’m hoping that I won’t be needing to update all that legacy code.

      Should the codex for wp_title be updated at this point to reflect the new best practice?

      • Drew Jaynes 3:04 pm on October 22, 2015 Permalink | Log in to Reply

        Should the codex for wp_title be updated at this point to reflect the new best practice?

        The code reference page for wp_title() will be updated with the deprecation notice when 4.4 is released. By that point, the wp_title() Codex article will already be redirecting to the code reference, as well.

    • BackuPsNL 4:05 pm on October 22, 2015 Permalink | Log in to Reply


      How to call the new title function with the separator of choice?
      How to get just the title without the wpsite name?

      I liked the way wp_title() worked.

      I am not happy with this code change… :-(

      • Konstantin Obenland 3:32 pm on October 23, 2015 Permalink | Log in to Reply

        How to call the new title function with the separator of choice?

        You can use the document_title_separator filter to change the separator to whatever you like. You can now even customize it to change based on what kind of page is being viewed!

        How to get just the title without the wpsite name?

        When you filter document_title_parts you can just change or unset the part that you don’t want to show up.

        • BackuPsNL 8:54 am on October 24, 2015 Permalink | Log in to Reply

          How does this work with the Yoast Seo plugin. As in the previous version i could just call wp_title and i got the correct yoast seo title when the plugin was activated.

          Now i have to enable force rewrite titles in that plugin settings to get the correct title in my page.

          With the Yoast plugin enabled and with force rewrite titles off i do not get the correct title as entered in the yoast seo title field in the page.

          I want to use my own title function as i dont like how wp presents it now.

          From wordpress you get Title – Page – Blog But i want Title – Blog – Paged

          There is no way to change the order or how wordpress presents the title. is there? If so please provide a example how todo so.

    • johnstonphilip 4:57 pm on October 22, 2015 Permalink | Log in to Reply

      I had used wp_title to generate facebook open graph meta tags. What would one want to use for that instead moving forward?

      <meta property="og:title" content="” />

      • johnstonphilip 4:58 pm on October 22, 2015 Permalink | Log in to Reply

        ok so the php was stripped out of that comment. Here it is again without the php tags

      • Konstantin Obenland 3:34 pm on October 23, 2015 Permalink | Log in to Reply

        Using wp_title() to display anything other than the document title is not really ideal. In your case you’d want to use the wp_head action to attach a callback that would output that html.

        • Nathan Shubert-Harbison 10:37 pm on November 5, 2015 Permalink | Log in to Reply

          What would you use to print the page title inside the `wp_head` action though?

          • Samuel Wood (Otto) 4:27 pm on November 11, 2015 Permalink | Log in to Reply

            Ideally, you would not be rolling your own code to do this in the first place. Many plugins can do this for you, such as SEO plugins, Facebook specific plugins, Sharing plugins, Jetpack, etc. Themes would not have this sort of code in them.

            That said, the OpenGraph title for, say, a Page, would ideally be the title of the Page, not the wp_title(). OpenGraph is for sharing content, after all. So get_the_title() would be what you want to use, although you would probably need to preload the_post() and do a rewind_posts() to get that in the normal manner. It’s not an ideal situation to pre-load posts, but it is doable by plugins. It is poorly doable by themes, they’re doing it in the wrong order, basically.

    • Shah Alom 2:43 pm on November 12, 2015 Permalink | Log in to Reply

      Have basic confusion!

      What is the difference between

      add add_theme_support( ‘title-tag’ ) to function file directly


      in the after_setup_theme callback hook

    • Konstantin Obenland 6:37 pm on November 12, 2015 Permalink | Log in to Reply

      I updated the post to reflect that wp_title() has been reinstated until alternative usages have been identified and a path forward for them defined.

    • Darko A7 4:41 am on November 17, 2015 Permalink | Log in to Reply

      This feels like a downgrade to me, what I had in few lines of code just the way I like it in one visible place, now have to do with filters and what not. Why?

      Anyway, I was doing a quick beta testing (4.4-beta4-35649) and there are absolutely no options to customize titles (separators, handling empty search strings…). This is a big omission, since they are supposedly now generated and handled by core.

      • Konstantin Obenland 4:33 pm on November 17, 2015 Permalink | Log in to Reply

        Separators can be changed with the document_title_separator filter, adjustments for special cases can be done by filtering document_title_parts .

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

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

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

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

    Feature Plugins Merged

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

    WordPress logo with wordmark below

    Responsive images in your posts. Just upload and insert!

    Potent Notables

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

    Deeper Reading

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

    (More …)

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

    Week in Core: Sept. 21-27, 2015 

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

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

    (More …)

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

    Week in Core: Sept. 13-21, 2015 

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

    News you can use

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

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

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

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

    Code changes

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

    (More …)

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

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

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

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

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

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

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

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

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

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

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

    Component Page Updates for 4.4 

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

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

    Component maintainers, here are your component pages…

    (More …)

  • Morgan Estes 5:03 am on September 2, 2015 Permalink |
    Tags: ,   

    WordPress Core Weekly – Aug. 24-30, 2015 

    Welcome back to the weekly core development recap post, with highlights from Trac changesets and other development updates for 4.4. This week’s update covers changesets [33721][33820], Aug. 24-30, 2015. That’s a lot of changes, but there are a few that developers need to be especially aware of:

    • File restructuring: new class and functions files have been introduced, and existing files used as loaders for the new files for backwards compatibility.
    • File and class documentation enhancements: ensuring every file gets a standard file header, even if that file only contains a class that is itself documented.
    • Switching themes now takes menu locations into account so the new theme (maybe) gets the locations of the current theme.
    • New hooks introduced: 'invite_user' (Multisite users) and 'wp_verify_nonce_failed'.
    • The Twenty Sixteen theme is being developed on GitHub.

    Now on to the firehose…


    • Bump h3 headings to h2 on various admin screens for better accessibility:
    • Network Admin: Hide the bulk actions checkbox for super admins. [33777] #28529
    • Avoid PHP notices in redirect_canonical() and _wp_menu_item_classes_by_context() if $_SERVER['HTTP_HOST'] is not set. [33775] #32229


    • Remove error from the query variables when cleaning up a URL in wp_admin_canonical_url(). [33770] #32847
    • Prevent unintended password change after clicking “Generate Password” and then “Cancel” when editing a user profile. [33766] #33419
    • When wp_json_encode() calls json_encode(), the latter will generate warnings if the string contains non-UTF-8 characters. No one likes warnings, so we need to do something about that. [33747] #33524
    • Add oEmbed support for ReverbNation. [33745] #33207
    • Remove rounded corners from “Choose from the most used tags” result in Tags meta box. [33742] #31560
    • Add some more data for shortcode unit tests. [33740] #33455
    • Allow these CSS properties in KSES: min-height', 'max-height', 'min-width', 'max-width' [33739] #31949
    • Pass option name to option and transient filters with dynamic names. [33738] #28402
    • In get_home_url(), import the $pagenow global to avoid having to check if it exists before comparing against it. [33736] #33545
    • In WP_Users_List_Table::single_row(), $actions is not always set before being used. [33735] #33491
    • foreach is a statement, not a function. [33734] #33491
    • Instead of [33713], allow WP_Posts_List_Table::get_bulk_actions() to check edit_posts AND delete_posts. [33733] #29789
    • TinyMCE: ensure the wordpress plugin is loaded before calling _createToolbar(). [33728] #33393
    • With a few modifications in wp-admin/menu.php, we can eliminate the extra logic for Post and Page menu registration. Instead, they can just declare menu_position on post type registration. [33723] #16865
    • WP_Query: add changelog for the title param after [33706] [33722] #33074

    Restructured some files for separation of purpose, so class files only contain classes, functions files only contain functions, and the existing file loads the new files for backwards compatibility.


    Move WP_Tax_Query into class-wp-tax-query.php and functions into taxonomy-functions.php; taxonomy.php contains only top-level code and loads the new files. [33760] #33413


    Move WP_Post into class-wp-post.php and functions into post-functions.php. post.php contains only top-level code and loads the new files. [33759] #33413


    Move classes into their own files, and functions into its own:

    • class-wp-roles.php
    • class-wp-role.php
    • class-wp-user.php
    • capbilities-functions.php

    capbilities.php contains only top-level code and loads the new files. [33752] #33413


    Move classes into their own files and functions into its own:

    • class-wp-http-cookie.php
    • class-wp-http-curl.php
    • class-wp-http-encoding.php
    • class-wp-http-proxy.php
    • class-wp-http-streams.php
    • http-functions.php

    http.php contains only top-level code and loads the new files, so this is 100% BC if someone is loading http.php directly.

    class-http.php requires functions from http.php, so loading it by itself wouldn’t have worked.

    WP_Http remains in class-http.php. [33748] #33413


    Move WP_Meta_Query into class-wp-meta-query.php and functions into meta-functions.php. meta.php contains only top-level code and loads the new files. [33761] #33413


    Move WP_Rewrite into class-wp-rewrite.php, functions into rewrite-functions.php, and constants into rewrite-constants.php. rewrite.php contains only top-level code and loads the new files.

    The rewrite functions have all kinds of cross-dependencies (like WP_Query), so loading the file by itself would have been bizarre (and still is). [33751] #33413


    Move WP_Comment_Query into class-wp-comment-query.php, and functions into comment-functions.php. comment.php contains only top-level code and loads the new files. [33750] #33413


    Move WP_User_Query into class-wp-user-query.php and functions into user-functions.php. user.php contains only top-level code and loads the new files. [33749] #33413


    Move classes and functions into their own files:

    • class-wp-widget.php
    • class-wp-widget-factory.php
    • widget-functions.php

    widgets.php contains only top-level code and loads the new files. [33746] #33413


    It’s important for every file in WordPress, regardless of makeup or architecture, to have its own file header, even if the file contains nothing but a class. When parsed, files and classes are mutually exclusive and should be documented with this in mind. [33755] [33756] #33413

    • Bring the file header and class DocBlock summaries for class-wp-widget.php in-line with the intention of the docs standard:
      • File headers: What the file is
      • Class DocBlocks: What purpose the class serves. Mentioning the class name in the class DocBlock is redundant [33816] #33413
    • Add inline-docblocks for the require_once() calls that now bring in the WP_Widget and WP_Widget_Factory classes, as well as general core widgets functionality, as of [33746]. [33758] #33413
    • Add a file header description and @since version to wp-includes/widget-functions.php, introduced in [33746].
      Also adds sub-section headers per the inline documentation standards for syntax. [33757] #33413
    • Add a file header to wp-includes/class-wp-widget-factory.php, created when the WP_Widget_Factory class was moved to its own file in [33746]. [33756] #33413
    • Correct the hook docs for the user_profile_update_errors action. [33769] #33537
    • After [33764], fix docblock formatting for wp_list_categories(). [33765] #33460
    • Use proper array documentation formatting for wp_list_categories().
      This changeset also corrects a few parameter descriptions, and adds a few that
      were previously missing. [33763] #33556
    • Fix copy pasta in wp_cache_decr() doc block. [33809] #33548
    • The type for the $t_time parameter in the post_date_column_time filter docs should be string, not array. [33731] #33540
    • Document the default comment data arguments for wp_new_comment(). [33730] #32369
    • After [33698], wrap the time constants in a DocBlock template. [33737] #33397
    • Clarify the return description for wp_create_user() to illustrate that a WP_Error object will be returned on failure. [33725] #33321

    Add changelog entries for a variety of hook doc parameters added in [33738]:

    hook parameter changeset/ticket
    set_site_transient_$transient $transient [33794] #28402
    site_transient_$transient $transient [33792] #28402
    pre_delete_site_option_$option $option [33789] #28402
    pre_add_site_option_$option $option [33788] #28402
    pre_site_option_$option $option [33785] #28402
    transient_$transient $transient [33783] #28402
    option_$option $option [33779] #28402
    pre_option_$option $option [33768] #28402
    pre_set_site_transient_$transient $transient [33793] #28402
    pre_site_transient_$transient $transient [33791] #28402
    pre_update_site_option_$option $option [33790] #28402
    site_option_$option $option [33787] #28402
    default_site_option_$option $option [33786] #28402
    pre_set_transient_$transient $transient [33784] #28402
    pre_transient_$transient $transient [33782] #28402
    update_option_{$option} $option [33781] #28402
    pre_update_option_$option $option [33780] #28402
    default_option_$option $option [33778] #28402


    • Get the correct theme when template and stylesheet were both passed as arguments. Fixes a bug introduced in [21131] where $new_theme got set before the second argument was
      appropriately handled, causing the current_theme option to later always be updated to the parent theme’s name. [33815] #32635


    • Improve/update escaping in default widgets:
      • wrap some variables in esc_attr() before echoing
      • replace some strip_tags() calls with sanitize_text_field()
      • call esc_url() when wrapping some URLs [33814] #23012
    • Improve/update escaping in WP_Widget_Pages. [33813] #23012
    • Switch back to using array_key_exists() instead of isset() for widget instance existence check.
      Reverts unnecessary change in [32602] since array_key_exists() does actually work with ArrayIterator objects.
      Merges [33696] to the 4.3 branch. [33721] #32474, #33442



    • Fix the doc block syntax for the 'wp_get_current_commenter' filter. [33811] #33304
    • get_comment_count() currently increments awaiting_moderation when comments are in the trash. This occurs because case 0: will match any value passed to switch that is a string that isn’t specified in the list of cases. This is terrifying.
      Cases for 0 and 1 should be '1' and '0'
      Add unit tests for get_comment_count(). Currently, there are none. [33806] #33414


    • Favor using the consistent and agnostic string ‘Attach’ over ‘Attach to a post’ in the media list table. [33810] #33515
    • Make a period translatable. [33802] #33594
    • Switching themes: if the new theme doesn’t have nav_menu_locations defined, but the old theme does, copy the old theme’s nav_menu_locations into the new theme’s theme mods. [33808] #18588


    • Improve the reliability of the crop returned by image_get_intermediate_size() and add a bunch of unit tests to tests/image/intermediate_size.php. [33807] #17626
    • When inserting an image into a post, the values in wp.media.controller.Library should not default to linking the image when no user settings are present.
      The default display setting value for link is now none. User settings persist and will override or confirm this value based on user actions. [33729] #31467

    Posts, Post Types

    • In get_post_type_labels(), ensure that filtered labels contain all required default values. [33776] #33543
    • Don’t change the View Post button permalink in the sample permalink HTML when updating the slug on a published or future post. [33773] #32954
    • Pass taxonomy name to filters in get_adjacent_post(). [33805] #33568
    • Make post meta box toggles accessible. [33762] #33544


    • Improve the efficiency of is_user_member_of_blog() by removing its use of get_blogs_of_user(). Adds additional tests. [33771] #32472
    • Add 'invite_user' action that fires immediately after a user is invited to join a site, but before the notification is sent. [33732] #33008


    • In wp_list_categories(), ‘current_category’ should accept an array of values. [33804] #33565
    • Introduce $hide_title_if_no_cats parameter to wp_list_categories(). [33764] #33460
    • Rename param added to wp_list_categories() in [33764] to $hide_title_if_empty. [33767] #33565
    • Term Splitting: Switch to a faster cron unschedule process to benefit sites with thousands of affected jobs. Fix the cron hook name in the failsafe rescheduler. [33727] #33423
    • In WP_Query::parse_tax_query(), allow ‘cat’ and ‘tag’ querystrings to be formatted as arrays. [33724] #32454, #33532


    • Simplify the weeks-per-year calculation WP_Date_Query::validate_date_values(). [33803] #30845


    • Bring network admin user searching to parity with single site user searching by wrapping search terms in asterisks. This means that searches don’t require an exact match and therefore significantly reduces friction when searching for users on the network admin screens. [33801] #32913

    Bundled Theme

    Correct license information in readme.txt.

    Text Changes

    • Drop the hyphen from e-mail and standardize on email.
      The AP Stylebook changed this in 2011, and we’re woefully inconsistent, so let’s go with the standard. [33774] #26156



    • Add 'wp_verify_nonce_failed' action that fires when nonce verification fails. [33744] #24030
    • Fire the check_ajax_referer action on failure as well as success. [33743] #33342

    Build Tools

    Thanks to @azaozz, @BinaryKitten, @boonebgorges, @bordoni, @Cheffheid, @chipbennett, @danielbachhuber, @dd32, @DeBAAT, @dimadin, @DrewAPicture, @ebinnion, @egill, @eherman24, @ericlewis, @garza, @hauvong, @helen, @janhenckens, @jjeato, @jmayha, @joedolson, @joehills, @joemcgill, @johnbillion, @KalenJohnson, @kitchin, @liljimmi, @luciole135, @mako09, @MikeHansenMe, @miqrogroove, @morganestes, @niallkennedy, @nikeo, @obenland, @Otto42, @pavelevap, @pento, @peterwilsoncc, @rachelbaker, @rhubbardreverb, @sammybeats, @sboisvert, @scribu, @SergeyBiryukov, @Shelob9, @tyxla, @Veraxus, @vilkatis, @Viper007Bond, @voldemortensen, @welcher, @westonruter, @wonderboymusic, and @yamchhetr for their contributions!

  • Konstantin Obenland 10:38 pm on July 21, 2015 Permalink
    Tags: ,   

    Dev Chat Agenda for July 22 

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

    During Beta Notes @iseulde would like to discuss headings and whether to convert on space or enter in #31441. Please download the latest nightly and test the feature before Dev Chat, so we can talk about it.

    Time/Date: July 22 2015 20:00 UTC:

    1. Beta Notes
    2. Feature Updates
      1. Admin UI – If @helen can make it
      2. Menu Customizer – @westonruter
      3. Passwords – @markjaquith
      4. Site Icon – @obenland
    3. Component Updates
    4. Open Floor
    • Ryan Boren 11:05 pm on July 21, 2015 Permalink | Log in to Reply

      Looks like a lot of ui discussion, potentially. Fresh screenshots posted to tickets or make/flow go well with ui discussions. 😉

    • Stephen Edgar 12:06 am on July 22, 2015 Permalink | Log in to Reply

      As I won’t be around for dev chat (Too early for us Aussies).

      I think the conversion should be on enter, after testing just now here’s why:

      As I start to type a heading ## as soon as I hit tap the spacebar any resemblance of what I typed on the screen is now gone and I’m a little perplexed why it vanished, as I start typing I see I’m now typing a h2 header, though grokking what just happened is not entirely clear.

      I’d much prefer to continue to see on screen what I’m typing so as I type ## my h2 heading all of that text remains on screen verbatim of how I typed it until I hit enter, hitting enter magic happens and I’m most suitably impressed and rejoice spontaneously with three cheers, “Hip Hip Hooray, WordPress”

  • Konstantin Obenland 2:57 pm on July 15, 2015 Permalink
    Tags: ,   

    Dev Chat Agenda for July 15 

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

    During Beta Notes I’d like to discuss how the installation flow feels now with the new Passwords UI enabled. Please download the latest nightly and create a new install with it before Dev Chat, so we can talk about it.

    Time/Date: July 15 2015 20:00 UTC:

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

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

  • Konstantin Obenland 5:20 pm on July 7, 2015 Permalink
    Tags: ,   

    Dev Chat Agenda for July 8 

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

    Time/Date: July 8 2015 20:00 UTC:

    1. Beta Notes
    2. Feature Updates
      1. Admin UI – @helen
      2. Menu Customizer – @westonruter
      3. Passwords – @markjaquith
      4. Site Icon – @obenland
    3. Feature Plugin Chat Next Week@samuelsidler
    4. Component Updates
    5. Open Floor

    Feature Leads: Let’s review last weeks goals and set new ones for 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