Make WordPress Core

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

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

We’d love for you to help out.

Looking to file a bug?

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

Want to contribute?

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

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

Weekly meetings

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

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

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

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Dominik Schilling 4:49 pm on June 29, 2016 Permalink |
    Tags: , ,   

    Weekly Dev Chat Agenda for June 29 — Ten Weeks Later 

    Agenda for the weekly dev meeting on June 29, 2016 at 20:00 UTC:

    • Feature Freeze and WordPress 4.6 Beta 1
    • Dev notes
    • Feature project updates
    • Component announcements/updates
    • Open discussion

    If you have anything to propose to add to the agenda, please leave a comment below.

    See you in the chat!

  • Andrew Rockwell 3:53 pm on June 29, 2016 Permalink |
    Tags: ,   

    Week In Core, June 21 – June 28 2016 

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

    • 102 commits
    • 41 contributors
    • 86 tickets created
    • 10 tickets reopened
    • 84 tickets closed

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

    Code Changes



    • Explicitly globalize $wpdb in wp-settings.php in case WordPress isn’t loaded in global scope. [37864] #37123


    • Improve author and content of the default comment. [37888] #36702, #14268
    • Remove the assignment of an undocumented $comment_count property in WP_Comment_Query::get_comments(), which appears to be accidentally introduced in [34544]. [37873] #37187


    • Improve flow from menu locations to editing a menu. [37901] #36795
    • Link “widget areas” to widgets panel in menu locations section description. [37900] #36796
    • Always define functions reflowPaneContents, findControlsForSettings, and _handleSettingValidities on wp.customize. See #36944. See #29071. [37867] #34893, #36944, #29071


    • Fix typo in wp-includes/shortcodes.php file description. [37865] #37175
    • Add two simple usage examples to the DocBlock for wp_redirect(). [37863] #32246
    • Improve the syntax and tensing within the DocBlock for is_home(). [37862] #32246
    • Improve formatting and syntax of the defaullt label docs in the DocBlock for get_post_type_labels(). [37886] #32246
    • Add a more complete $labels parameter description to the DocBlock for register_post_type(). [37885] #32246
    • Improve the $post_type parameter description in the DocBlock for register_post_type(). [37884] #32246
    • Add more complete documentation for the $supports argument in register_post_type(). [37883] #32246
    • Improve the usefulness, accuracy, and syntax of the register_post_type() DocBlock summary and description. [37882] #32246
    • Add missing variable reference for wp_edit_form_attachment_display. [37880] #
    • Further improve the note of caution within the DocBlock description for query_posts(). [37878] #32246
    • Add a note to the DocBlock for query_posts() to caution against general usage, including a pointer to the pre_get_posts action. [37877] #32246
    • Make the DocBlock summary for get_option() more explicit and convert to using a third-person singular verb. [37876] #32246
    • Improve the formatting and usefulness of information in the DocBlock for sanitize_text_field(). [37852] #32246
    • Add some missing changelog entries to the DocBlock for add_theme_support(). [37849] #32246
    • Correct the $request parameter datatype in the hook doc for the posts_request filter. [37848] #37142


    External Libraries


    • Update wp.template to match parameter changes to _.template in Underscore 1.8.3. [37851] #36695


    • Make “That’s all, stop editing! Happy blogging.” translatable. [37902] #36945
    • Move the WP_Locale class to its own file. [37889] #26511, #37209
    • Remove HTML tags from translatable string in wp-admin/maint/repair.php. [37858] #37147
    • Enable unloading of text domains that have been loaded just in time. [37855] #37113, #34114
    • Add support for the Catalan flown dot in remove_accents(). [37853] #37086




    • Add a ms_sites_list_table_query_args filter to WP_MS_Sites_List_Table. [37899] #26580
    • Replace wp_get_network() internals with get_network().  [37896] #32504
    • Introduce get_networks(). [37895] #32504
    • Introduce WP_Network_Query. [37894] #32504
    • Introduce get_network(). [37893] #32504
    • Remove unused site_count property from WP_Site_Query. [37875] #35791
    • Clear incomplete objects from cache in get_blog_details() when found. [37874] #36717
    • Set WP_Network blog_id property default to string as expected. [37871] #36717
    • Change WP_Network id property to an integer. [37870] #37050
    • Cache found_sites and max_num_pages in WP_Site_Query. [37868] #35791
    • Move call of get_blog_details() inside ms_site_check(). [37850] #37118


    Posts, Post Types

    • Introduce WP_Post_Type and use it in register_post_type() and unregister_post_type(). [37890] #36217
    • Fix back-compat for filters in get the modified time and date functions after [37738]. [37866] #37059
    • Add hooks for post sticky status changes. [37857] #35600
    • Add a filter to disable the categories dropdown. [37856] #36152



    • Add list-style-type to the list of allowed CSS attributes. [37898] #35877
    • Adjust the list of safecss attributes for readability. [37897] #35877



    • Wrap unusually long theme names on the Theme Details screen. [37872] #37033



    Thanks to @adamsilverstein, @anilbasnet, @azaozz, @boonebgorges, @celloexpressions, @coffee2code, @danielbachhuber, @davidmosterd, @DrewAPicture, @Ego, @flixos90, @georgestephanis, @grapplerulrich, @Ipstenu, @ixkaito, @jeremyfelt, @jnylen0, @joemcgill, @jorbin, @julesaus, @kovshenin, @littlerchicken, @nacin, @nbachiyski, @Ninos, @ocean90, @ojrask, @pento, @peterwilsoncc, @rachelbaker, @ruudjoyo, @SergeyBiryukov, @sirjonathan, @solarissmoke, @southp, @spacedmonkey, @swissspidy, @westonruter, @xavivars, and @xavortm for their contributions!

  • voldemortensen 7:38 pm on June 27, 2016 Permalink |
    Tags: ,   

    This Week in 4.6: June 27 – July 3 

    This is the jump-start post for the tenth week of the WordPress 4.6 release cycle.

    Beta 1 is June 29th, that’s only 2 days. July 4th is a U.S. holiday so many U.S. based contributors might be offline over the weekend and Monday. 🎉💥🎉💥🎉

    Tickets/projects seeking feedback:

    Meetings this week:

    Bug Scrubs

    Feature Chats

    Weekly Chats

  • Grant Palin 7:06 pm on June 23, 2016 Permalink |
    Tags: ,   

    Week In Core, June 15 – June 22 2016 

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

    • 80 commits
    • 33 contributors
    • 26 tickets created
    • 9 tickets reopened
    • 37 tickets closed

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

    Code Changes


    • Theme Installer, make the “Upload Theme” button… a button. [37742] #35457
    • Remove the ARIA roles from the wp.a11y.speak() live regions. [37734] #36289



    • improve the notice when the sessionStorage autosave is different than the content. [37737] #37025

    Build/Test Tools


    • Wrap or unwrap the List Table comment_date as comment status changes via Ajax. Introduced in [36521]. [37743] #36742



    • Clarify documentation for wp_logout_url() and wp_login_url() and corresponding hooks. [37753] #34352
    • Improve the summaries and return descriptions for get_registered_nav_menus() and get_nav_menu_locations(). [37752] #37106
    • Add a missing summary and @since version to the DocBlock for WP_MS_Sites_List_Table::prepare_items(). [37739] #36675, #21837, #24833, #33185


    • Add white outline for contrast on darker backgrounds. Change red colour in toolbar. [37751] #36638
    • after inserting a link detect if the URL is broken, first run. [37741] #36638


    External Libraries


    • when running precommit use regex to check which files have been modified. [37749] #36528


    • Add unit tests for the override_load_textdomain filter. [37746] #36398


    • Use the correct variable for the file object. [37728] #14244
    • Pass allowed file extensions to Plupload. [37727] #14244
    • properly refresh the position of the Plupload shim so it moves over the Select Files button or off the screen. Fixes #37039. [37722] #37039




    • Unifies the APIs for getting a post’s modified date or time with getting a post’s date or time. [37738] #37059



    • Include X-Robots-Tag: noindex header in REST API responses to prevent endpoints from being indexed by search engines. [37726] #36390


    • Change the capability needed to view revision diffs to edit_post. Merges [37779] to supported branches. [37799] [37797] [37796] [37791]
    • Change the capability needed to view revision diffs to edit_post. [37779]



    • Improve handling of extensionless filenames. This ensures files retain a filename after sanitization. [37756]
    • Restore keyboard navigation of the media grid. [37755] #36900



    Thanks to @adamsilverstein, @afercia, @akibjorklund, @azaozz, @boonebgorges, @coderste, @coffee2code, @dlh, @DrewAPicture, @ericlewis, @Fab1en, @flixos90, @helen, @imath, @iseulde, @jeremyfelt, @joemcgill, @jorbin, @kraftbj, @lukecavanagh, @m_uysl, @nbachiyski, @neverything, @ocean90, @peterwilsoncc, @polevaultweb, @Props, @rabmalin, @rachelbaker, @rockwell15, @Soean, @swissspidy, and @Viper007Bond for their contributions!

  • voldemortensen 2:28 pm on June 22, 2016 Permalink |
    Tags: , ,   

    Weekly Dev Chat Agenda: June 22nd, 2016 – 9 Weeks Later 

    Agenda for the weekly dev meeting on June 22 2016 at 20:00 UTC:

    If you have anything to propose to add to the agenda, please leave a comment below.

    See you in the chat!

  • Dominik Schilling 2:06 pm on June 20, 2016 Permalink |
    Tags: ,   

    This Week in 4.6: June 20 – 27 

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

    Beta 1 is only one and a half week away, June 29th. WCEU is also this weekend, June 24-26, which means a lot of people are traveling. Thus some of the meetings could be postponed or canceled.

    Also, the release process of WordPress 4.5.3 is planned to start on Tuesday, June 21st 2016 at 14:00 UTC.

    Tickets/projects seeking feedback:

    Meetings this week:

    Bug Scrubs

    Feature Chats

    Weekly Chats

    • networkwebmasters 12:13 pm on June 21, 2016 Permalink | Log in to Reply

      Autosave & Revisions are core feature of WordPress, please add Control Options for these features.
      Many users facing lots of issues on shared hosting environment.
      Also it may help speed up WordPress.

      Please add ASAP

      I tried to post here https://wordpress.org/ideas/ but this form is not working.

      Thanks 🙂

  • Nick Halsey 2:15 pm on June 16, 2016 Permalink |
    Tags: , ,   

    Feature Proposal: Content Authorship in Menus, with Live Preview 

    The current navigation menus system is built around a paradigm that every menu item must be associated with an existing piece of content. However, this is problematic for new users, who may find themselves with the opportunity to build a menu before creating any content. #34923 seeks to improve this experience and eliminate this usability “dead end” by adding the ability to create new post objects (most notably pages) within the menus interface in the customizer.


    Purpose & Goals

    While this feature is aimed primarily at new users setting up their site for the first time, it may also be useful for users that are restructuring a site, or even if they want to add a page here or there and add it to their menu before filling out its contents. It’s important to note that posts and pages added here are stubs – only their title is filled out, and the content will be added later via the post editor. For that reason, most existing sites would probably maintain their existing workflows to create new pages via the post editor, publish them, and then add them to menus. This is of course still fully supported and the new proposal seeks to provide an alternative approach that may be better for different use cases such as new sites.

    Because the feature is proposed to be located in the customizer, it also fully supports live preview. The live preview component can build user trust and confidence by letting users preview and interact with their site as changes are made, before they’re published.

    Technical Considerations

    To allow new content to be created in the customizer, posts are created with the auto_draft status. When the user saves & publishes in the customizer, these newly-created posts are transitioned to be published. In the customizer preview, the status is modified to protected to allow the posts to be previewed.

    Ideally, term creation should also be a part of the menus UI. Unfortunately, terms to not currently have a status field, and implementing that or looking at alternative approaches is something that will take more thought. Thus, this feature is being built with future support for terms in mind, but without support currently.

    By default, the ability to add new content depends on the appropriate capabilities and the show_in_nav_menus parameter when registering post types. Additionally, a new filter is proposed to allow authorship in menus to be disabled on a per-post-type basis.


    User testing has been requested and there are several tasks that could be tested:

    • Create a new menu for a brand new site by creating pages and adding them to a menu, assign the menu to a location and publish it.
    • On an existing site, create new pages to add to an existing menu.
    • On a complex site with multiple menus create a new page once then add it to multiple menus.
    • On sites with custom post types, create new custom posts for any of the scenarios above.

    Test with the latest patch on #34923 and make sure the customize posts plugin is not activated (it has conflicts). If anyone is able to conduct user tests that would be much appreciated.

    Customize Posts Plugin

    Part of the inspiration for this feature comes from the Customize Posts plugin, which has the ability to live-preview posts and post meta in the customizer. Only a very small portion of the plugin would make its way into core as part of the nav menus content authorship feature. However, the proposal is currently to establish the wp.customize.Posts namespace for future expansions of post-related functionality in the customizer. The existing plugin would extend this core namespace, and other plugins could do so as well.

    There are currently no plans to consider the Customize Posts plugin for full merge into core; however, stay tuned for an upcoming feature project kick-off that will seek to explore the future of live preview in WordPress at a broader level.

    Feedback & Next Steps

    The latest patch is currently seeking feedback for accessibility, design, code review, docs, and general comments. Please test it and leave your feedback as comments on this post or the ticket, #34923. Given current timing the ticket is likely to target the 4.7 milestone.

    One remaining piece to implement is a mechanism to inform the user that their new posts have been published and provide links to edit the posts in the admin. This could take the form of a notifications area in the customizer or preview, or happen inline within the menus UI as a notice using the customizer setting validation feature that’s new in 4.6. UX feedback and ideas for the potential approach here are needed, and it could also probably work to ship without this part for now.

    • chatmandesign 2:23 pm on June 16, 2016 Permalink | Log in to Reply

      Awesome. As a WordPress developer, I setup new sites for clients on a regular basis, and that usually involves creating menus and stubs before I have content. This feature will make that process go much quicker, so while it’s mainly for new sites, it’s definitely not just for new users.

    • FolioVision 2:33 pm on June 16, 2016 Permalink | Log in to Reply

      This really looks like creating trouble where there is none. There are all kinds of dependencies and ugliness which will come out of these zombie pages.

      There’s enough empty and empty headed test WordPress sites out there by clients who don’t want to write an iota of content and really shouldn’t be building websites at all, without us adding to the noise.

      My objection to this of course is not to prevent people from wasting time on dead end web projects – that’s their free choice – but to the amount of effort we will spend and the bugs which will hit core WordPress as a consequence of catering for the absolute lowest common denominator.

      I.e. people who want want a website but have nothing to say (and certainly nothing to publish). Surely we have features and bugs to fix enough for people who are really using their sites as publishing platforms?

      Sincerely, Alec Kinnear

      • Amaury Balmer 3:03 pm on June 16, 2016 Permalink | Log in to Reply

        100% agree.
        The amount of time spent on this feature is crazy …

      • Travis Northcutt 7:24 pm on June 16, 2016 Permalink | Log in to Reply

        Instead of degrading( edited by Jorbin) on someone else’s hard work, why not take action on the “features and bugs to fix” that you mention? Here are all the tickets marked needs-patch that don’t have one: https://core.trac.wordpress.org/tickets/no-patch

        Put up or shut up.

        Sincerely, Travis Northcutt

        • Ipstenu (Mika Epstein) 1:01 am on June 17, 2016 Permalink | Log in to Reply

          Travis, it’s really great you’re so passionate about this, still please remember that everyone should be respectful, even when coming to the defense of others.

        • FolioVision 9:56 am on June 17, 2016 Permalink | Log in to Reply

          As a matter of fact, we do have some code for fixing the very buggy add media buttons but no one can be bothered to even acknowledge our ticket.

          Instead of fixing what’s already written, the mob is running after new features, with you at its ill-mannered head. How about finishing REST API (great idea, huge resources invested already: from what I remember Matt Mullenweg seems to slowing the REST API down as fast as he can) or even Shiny Updates before starting this?

          Sincerely, Alec Kinnear

          PS. I’ve read the more articulate comments below from designers who want to use this feature to build sites. If that’s what this is then the customizer should then be advertised as a page/site builder and not an appearance tool. That’s a huge change in mission and one not to take lightly (those who’ve built site builders in the past will know what I mean). Which only reinforces my suggestion that we marshall all available resources to finish our big open projects before starting something on this scale.

          • Aaron Jorbin 7:52 pm on June 17, 2016 Permalink | Log in to Reply

            There is no patch on the ticket you posted.

            Please also remember that contributors such as Nick are volunteers. While you may not view this as the most pressing issue, Nick has spent a considerable amount of time talking to users and investigating the bottlenecks that they face when using the customizer along with Weston Ruter and others. The customizer is often one of the top examples given of component maintainership. Encouraging its neglect in favor of your prefered projects does not improve WordPress.

            The customizer team developed a roadmap that you found “comprehensive and forward thinking”. This proposal fits two of the identified pieces of that roadmap( “Continue iterating on current live preview features” and “Experiment with a guided new user experience (NUX).”).

            • FolioVision 2:15 pm on June 20, 2016 Permalink

              Aaron, I wrote that comment before the REST API effort blew up in all our faces (just when we thought we were getting a good tool). Again, I’m not saying this enhancement is not of value, I’m saying let’s finish what we started before opening up a new ways to break WordPress.

              Now that someone has noticed our ticket about the media buttons, we’ve supplied the full patch, thank you and it’s been accepted. Viktor was simply not aware of etiquette (supplying patch with bug report). Yet when we’ve supplied patches with 150x performance improvement, bickering and relativism were the result instead of action. WordPress would be a much more solid project if we could clean up lingering issues and open unfinished projects for say half a year before starting major new additions.

              Again, we don’t build low traffic play projects at Foliovision nor do we have many fortune 500 clients with unlimited budgets, we work on SMB sites where stability and performance and security are the priorities. That’s our perspective – real world development and maintenance of complex sites with some resource constraints. That’s our perspective.

              In this case, the customizer is now being morphed from an appearance customizer (original role) to a site builder. In my opinion, it’s not fair play.

            • FolioVision 2:19 pm on June 20, 2016 Permalink

              Why am I being moderated here again? Not being in sync with groupthink gets one moderated? The person here who was offensive is Travis Northcutt who attacked me with expletives for giving an alternative perspective.

              You know my email. It’s attached to our account. You can reach me there to keep this thread on topic.

              Alec Kinnear

            • Aaron Jorbin 7:22 pm on June 20, 2016 Permalink

              1) Your message triggered auto moderation due to having 2 or more links in your response (the default for WordPress). Your account is not being moderated. I’ve opened a ticket since I don’t think multiple trac links should trigger it on this site.

              2) The REST API has not blown up in anyones face. Every piece that has been proposed for core merge has been merged. The endpoints plugin has 20,000+ installs.

              3) Why hasn’t your pet tickets had traction? Likely since there are 100 comment tickets. 23 have been closed thus far for 4.6. When a ticket goes ~3 years without any activity, it often gets deprioritized. Additionally, as noted on the ticket, the 150x improvement you claim may not be true in all instances “With 2,488,928 rows and the comments table on SSDs, the old query ran in 1.2449 seconds. With the new way, the last query alone takes 1.9485 seconds”. That’s not bickering, that’s being considerate of facts.

              If you are looking to better understand the etiquette, the contributor handbook is a great start. It’s a work in progress, so respectfully adding comments about things that are unclear is always welcome.

      • Mark-k 3:31 am on June 17, 2016 Permalink | Log in to Reply

        I actually like the general idea, but it is obviously outside of the badly defined scope of the customizer. Seems like the customizer is trying to leave what its core is – customizing front-end settings and to expend to become the admin interface, because that is the only logical way this kind of features will end up doing.

        If content creation work flow needs to be revised then it needs to be revised in the admin, not sneaked up from the customizer.

        Not actually sure what is the workflow the user is supposed to have here. It sounds like “hmmm I have no idea what content should go there, but I know I will want to link to it” which IMO doesn’t make much sense.

    • Luke Cavanagh 3:18 pm on June 16, 2016 Permalink | Log in to Reply

      I can see this having some use. But most content, page or post is always normally created in the dashboard.

    • Braad 4:36 pm on June 16, 2016 Permalink | Log in to Reply

      Awesome proposal! This feature will be super helpful for me and other developers who create sites for clients. Thank you to Nick, Weston, and all the other people working hard to make the Customizer even better.

    • Morgan Kay 7:52 pm on June 16, 2016 Permalink | Log in to Reply

      I agree that this is a great idea. It will be a big timesaver for people who build sites for clients – one of the first steps in any project is to create a bunch of empty pages that the client will fill in later. It will also make life a lot easier for clients – I know from training dozens (if not hundreds) of people in using their sites that site owners tend to think in terms of menus. I have to explain that first you go create the page, and then you have to add it to the menu. A lot of people will think it is a lot easier to add the page in the menu, and then go fill in the page content.

    • David Innes 8:12 pm on June 16, 2016 Permalink | Log in to Reply

      Building sites menu-first seems like a common style and so this seems like a nice enough idea. You’re going to want to be careful about usability though because the workflow could be complex.

      Based on observations of newcomers some thing to watch out for would a non-zero number of users to

      • create a new page from the menu interface with the expectation that they’d be taken to that page.
      • delete the menu item because it “didn’t work.”
      • recreating the page from the menu interface

      This is not a reason not to implement this change because I think it really will be handy once they get the hang of it. Just something to watch out for during the design and error-checking process.

    • vherring 10:51 pm on June 16, 2016 Permalink | Log in to Reply

      I am a user not a WP developer, although I have been in software development for more years than I care to remember. This kind of feature is fabulous because it starts to make the development of content and design for the average Joe much easier. I applaud this type of change. There is a danger that the WP product will be directed towards developers and not the ordinary content providers. This change is a positive for the content provider. Love it.

    • Ahmad Awais 9:11 am on June 17, 2016 Permalink | Log in to Reply

      Works for me. I think these new features will make Customizer more reliable. Bugs can always be dealt with, since when do we not look into adding new features only coz there will be bugs. #justsaying

    • Niklas 1:46 pm on June 17, 2016 Permalink | Log in to Reply

      A thousand times yes!

      This is great, more often than not when I let customers use WordPress (while sitting next to them) they start by creating the outline of what the site should be like. They go to Appearance → Menus and start typing adding the names of the menu items they want to add. Then they get confused why they need to add links. I think I have had this dialogue four times this year:

      “To where?” they ask.
      “To the page you want to link to” I reply.
      “I want to place my [some page] here” they reply.
      “Oh, they you need to create the [some page] first, because you see if you create the [some page] first then WordPress will automatically keep the URL and menu name up-to-date.” I reply.
      “Oh” they say, somewhat defeated, feeling they did something wrong and were stupid because they didn’t do it the right way.

    • Morten Rand-Hendriksen 6:37 pm on June 17, 2016 Permalink | Log in to Reply

      While I think this functionality is useful, I think the Customizer is the wrong place for it. That also extends to post/page editing btw. Using the Customizer for content creation blurs the scope of the feature by mixing two very different types of tasks into one tool: Customizing the appearance and functionality of a site vs. creating content for the site.

      I can see this type of feature creating a lot of confusion for the end-user, especially those who are not already well versed in how WordPress works.

      IMO for this concept to work, there has to be a clear separation between the Customizer action (creating and customizing a menu) and the content creation action (creating and populating Pages). This separation needs to be both contextual and visual, either by moving focus off the Customizer to a new and different Editor panel, or by enabling in-page/post editing directly in the preview.

    • Jonathan Brinley 8:37 pm on June 17, 2016 Permalink | Log in to Reply

      This seems like it could be a useful tool for a certain subset of users (but I’ll probably have to figure out how to disable it on many sites I build). There are some questions that I think we should ask.

      1. Does this belong in the theme customizer? It doesn’t seem to be related to the customizer’s role of customizing the theme. This is more of a content architecture wizard. Adding it to the customizer distracts from the purpose of the customizer. The wizard could more appropriately live in a separate admin screen focused on laying out your site’s content.

      2. Does this belong in WordPress core? “This feature is aimed primarily at new users setting up their site for the first time.” Then why not have it in a separate plugin that can be activated when setting up a site for the first time, and then deactivated and uninstalled for the other 99.99% of the site’s lifespan?

      • Ipstenu (Mika Epstein) 11:17 pm on June 17, 2016 Permalink | Log in to Reply

        Regarding #2 – Asking new, first time WP users, to install and then uninstall a plugin is a bit much. It would end up with people not using it.

        Perhaps instead say “This feature is aimed at people setting up their site either for the first time or with a new theme.” When someone’s customizing a new theme and realizes “Oh I need this menu item…” would this not be the best place for it?

    • Mark Root-Wiley 6:48 pm on June 19, 2016 Permalink | Log in to Reply

      If people think this feature is appropriate, then the implementation seems ok. Props are due Nick & Weston no matter what. I know they’ve worked really hard on this and I don’t want to downplay that at all.

      I have significant concerns about this issue and I’ll try to productively summarize the reasons below. Pardon the length, but I promise this got written revised, and shortened 🙂

      1. Feature Project?
      I see this feature isn’t listed on the Feature Project list and it feels like applying the “mindset” of the feature project might drastically change the reasoning behind and communication of the feature and subsequently the feature itself. Solely based on how this work has been communicated, I don’t feel like the case has been made for core inclusion yet.

      2. Content in the Customizer
      This is by far the most clear-cut example of pulling content into the Customizer yet. I realize this comes across as a “slippery slope” argument, but this feature seems specifically intended to lead to further content editing in the Customizer later (“establish the wp.customize.Posts namespace for future expansions of post-related functionality in the Customizer”), so I think it’s really important to have a clear vision and rationale at this moment for what the Customizer is and isn’t.

      Iterative development is often great, but this feels like a case where the iteration just feels incomplete and likely to cause problems. (And yet a more full-featured version of post creation in the Customizer brings us back to the more fundamental issues above.)

      The Customizer is currently about working with what you’re looking at, but the primary purpose of this feature seems to be creating new content off screen.

      3. NUX & 80/20
      If the primary use-case is for new users, this feels like a very permanently visible feature. Is the problem this feature solves making a first menu, making a single page, or bulk creation of pages? I think all three of those would have different implementations.

      This feature might help users create a new page in a menu faster than before, but I think it conversely might obscure the post management features in WordPress and actually lead to more confusion down the road. (More on that below.) Creating content in the Customizer feels kind of a like a misrepresentation of what WordPress is and how it’s intended to be used. (I think this is what Morten’s getting at above.)

      Considering all of the above, I don’t see this feature really passing the 80/20 rule, and that makes it feel like plugin territory, not core territory.

      4. Introducing New Problems

      > this usability “dead end” by adding the ability to create new post objects (most notably pages)

      I have indeed observed users wonder why they can’t create new pages for a menu, but I worry that the proposed feature highlights the “dead end” rather than fixes it. It introduces many new “dead ends” too, like ordering, editing, or adding metadata or taxonomy terms to pages.

      If a user makes multiple new pages, how does this ensure they get populated with real content easily? Creating new blank pages is fine on a development site, but what if people create a bunch of blank pages on a live site in order to fill them in later? Are we doing them a favor by making this “easy” but leaving lots of blank pages up on a live site? Does this feature accidentally encourage “Coming Soon” pages? (Those animated GIFs were amazing, but I’m serious about the question.) David Innes’s concerns above are along similar lines.

      Possibly the #1 question I would want from a usability test is, “Do users understand what they’ve just created?” If a user adds a new Page, do they know to find it on the “All Pages” admin screen? Does this make the concept of different post types too abstract if they are all just initially conceived of as “menu items”?

      I’ll end with a quote from the incredibly smart Karen McGrane in her A List Apart article “WYSIWTF”:

      “Inline editing encourages content creators to focus on the visual presentation of the desktop interface. Just at the moment when we need content creators to think about the underlying structure, we’re investing in tools that obscure the ‘connective tissue.'”

      I think this feature obscures the “connective tissue” of WordPress. This may solve one specific real problem in a positive way, I am just seriously concerned that it creates too many new ones in its wake.

      • Nick Halsey 12:34 am on June 20, 2016 Permalink | Log in to Reply

        Thanks for the thoughtful comment.

        This feature is not about content creation in the customizer. It’s about content creation in the menu management workflow. The customizer offers the added bonus of live preview in this case, but is not the primary focus here. We shouldn’t be asking any questions about whether the customizer is the right place for creating content; rather, the question is whether it makes sense to be able to create content while managing menus.

        If there’s an appropriate path to then edit that content (in wp-admin), I think that content authorship in menus makes a lot of sense for a variety of workflows, particularly because menus offer a chance to develop a site’s structure more holistically with pages, terms, hierarchy, etc. than what the pages list table offers. This could actually improve understanding of different post types and taxonomies because it provides a chance to see how those objects can interact with each other to shape a visitor’s experience.

        In terms of process, this is not a particularly large feature and with the difficulty that we have getting contributor interest/activity in general customizer meetings/tickets/etc., I don’t see any way that we could justify starting a feature project solely to look at content authorship in menus. However, I’m hoping we’ll be able to build up enough interest to start a project focused on next steps with live preview in core at a broader level, as mentioned in the post.

  • voldemortensen 11:13 am on June 16, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: June 15th 2016 

    This post summarizes the weekly dev meeting on June 15th, 2016.

    Update on WordPress 4.5.3

    Still targeting Tuesday, June 21st 2016 at 14:00 UTC.

    Feature project updates

    Font Natively

    @helen updated the system fonts ticket with screenshots of the test page. The ticket still needs a few more screenshots and a patch for font-weight.

    Directly after the meeting @coderste submitted a patch for the remaining font-weight issues.

    Shiny Updates

    The results of Monday’s Shiny Updates meeting gave a partial merge approval. The commit was made today [37714]. Congratulations to the Shiny Updates team and all who were involved in any way. @swissspidy is going to lead the project for the rest of the cycle.

    Dev notes and initial field guide planning

    The Field Guide is an effort that the Core Team make each release to inform developers about important changes in the release. The Field Guide is made up of links to individual posts known as dev notes. Dev notes include things like new features, changes to watch for, and potential areas for breakage. As an example, here is the Field Guide for 4.5: https://make.wordpress.org/core/2016/03/30/wordpress-4-5-field-guide/

    Please note: dev notes do NOT need to be written by committers. Someone can work with first time authors to help them feel comfortable writing a post. If you would like to contribute to the 4.6 Field Guide please speak up in the #core Slack channel and someone will help you on your way.

    Topics that need dev notes and their potential authors:

    WCEU Contributor Day

    For the #core group there are currently ~140 signups. 20%-40% of these signups are new or not an experienced contributor (yet 🙂). Contributor days are meant to change that.

    Review handbook pages and good-first-bug report

    In order to effectively help those seeking to begin contributing to WordPress, both the contributor handbook pages and the good-first-bug report need to be reviewed and refined. These help guide new contributors in finding something to work on and properly submitting a patch.

    @lukecavanagh showed interest in helping with reviewing the handbook pages.

    Workshop about preparing a dev environment for core

    The core group is going to be huge and it will be way more productive for everyone if there was someone experienced to help new people set up their dev environments. The WCEU team is looking for someone (with a backup) to lead a workshop about preparing a dev environment for core. @adamsilverstein volunteered to help with the workshop. @jeremyfelt is going to help if any issues come up with VVV.

    If anyone else is interested please contact @_dorsvenabili or @petya.

    Component announcements/updates


    Open discussion

    • #12706 needs some eyes and an architectural decision before it can move forward. It may be a good candidate for a feature project.
    • In 4.5, the login <title> structure was fixed, but the admin pages were missed. #35774 aims to fix that.
    • #34923 is seeking feedback for accessibility, design, code review, docs, and general comments.
  • Eric Binnion 9:02 pm on June 15, 2016 Permalink |
    Tags: ,   

    Week In Core, June 7 – June 15 2016 

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

    • 62 commits
    • 67 contributors
    • 61 tickets created
    • 15 tickets reopened
    • 80 tickets closed

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

    Code Changes



    • Set a defined line-height for number type inputs to fix display issue in Safari. [37693] #37024


    Bundled Theme

    • Twenty Ten: Revert pot changes after update test.[37715]



    • Do not flag a comment as a duplicate if the comment_author_email is provided but not a match. [37713] #37093
    • Fix pagination totals in the response of the inline delete actions when filtering the List Table by comment_type. [37664] #36991


    • Ensure MediaControl fetches the necessary attachment data for rendering when dynamically added via JS. [37701] #36521
    • Update server-sent setting validation notifications as changes are entered. [37700] #36944


    • Prevent jumping when using the backspace button in the Text editor in Firefox and IE. [37684] #37072
    • quickTags: when the user selects some text by triple-clicking, then wraps it in a tag, and the last selected char is \n, insert the closing tag before the line break. [37661] #29571
    • Adjust the sidebar position when moving a postbox from one column to another. [37659] #35230



    • Docs: Add extensive documentation to the remove_accents() DocBlock outlining the accented characters core replaces. 37669] #34677


    • After [37702], correct the expected result in test_size_format(). [37705] #37037
    • In size_format() and wp_convert_bytes_to_hr(), replace kB with KB for consistency with other units. [37702] #37037
    • Docs: Replace HTTP links with HTTPS. [37674] #36993
    • Docs: Improve the DocBlock summary for add_theme_support(). [37673] #32246
    • Docs: Add documentation for the variadic second parameter, $args, accepted by add_theme_support(). [37672] #37067
    • Docs: Improve documentation for the $feature parameter in the DocBlock for add_theme_support(). [37671] #32246, #37067



    • Revert the test added in [37716], as it causes errors when running the full suite. [37718] #36790
    • Adjust the regex in wp_maybe_decline_date() to handle word boundaries correctly. [37717] #36790
    • Add a unit test for wp_maybe_decline_date(). [37716] #36790
    • Add context and translator comments to Back to %s strings. [37703] #37095
    • In remove_accents(), add support for de_CH and de_CH_informal. [37698] #37076
    • Simplify the WordPress update notice for translators. [37675] #35721

    Login and Registration

    • Fire wp_no_robots() in wp_die() only if function exists. This covers cases where wp_die() is used before general-template.php is loaded. [37689] #34401


    Networks and Sites

    • Docs: Update the documentation for get_site() and the get_site filter following the removal of the $output parameter in [37652]. [37699] #35791
    • Use to_array() method on WP_Site objects in wp_get_sites(). [37667] #36717
    • Introduce get_current_network_id(). [37670] #33900
    • Tests: Split get_blog_details() test into individual tests [37666] #36566
    • Tests: Move get_blog_details() tests to their own file [37665] #36566
    • Tests: User a data provider for wp_get_sites() tests. [37662] #36566
    • Tests: Move wp_get_sites() tests to their own file [37660] #36566
    • Avoid a PHP notice in get_permalink() if default category is unavailable. [37707] #36529


    • Normalize WP_PLUGIN_DIR in the test added in [37332], otherwise it fails on Windows. [37719] #29154
    • Fix edge-case where the tab=upload page can be accessed directly. [37681] #35429

    Posts, Post Types

    • Docs: Improve the return description for wp_get_post_categories() to include more information about possible return values. [37686] #37002


    • After [37692], don’t skip set_found_posts() when no posts are found. [37712] #36687
    • Allow plugins to supply post results instead of having WP_Query fetch them from the database. [37692] #36687
    • Docs: Improve first-order clause documentation for the $meta_query parameter in the constructor for WP_Meta_Query. [37688] #32659


    • Introduce a redirect_term_location filter to change the redirect on term editing. [37696] #36367
    • More specific cap check when processing category data on post save. [37691] #36379
    • Introduce term_taxonomy_id parameter for WP_Term_Query. [37683] #37074
    • Tests: Move WP_Tax_Query tests to a more appropriate file. [37682] #37074

    Text Changes

    • Text Changes: Simplify two strings in wp_password_change_notification(). [37704] #35736


    • Make default “read more” link more accessible. [37706] #36572




    • Embeds: In WP_oEmbed::get_provider() and WP_oEmbed::get_html(), parse the $args string to an array, as we treat it as an array later. [37720] #37071
    • wp_signon() expects an array as the $credentials argument, not a string. [37697] #37071
    • Stop WP_List_Table notices from persisting on pagination navigation. [37663] #35620

    Thanks to @flixos90, @adamsilverstein, @AdamSoucie, @afercia, @afragen, @alexvandervegt, @azaozz, @boonebgorges, @dashaluna, @dd32, @dlh, @DrewAPicture, @EFAREM, @ethitter, @flixos90, @grapplerulrich, @Ipstenu, @iseulde, @j-falk, @jeherve, @jeremyfelt, @jipmoors, @jnylen0, @joelwills, @joemcgill, @john_schlick, @johnbillion, @johnjamesjacoby, @johnpgreen, @joostdevalk, @jorbin, @JoshuaGoodwin, @azaozz, @jpdavoutian, @Kau-Boy, @khag7, @kraftbj, @mapk, @melchoyce, @michael-arestad, @obenland, @ocean90, @odysseygate, @pansotdev, @paulwilde, @pento, @peterwilsoncc, @Presskopp, @rachelbaker, @ramiy, @ramiy, @rmccue, @ronalfy, @ryelle, @semil, @SergeyBiryukov, @simonvik, @spacedmonkey, @stephdau, @svovaf, @swissspidy, @TimothyBlynJacobs, @tlovett1, @westonruter, and @zakb8 for their contributions!

  • Jeremy Felt 6:51 pm on June 15, 2016 Permalink |
    Tags: , , network-sites   

    Multisite Office Hours Recap (June 14, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @flixos90, @spacedmonkey, @jeremyfelt

    Tickets Covered

    • #36675, WP_MS_Sites_List_Table should use WP_Site_Query. This is almost ready and should also close #33185, #24833, and #21837. Soon after an effective patch can be written for #26580. Available search columns in WP_Site_Query will remain as domain and path. Once everything is in, an assessment can be made on the usefulness of searching custom columns on the wp_blogs table.
    • #35791, WP_Site_Query has a patch that will go in before the above so that search columns are available. Most of the functions mentioned in the ticket description have been updated to use get_sites(). New tickets should be created for the replacement elsewhere in core.
    • #36935 implements lazy-loading of site details in WP_Site and will go a long way towards the—possibly silent—deprecation of get_blog_details() in core. It implements a new global cache key (site_details) that will help clear up some of the issues that come with the blog-details cache key. Once this is in, get_blog_details() can be replaced almost everywhere. See #37102 for that progress.
    • #36717 is still in temporary limbo. The private blog_id and site_id properties will likely need to be made public again, but there remains a sliver of hope that this can be worked around inside get_blog_details() for the time being. If it’s still in for beta, it will mostly be for testing.
    • #32504WP_Network_Query still has 2 weeks before beta. A patch and tests are already there, so there’s a high chance it can go in this week.

    If you aren’t available during the weekly multisite office hours, feel free to leave a comment here or in #core-multisite with a ticket number you’d like to see discussed.

    See you next week!

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar