Make WordPress Core

Updates from September, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • 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 …)

  • Weston Ruter 2:00 pm on September 23, 2015 Permalink |
    Tags: , ,   

    Outlining a possible roadmap for the Customizer 

    Planning for the future is a necessary and important part of the WordPress development process. As we consider the future of WordPress – both as a whole and individual features – we publish proposed roadmaps to encourage greater discussion and give insight into the core team’s thought process.

    The process of creating a roadmap is just as important as the vision behind it and the final roadmap itself. This process gives the entire community an opportunity to research and document history, define what specific items can be accomplished to bring us closer to the vision, and outlines how those tasks fit together within a possible timeframe.

    What follows is a potential roadmap for the Customize component. If you’re interested in the future of live preview in WordPress, now is the perfect time to get involved and leave your feedback.

    A couple of months ago, the WordPress lead developers met with the maintainers of the Customize component to discuss the future of live preview in WordPress. The goal of the chat was to come up with a potential roadmap for both the component and for how live preview can improve the user experience of WordPress for all users.

    The ultimate goal of live preview in WordPress is to create user trust and remove the “save and surprise” inherent in some of the backend features.

    After a lot of discussion, the group decided to target the following goals over the next two years:

    • Considerably improve performance.
    • Continue iterating on current live preview features to ensure they are solid and as easy-to-use as possible, including theme browsing and installation, menus, and widgets.
    • Experiment with new and different user interfaces. If we were creating live preview today, what would it look like? In what ways can we ease the feeling that you’re looking through a “porthole”?
    • Removal of the ambiguous mode. Currently, the Customizer is contained in a sidebar without the admin toolbar, but ideally there is the admin and the theme, and no in-between. One direction this may go is enabling “Customize” on the front end to immediately load the Customizer controls.
    • Experiment with a guided new user experience (NUX). Live preview lends itself to site setup. How can we improve the live preview experience and combine it with the NUX? Consider a “setup wizard” use case and ensure the flow has no dead ends, i.e. users can customize everything in one.

    Those overall goals for live preview in WordPress can be rewritten into some specific features that are in development or planned for the future of the Customize component. These include:

    • Transactions. This re-architecture of some of the Customizer internals improves compatibility with themes by loading the preview using a natural URL, and allows Ajax requests or even REST API requests to be previewed. It also allows the preview to be viewed independently of the Customizer, so changes can be shared for others to review. See #30937.
    • Selective refresh. Only a piece of the page will need to be refreshed when this backend feature is implemented. (Formerly known as “Partial Refresh”.) Currently, this is available for menus in the Customizer. This eliminates duplication of display between PHP and JS, keeping it DRY. See #27355.
    • Concurrency. Allows for “locking” settings using the Heartbeat API, improving the overall user experience by preventing users from overwriting each other’s changes. See #31436.
    • Revisions. Enables plugin developers to add features like draft, roll back, and scheduled changes (e.g. “change my background on January 1”). This builds upon transactions, as the setting changes are staged in a transaction, and this facilitates settings to be revisioned and for settings to be scheduled. See #28721, #31089.
    • Theme installation. Iterates on and completes the theme browsing experience.
    • Responsive preview. Iterates on the concept of live preview by giving users a better idea of what their site will look like on other devices. See #31195.
    • Bootstrapped Customizer. Lazy-load the Customizer into the current frontend view without having to leave the page. With selective refresh implemented, inline controls and frontend bootstrapping would be possible since full-page refreshes would no longer be required.
    • Improvements for both touch and small devices.

    Beyond those features, the group identified some specific changes that should be prioritized, in conjunction with the features planned:

    • The sliding animation between panels should feel more like “moving panels” (see: iOS).
    • Keyboard navigation should be consistent and clear.
    • Identify “dead ends” in the interface and remove them, when possible. For example, prior to menus in the Customizer, it was not possible to customize that aspect of your site’s design with the Customizer.

    The concepts surrounding live preview and the Customizer have been in development for a long time. Many of the concepts from Elastic Theme and the Visual CSS Editor have been incorporated over time. Over the next few years, experimentation with these concepts will likely take place in feature plugins. For example, this team may experiment with inline content editing, where it makes sense in the context of customizing a site. Another path for exploration is simple theme customization – e.g. change the header font, change the sidebar color, or change the width of the sidebar.

    As with all components and new features, we shouldn’t be afraid to experiment and fail and should continually push for new experiments and ideas, especially in the context of feature plugins. Further, some of the above experiments may not make it into core, but are meant as a general direction that live preview should take in WordPress.

    Taking these features together, below is a sequence outlining a possible roadmap for live preview and the Customize component in general, along with estimated targets. Please note that this is a proposed roadmap and is entirely dependent on contributor involvement. Additionally, many of these things will take place in a feature plugin prior to core inclusion.

    • Partial refresh. Performance Improvements. (Target: 4.4)
    • Responsive Preview. Transactions. (Target: 4.5)
    • Concurrency. Revisions. Theme Install. Beginning of NUX wizard. (Target: 4.6)
    • Focus on touch screen / small device improvements. (Target: 4.7)
    • Developer API improvements based on feedback from plugin developers. (Target: 4.8)
    • Improved UI after experiments in 2016. NUX “wizard mode.” (Target: 4.9)

    Live preview is one of the most critical features in WordPress as we continually combat “save and surprise.” The Customizer in its current form provides an improved user experience to WordPress users when customizing their site’s design. Each feature mentioned above is a continuation of the live preview concept, building and improving upon the Customizer.

    Everything above is just a proposal and we need your feedback to ensure it is the right direction. If you’re interested in any of the above, comment here with your feedback, or join the team in #core-customize.

    This post was a collaboration between @helen, @nacin, @mark, @celloexpressions, @samuelsidler, and yours truly.

    • Davide 'Folletto' Casali 4:46 pm on September 23, 2015 Permalink | Log in to Reply

      > NUX wizard

      I find a bit dangerous to think of it as a “wizard”, mostly because usually wizard UIs have specific connotations. We should think of it more as a “tutorial” like games do. Not separate UIs, but a guide through an existing UI that can be dismissed if you’re expert, or done partially, or followed all along. :)

      Other than that… this seems AWESOME. :)

      Performance is really the main thing there. That alone would reap huge benefits. Then you add Live Preview and well, boom! :)

    • Daniel Bachhuber 6:11 pm on September 23, 2015 Permalink | Log in to Reply

      We (Fusion) are very keen to adopt the Customizer as the UX for frontend management, and look forward to helping out with the feature plugins built as a part of the roadmap.

    • FolioVision 12:43 am on September 24, 2015 Permalink | Log in to Reply

      Weston, thanks for the comprehensive and forward thinking report.

      It would be great if the interface paradigm for Customizer would remain constant for the exterior world (i.e. agencies and clients) while a dev version gets tested by the more progressive among us.

      Perhaps a switch to throw in settings to enable experimental Customizer features? The switch could be retired when Customizer settles a bit.

      • Weston Ruter 4:05 am on September 24, 2015 Permalink | Log in to Reply

        @FolioVision yes, absolutely. This is why most of the new features will be developed in feature plugins so that they will remain opt-in until they are deemed solid for everyone.

    • devolute 4:05 pm on September 25, 2015 Permalink | Log in to Reply

      but ideally there is the admin and the theme, and no in-between.

      Here here! Does this mean that there will be a “front-end” mode, and a “dashboard” mode that fits into the current dashboard so that things can be altered without a preview being available?

      • Weston Ruter 4:16 pm on September 25, 2015 Permalink | Log in to Reply

        @devolute Basically the idea is that there would no longer be a separate “Customizer” URL (wp-admin/customize.php) that you go into. When on any frontend URL, clicking “Customize” would just slide out the Customizer sidebar pane in place. You’d still have the admin bar available and everything else that you would normally when on the frontend, except you’d also be able to make changes to the Customizer as you browse around. So no, this doesn’t have in mind making the Customizer controls available in the wp-admin without a corresponding preview.

        • devolute 4:19 pm on September 25, 2015 Permalink | Log in to Reply

          Ah, I understand your intention. I think my problem is that I’m using the customizer for things like phone numbers, addresses and other options when I perhaps should look at other solutions.

    • Ahmad Awais 3:38 pm on September 26, 2015 Permalink | Log in to Reply

      We at WPTie are slowly yet gradually adopting Customizer in all our themes and plugins (where needed). All in for customizer support in WordPress.

    • Alex Mangini 10:23 pm on September 28, 2015 Permalink | Log in to Reply

      On the “Bootstrapped Customizer” point, is this a move towards inline content editing and possibly even “page builder” type concepts?

      My biggest curiosity about the Customizer and what I really want to use it for as a developer is creating posts and pages without a 3rd party visual editor and without the drawback, as already stated, of guessing what they’ll look like after inputting content into specially built meta boxes or widgets.

      Thanks for doing these write-ups, as I build more and more WordPress plugins/products I find myself lurking around here to better educate myself and plan roadmaps for my own work.

      • Weston Ruter 10:45 pm on September 28, 2015 Permalink | Log in to Reply


        On the “Bootstrapped Customizer” point, is this a move towards inline content editing and possibly even “page builder” type concepts?

        This is already possible, actually. For an example of inline editing, see the Customize Inline Editing plugin. And page builders are also possible now by using widgets in the Customizer. I’m currently working on a site that uses a concept of query-specific widget areas to allow every URL to have custom sidebars configured, where the main content area is just another widget area: this allows drag-and-drop building of pages just with standard widgets and any custom widgets that you define. Widgets still have a lot of room for improvement in Core, but I’m very keen to see them move in the direction of “content blocks” which can be used for building page templates in the Customizer.

    • Nick Halsey 4:19 am on September 29, 2015 Permalink | Log in to Reply

      Thanks for getting this published Weston.

      A couple of additional comments on my end:

      • We need more help. The Customizer can do (and could do) a lot, but without more contributors (not just code), it’ll take time to see big improvements go through. I’d love to see more of an effort to embrace the Customizer throughout various other core projects, and to see more community involvement in Customizer design and development.
      • In the interest of experimentation and building on the benefits of live preview, I’m planning on looking at some ways to integrate things like page templates, post formats, and featured images (with cropping) into the Customizer. While there’s a good chance none of those things will make it into core, I’d like to encourage anyone with any ideas for the Customizer to try them out and offer them for discussion. We’re no where near the limit of what users could do with the Customizer and it’s an amazing framework to build additional features on top of.
      • While many of the topics in the post are fairly developer/backend oriented, it’s important to emphasize that there is still a significant amount of design and UI/UX work to be done, including looking at entirely different approached to the live preview UI concept. Don’t be shy to share your ideas if you have any – the technical side of things is evolving to support pretty much anything we may want to try.
  • 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!

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

  • Helen Hou-Sandi 7:00 pm on August 26, 2015 Permalink |
    Tags: ,   

    New committers for 4.4! 

    It’s that time again… Please join me in welcoming Tammie Lister (@karmatosed) as a guest committer for WordPress 4.4. There’s another committer to be announced, but we thought we’d wait until he’s back from vacation for a proper welcome.

    You may recognize Tammie from her role as an admin on the theme review team, and she’s also a theme developer extraordinaire at Automattic. Tammie will be heading up development of the new default theme, Twenty Sixteen.

    The lead developers review and appoint new committers to serve each release cycle, often to work on a particular component or feature. This guest commit access comes up for review after each release and can be renewed. Ella Van Dorpe, Konstantin Obenland, and Weston Ruter, all new committers at the beginning of the 4.3 cycle, have been renewed for 4.4.

    Over the last few cycles, both Aaron Jorbin and Jeremy Felt have been working through long-term plans, smashing through tickets, and improving the entire codebase, especially when it comes to tests and multisite. I’m happy to announce that both are now permanent committers. Please join me in congratulating everyone!

  • Scott Kingsley Clark 4:15 pm on August 3, 2015 Permalink |
    Tags: ,   

    Fields API: Request for review of direction 

    Over the past many months this year, I have been working with guidance from @helen on the new Fields API with the intention of inclusion into WordPress core. It’s based on the Customizer API, so those who have experience with it will see a lot of similarities. The goal isn’t to create a duplicate API though, and in our proposal we would be implementing the Fields API within the Customizer API.

    What does that bring to core as a whole? It gives core a very real and far reaching API to add fields to any type of object in a standard interface. Given the growth of the Customizer API and its inclusion of fields, @helen and I both agreed it’d be great to leverage everything it can do in our efforts here. The goal isn’t focused on the actual Customizer UI or editing on the front-end, it’s all data-oriented.

    We would create implementations behind the scenes in the various existing APIs such as the Customizer API (now) and Settings API (later) while maintaining backwards compatibility. We’re also hoping to implement the Fields API within the User profile screen. This would give core more flexibility towards revamping the User profile screen in the future, without having to tackle even more than just a UI refresh. That’s also not mentioning the fact that plugin and theme authors could leverage this API to extend WordPress with their own fields in the various areas. Future places we’d look at integrating Fields API with would be the Post editor, which I’ve pegged as our third focus, behind User profile fields and the Customizer API.

    Anyways, that leads us to the point we’re at now, we have an API but we don’t have all of the built-in Field Types (control types) yet or the latest Customizer API changes from 4.3 merged upstream into the Fields API. There are unit tests that are running (and passing!) so that is going to help us on our road towards core for sure.

    We need developers to give their feedback on the direction we’re heading. Here are the relevant links for those reviewing:

    I’d love more feedback from anyone contributing to WordPress, or the *countless* plugin and theme developers who would use the Fields API. Please comment on this post, or if you’d like to discuss further, you can hop into our weekly meetings on Mondays (Monday 20:00 UTC 2015) in the WP Slack #core-fields channel, or ping me there anytime.

    Update – 08/10/2015:

    We now also have a growing list of developers who are behind this project and would implement it in their projects if it were merged into core.

    • Matt Gibbs 4:48 pm on August 3, 2015 Permalink | Log in to Reply

      Thanks for all the hard work, Scott and Helen! The specifications doc looks very detailed. I’d like to see more usage examples though. Similar to the one on https://make.wordpress.org/core/2015/05/27/metadata-api-project-reborn-the-new-fields-api-project/

      1. How to create custom field types (or Controls as its called now)?
      2. Does a field require a section?
      3. What happens if the field capability isn’t set? Does it fallback to the parent section / screen?
      4. How are repeatable fields handled in the current spec?
      5. Is the field API itself concerned about field order? Should it be?
      6. How granular are field sections? E.g. can a field be added to a single post item (or user) only?

      • Scott Kingsley Clark 5:55 pm on August 3, 2015 Permalink | Log in to Reply

        1. We’re still ironing that part out, control types / field types is the next area of the spec we have to nail down. Feel free to join us on Mondays for our weekly meetings if you want to help us get that part finished.

        2. Currently, it functions the same as the Customizer API, which allows you to add as many fields as you want, without sections or screens (panels). The differentiation is when you add a control, you specify the section or screen you want to add it to.

        3. Fields don’t require capabilities, controls don’t either. We handle the same capabilities checks as the Customizer API does right now — https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-customize-setting.php#L439 — which is to say, if you don’t provide a capability check, it is wide open. We should nail this down further and I think it’d be good to default to no-access. We need dev input on that.

        4. There is no preparations for repeatable fields or repeatable groups at the moment, that’s something we want to nail down in the control types / field types discussion, as there may be things we want to do there. The existing Fields API spec is almost entirely based off of the Customizer API and no additional functionality has been added for that yet. It’s on our list though, we want to ensure any effort we put forth into core does not limit developers or the common ‘loop field’ use-cases. Whether ‘loop fields’ go into core or not, that’s not something I can speak to at this point.

        5. Yes, the spec makes use of the ‘priority’ option for screens, sections, and controls. Works just like filter/action priorities do.

        6. Screens, sections, controls, and fields are all added to a specific object type / name (for example: post type : post). Further definition based on a conditional like a specific ID, capability, etc, could all be handled through an additional callback or filter that we can add inside of the check_capability methods for screens / sections / fields.

    • Brent Jett 8:23 pm on August 3, 2015 Permalink | Log in to Reply

      Cool spec! I like the idea of a broad-reaching common syntax for adding fields from themes/plugins, but I’m wondering if there isn’t a more modern/human-readable format or syntax for this. My immediate thought was JSON files (OOP code underneath obviously). WordPress exposed object oriented API so late in it’s relative lifespan that OOP code like the customizer API still looks very foreign to themers. Given that most app platforms now use JSON manifest files to declare things like configuration, it would seem to me very natural for WP to look at adding a more approachable syntax like that to it’s theme configuration APIs.
      But I could be way off. Nice work either way.

    • Mike Nelson 10:14 pm on August 3, 2015 Permalink | Log in to Reply

      In Event Espresso we created a similar system called the “Forms System”, inspired primarily by Django’s forms. EE Forms basically define how to display an HTML form, how to validate the user-provided input on both the client-and-server side, and how to sanitize/normalize the data for use in the PHP code. (It leaves the job of saving data to either our models system, wp options api, and sometimes direct wpdb).
      EE “form sections” are roughly equivalent to your “screens” and “sections”, and EE “inputs” are roughly equivalent to your “controls”.
      Some differences that might spark some ideas for you:

      1. EE form-sections are nestable; so you can have sub-sub-sub-sections etc. This has allowed for more re-use. Eg, say you wanted to have screen section for multiple post custom fields: the “custom fields” would be a section, and then it would have a different sub-section for each post custom field.
      2. Each form section can have its own “layout strategy”, a separate class that dictates how to layout the form section’s inputs in the HTML, and its sub-form-sections. So if you want to layout your form’s inputs in a very standard way, you’d select one of the pre-set layout strategies.
      3. If you want to layout your forms input in the HTML in a very custom way, template code can be passed a form section which gives the template code access to the sub-sections and inputs and the template code can dictate where to place what
      4. sub-sections can actually just be chunks of HTML, “html subsections”. These have been good for extra stuff that’s important for the display of the form, but aren’t necessarily related to form-data
      5. the EE forms system is separate from our “model system”, although they’re sometimes related. The forms system is primarily focused on displaying HTML forms, and then validating and sanitizing the user’s input; whereas the models system focused on defining the underlying data stored in the database, how that data is related to other data, how to save and retrieve that data, etc. We have a form section base type that can automatically create sub-sections and inputs based on a particular model.

      Other than that, it’s really quite similar.

      Also it’s not that clear: is the fields API intended for use in the frontend too?
      Also it seems if this is intended primarily for defining the HTML forms and how they get validated/sanitized. I think having a separate API for defining the underlying data would be beneficial, in cases where you don’t want every attribute of the data to necessarily be represented in HTML forms, or you might want to provide different forms for editing the same underlying data.

      • Scott Kingsley Clark 4:16 pm on August 4, 2015 Permalink | Log in to Reply

        1. I’d like to explore the idea of sub-sections and sub-fields (sections that can have sections in them, fields that can have fields in them) in our class architecture. Even if they’re not utilized in core, the ability to use them or for plugins to enable their use would be a big thing.

        2. We’re looking at something similar, though not really, it’s mainly that each screen will have it’s own fields display and saving implementation, much like the Customizer itself has one.

        3. There are filters and actions in place for this right now in the Customizer and the Fields API

        4. I don’t doubt someone could extend the Fields API with a new control type or a custom section class that would be able to output just HTML as set in the definition options. That could be useful for some cases.

        5. Fields API is based on the Customizer API, it’s somewhat split up between modeling and display, but it’s not entirely MVC at the moment.

        6. You can use the Fields API anywhere, you would write your own implementation to display fields and process the $_POST data accordingly, utilizing the underlying Fields API to access the data structures and field types input HTML etc. You could even use the Fields API for any object type you want to build into it, there are hooks in place that support custom object types, for purposes of plugin developers to utilize the Fields API for their own things (Gravity Forms, Pods, NextGen Galleries, etc).

        7. Each implementation can override the core output, to do whatever it wishes. For instance, Customizer API supports previews and makes heavy use of JS to do what it does. Our Customizer API implementation extends the Fields API but does not limit the ability for those things, and many others for other implementation needs.

    • thomask 11:02 pm on August 3, 2015 Permalink | Log in to Reply

      I am really looking forwards to this, actually for me this is the second most crucial missing feature for WP – the first is multilanguage support. I use Advanced Custom Fields for almost every web i do, and however it is very nicely written and easy to use, i would prefer some build-in support.
      I have read it all just briefly and will have to try it, from my experience what is important is
      1. support for multilanguage fields (so that i can have common field for all languages version of one post, as well as translatable field) – but this is i guess more question on the multilanguage plugin (or future WP multilanguage support)
      2. text field (just simple text), term fields and post field (N:N relation field), wysiwyg field, user selection field … and/or easy way how to create new field types with standardised look, values control etc.
      3. allowed values control and definition, read only possibility, required field possibility
      4. possibility to add fields also to terms (!!!) – imo terms (edit-tags.php) are currently very stupidly different from the posts – it should have the same look, so that we could use the same fields and functions.
      5. easy definition of post types and other conditions, that are required for field to be displayed
      6. advanced feature, but very usefull in many cases – possibility to set-up condition for field, that should be calculated live on the post screen depending on some live changes – e.g. “this field should be visible only when category is “blabla”).
      7. field could be added also to attachments – but dont forget, that it does not have only the standard post.php, but that the fields are displayed also on the attachments popup screen
      8. dont forget the field versioning (with older version of post you see also older version of its fields)
      9. posibility to create groups of the fields with their conditions
      10. possibility to e.g. display fields in two columns
      11. very advanced field – repeater field (e.g. something like this http://www.advancedcustomfields.com/add-ons/repeater-field/) – possibility to create field table. This is very complex, but very often this is the only way how some things can be solved, as currently there is only simple ID->key->value in WP, but very often you need ID->key->array(subkeyN->valueN), so without this field type many users will still have to use some solution as advanced custom fields.

      • Scott Kingsley Clark 5:26 pm on August 4, 2015 Permalink | Log in to Reply

        1. That sounds great, it sounds like Fields API could enable this through the options you pass into the configurations. A plugin could pick that up and change how the fields work from there, per language.

        2. That’s on the list at the moment

        3. Good ideas, we’re still nailing down the specs but those are two I’d like to see us tackle if possible — it’s just going to be difficult.

        4. Not currently possible, but when Term meta makes it’s way into core, this Fields API will be there to utilize :)

        5. Sounds great, I’m not sure how much of this we’ll tackle in the Fields API itself, but it’ll definitely be doable by a plugin.

        6. That also sounds great, plugin material though — but enabled by our extensible code.

        7. This sounds great too, it’s not part of our initial focus but there are hooks in place that we could implement this for media fields as well.

        8. This isn’t a problem, everything operates by ID, revisions get their own ID, so everything should continue to work there, even when post meta revisions makes it’s way into core.

        9. Groups of fields are possible, but conditions is currently plugin territory.

        10. That sounds like plugin territory, but totally possible because we have hooks for that.

        11. I love the idea of a loop field or some basic repeatable field in core, not sure if we’ll include the field type itself in core but we’ll do everything in our power to enable developers to make use of it in the numerous plugins that have this field type as an option.

    • camu 1:16 pm on August 4, 2015 Permalink | Log in to Reply

      Thank you for all this work. I was wondering, why not just merge Advanced Custom Fields into core? It’s a robust plugin that already does most of the things listed here above. I’ve been using it for years now, and it has always delivered.

      • Scott Kingsley Clark 4:04 pm on August 4, 2015 Permalink | Log in to Reply

        There aren’t any plugins that could be a candidate to merge into WordPress core right now as they are, this Fields API effort is our focus right now to make a better API for custom fields plugins out there to utilize for a better standard when developing for WordPress. What we’re doing here wouldn’t replace custom fields plugins for many developers, they add features that are useful for some projects and offer an admin UI to manage these things. At this point, the focus is not on creating an admin UI to manage custom fields for objects in WordPress, but to offer up a unified API to interact with fields for all object types.

        • khromov 4:53 pm on August 4, 2015 Permalink | Log in to Reply

          From reading the post, the proposed direction is very similar to what ACF offers. There will be edge cases that the new API won’t fill right away (ie. repeatable fields), but it’s something the community is going to want and build.

          My point is, don’t understimate the will of the community to bend this to their particular use case. A good design (which it looks like so far), enables that.

          • Scott Kingsley Clark 4:57 pm on August 4, 2015 Permalink | Log in to Reply

            Totally agree, this is actually the result of lots of communication between many developers of plugins / libraries for building custom fields. There’s no way I would underestimate this community, was just noting that none of the plugins were a direct fit.

    • christopherabalos 7:49 pm on August 4, 2015 Permalink | Log in to Reply

      Very interesting take on a much needed API. The WordPress API for creating metaboxes, post types, taxonomies, customizer fields, widgets, etc are in need of a uniform API. I’ve been attempting to tackle this the last few months in my own projects. My implementation revolves around new manager classes for things like post types and settings that follow a pattern similar to the Customizer API. My manager classes have been written to accept WP_Customize_Control objects.

      I’d also like to see the ability to create fields for widgets, which is something I’ve included in my implementation.

      I’m curious to hear more about the decision to wrap the fields API into a single manager vs. having separate managers that all accept the same field objects.

      Keep up the great work Scott!

      • Scott Kingsley Clark 3:21 pm on August 5, 2015 Permalink | Log in to Reply

        Widgets is totally a logical next step in this, I would love to see Fields API used for Widgets, for the Shortcode UI project, etc.

      • Scott Kingsley Clark 3:24 pm on August 5, 2015 Permalink | Log in to Reply

        One manager class is based on the Customizer API structure. I ended up going with one class so that there was one class things would be used to interact with, stored screens/sections/fields/controls in, etc.

    • Chris Lema 3:43 am on August 5, 2015 Permalink | Log in to Reply

      My question may be silly, but assuming that a field has been created and attached to a post type, and then populated for all those posts, is there an expected facility in the API to be able to return a list of posts where the field is populated with a specific value? Additionally, are their collection operations where I could get a count of all those posts with the value of a specific field matching what I’m submitting?

      • Scott Kingsley Clark 3:20 pm on August 5, 2015 Permalink | Log in to Reply

        WP_Query / meta_query already do this :)

        The Fields API is not meant for querying for data, it’s to register the structures of information a site needs for it’s content / data types.

        • jbmanos 11:38 pm on August 7, 2015 Permalink | Log in to Reply

          So if I’m understanding this correctly, I could register fields I’ve developed for a particular site and the core will know what fields it needs to show the data it has? In other words, this would be a manifest of information types available?

          If so, I like it! I already get a little nervous that if I lose a piece of php that registered the fields to begin with, how many SQL queries and guess it’ll take to recover the data.

          • Scott Kingsley Clark 6:50 am on August 10, 2015 Permalink | Log in to Reply

            Basically, yes. A standardized API to register fields for different objects. An API that would eventually be the under pinning of all other Form UI, in that — a plugin, theme, or app (as exposed by a REST API) could know everything about your WP site, what content types it has (already possible), down to what fields it has (already possible) but more importantly — what types of fields it has. More in-depth information about the fields, where they are, how they’re used.

            If you lose the PHP side of this, you’re back to where you were before, which is to say, the same place you’d find yourself if you lost the config in any other plugin that builds fields. So there’s not really anything to get around that :)

    • Paul de Wouters 6:35 am on August 5, 2015 Permalink | Log in to Reply

      Not sure if it has been mentioned, but custom fields for menu items would be useful too.

      • Scott Kingsley Clark 3:20 pm on August 5, 2015 Permalink | Log in to Reply

        That’s a whole other story for another time, but I agree. Menu item custom fields are currently a very big affair to deal with given the lack of actions/filters in that area of the UI.

    • Eric Andrew Lewis 7:24 pm on August 14, 2015 Permalink | Log in to Reply

      Defining a spec for this project is a great way to go.

      The spec can be drawn out in some places. e.g. What is a field, and how does it relate to object metadata? How does this relate to prior HTML form HTTP POST submissions? This would help describe the problem space.

      The cross-platform usage of self-describing fields/metadata for rendering custom views (e.g. rendering a color-picker in the iOS app, or rendering custom media fields in Attachment Details) is a major plus, which should be explained in Community Benefits.

      The “Background” section (as-is) doesn’t seem relevant in spec, as it describes the history of the project, not specification.

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

  • Samuel Sidler 2:47 pm on July 10, 2015 Permalink |
    Tags: , ,   

    Feature Plugin Chat on July 14 

    Hey everyone!

    As I mentioned at this week’s dev chat, we’re going to have a feature plugin chat this coming Tuesday July 14 19:00 UTC.

    If you have an idea that you’d like to propose as a feature plugin or if you have a feature plugin already in development, come to the chat and comment below with the following details:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current status (e.g. idea, planning, early/late development, existing plugin, testing, stable, etc). If you’re just in the idea stages, list any existing plugins that are similar to your idea.
    • A list of those involved or already interested in your feature plugin (including you!).
    • A link to the plugin in the WordPress.org plugin directory and/or GitHub repository, if applicable
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    Please leave just one comment per feature plugin/idea so others can comment on the ones they’re interested in.

    Current feature plugin leads: We want your feature plugins here too! Please post an update with the information above.

    • Pascal Birchler 3:10 pm on July 10, 2015 Permalink | Log in to Reply

      I think there was a discussion about a toolbar feature plugin as mentioned in #32678. Basically, it should explore adding (most of) the admin menu to the toolbar.

      Status: Idea
      Similar plugins: https://wordpress.org/plugins/admin-bar-plus/

      I’d love to help with development and testing.

    • Pascal Birchler 3:13 pm on July 10, 2015 Permalink | Log in to Reply

      At the moment you can’t edit multiple users at once, which is pretty annoying for some use cases. Maybe this is something that should be explored as a feature plugin.

      Status: Idea
      Similar plugins: https://github.com/Automattic/bulk-user-management (old, multisite-only)

      I could help with scoping, planning and development if there’s enough interest. But I’ll probably end up developing something anyway 😉

      Relevant core tickets: #28050 and #32356

    • BrashRebel 3:49 pm on July 10, 2015 Permalink | Log in to Reply

      The TV team is collaborating on a plugin which places tutorial videos in the contextual help menu. The videos come from WordPress.tv and provide a visual walkthrough of the current screen in the wp-admin. The plugin is being developed for the purpose of assisting beginner WordPress users through video. The idea of proposing it as a future feature plugin has been briefly discussed.

      Current status: existing plugin
      Interested parties: @brashrebel @jerrysarcastic @roseapplemedia @ubernaut @johnparkinson
      Github: https://github.com/brashrebel/wptv
      We’d like help with:

    • jrf 4:37 pm on July 10, 2015 Permalink | Log in to Reply

      > Overview of your feature plugin proposal.

      Dependency management for themes and plugins the WordPress way.
      Allow themes and plugins to indicate dependencies on (other) plugins and providing an easy way for admin users to install, update and activate those. Will include activation prevention if dependencies are not met and providing cascading deactivate of dependents when a providing plugin would be deactivated.

      > Current status

      Existing external library which is widely used. +/- 6% of all themes in the repo use it, also used by a large number of premium themes and numerous plugins.
      A large refactor is planned and knowing what parts would be acceptable for core would be useful before starting the refactor.
      Roadmap for refactor from before this proposal (open to change per scoping): https://github.com/TGMPA/TGM-Plugin-Activation/issues/394

      > People involved

      Thomas Griffin – Project Owner & creator of the original TGMPA library
      Gary Jones – Project Lead
      Juliette Reinders Folmer – Lead Developer

      Suggesting this as a feature plugin is inspired by numerous users who keep suggesting it should be part of core.

      > Link


      > What you’d like help with

      Scoping: the libary currently features some functionality which may or may not be acceptable for core. Advise on this would be helpful before starting the refactor.
      Ref: https://docs.google.com/document/d/1abkiqT15SSboJVF8a16QDOL8o8Ocy4EHxsoZKwuwMFY/edit?usp=sharing

      Placement in the admin/user interface: currently plugins and themes can influence where the admin screen for TGMPA will show up. In the roadmap for 3.0 we’ve already included removal of this functionality and creating a set place for the admin page. Thoughts on where this should be and/or whether this should be integrated in an existing admin page would be helpful.

    • Daniel Bachhuber 9:41 pm on July 10, 2015 Permalink | Log in to Reply


      Shortcake adds a user interface to shortcodes.


      Late development. The next slated version is 0.5.0. You can easily skim through many discussions to date.


      @danielbachhuber, @mattheu, @goldenapples, @davisshaver and others



      Get Involved!

      At this time, we’d very much appreciate involvement in the form of documentation and user testing.

    • Nick Halsey 6:48 pm on July 12, 2015 Permalink | Log in to Reply

      Customizer Theme Installer
      Customizer theme installer would build on the Customizer Theme Switcher plugin merged in WordPress 4.2, bringing .org-repo-browsing and theme installation into the Customizer experience. The current idea is that entering theme-installation mode would bring the Customizer controls area full-width, hiding the preview, and the different tabs on the existing admin screen would be available, along with an “installed” tab. This would incorporate “shiny” theme installs – for each theme there are two options: “install” and “install & preview”. We would remove the existing theme-install previewer and instead offer the ability to download a theme and preview it in the Customizer with your actual site in one click. The basic install action would allow multiple themes to be installed at once, then the user could go through them to preview within the Customizer using the existing workflow.

      Current status: idea/design/wireframing

      Involved: @folletto and I (@celloexpressions) have tossed several ideas around and done some initial branstorming and wireframing, building on the work done in 4.2. I was originally planning on working on this for 4.3, but did Menu Customizer instead. I’d like to set up a meeting in the next couple weeks to get going on this effort and try to develop a merge-ready plugin by the time 4.3 is released, to be ready for merge in 4.4. Based on Customizer Theme Switcher (which was developed in only a few days), this effort will likely be more design/UX-heavy than development-heavy.

      • Paal Joachim Romdahl 7:02 pm on July 13, 2015 Permalink | Log in to Reply

        Features added to the customizer will these also be added outside of the customizer as well? For instance to the settings section. (Just thinking in general here).

    • Nick Halsey 7:51 pm on July 12, 2015 Permalink | Log in to Reply

      Background Image Cropper
      This plugin adds cropping to background images, to bring the feature into closer parity with header images. The plugin is currently awaiting review for the plugin repo, but is trivial code-wise and more about deciding whether this is a feature that users need/want. See also #32403.

      Current Status: Late development. The plugin is not currently functional due to a critical core bug in trunk that will be resolved in #29211 (specifically, it prevents the Customizer from loading, but there are additional issues that need to be cleaned up with the new API here). Once that core ticket is resolved in 4.3, the plugin will be fully functional and only potentially require minor tweaks.

      Involved: @johnbillion first proposed the idea in #32403, and I’ve built the plugin. Now, this feature is all about getting the word out about the plugin (once 4.3 is out, since that’s the required version), and gauging user interest. I suspect that we may run into issues here with some of the broader problems with the background images feature, and it remains to be seen whether cropping should be introduced without exploring broader changes here. Feedback and ideas welcome.


    • Nick Halsey 8:06 pm on July 12, 2015 Permalink | Log in to Reply

      Customizer UI Experiments
      Customizer UI Experiments is a new feature-plugin designed to be used on an ongoing basis for testing smaller UI/UX changes in the Customizer before rolling them into core. It contains several components that can be merged into core and subsequently removed from the plugin on an individual basis, with new components added as ideas are proposed. This single plugin to cover several distinct proposals allows testers to evaluate UI changes without wading through patches on different tickets scattered throughout trac. It also gives us a place to evaluate patches with feedback from a larger audience, hopefully improving our processes around UI-related Customizer tickets, which have had issues in the past. As a general rule, components added to this plugin should have a trac ticket first. This is a great plugin for multiple people to have commit access to, so if you’re interested in working on it (primarily porting patches to plugin form, and maintaining the plugin as components are added, updated and removed), please let me know and I can add you.

      The plugin is awaiting review on the .org repo, and initially contains an implementation of the patch on #32296. Components implementing #31195 (device-preview buttons) and #29158 (testing approaches to increasing visual contrast and improving focus styles for accessibility) are in the works as well.

      Current Status: This is a slightly different type of feature-plugin, so it will always be in a stable mode where testers can try it out (and leave it on) on their sites, with features coming in and out as they’re developed and merged into core. This is a sort of preview and testing ground for minor changes and features to come. Scope is strictly limited to changes with the Customizer UI itself – this plugin should avoid implementing larger features that add new panels/sections/settings/controls. Once the plugin is available on .org, I’ll link it on the tickets that it implements currently.

      Involved: I’ve done the initial development and scoping, with @voldemortensen already volunteering to help out and have commit access. Anyone interested in welcomed to jump in on Customizer-ui-related trac tickets and ping us in #core-customize or #design on Slack to discuss ideas.


    • George Stephanis 4:57 pm on July 13, 2015 Permalink | Log in to Reply

      Two-Factor Authentication

      Simple username/password authentication is fast becoming insufficient for the modern web. Several plugins so far have begun implementing methods for running two-factor authentication through varied systems, but none of them play well with one another. Our goal is to get a framework for two-step, two-factor authentication into core with several default providers (emailing a code, TOTP, and FIDO U2F) that core can support without any dependency on external providers, and keep it extensible, so that third-party plugins can add in new methods, such as Clef or TXT codes.

      Current Status: Active development, probably ~60% complete. Some providers need fleshed out, and the system needs backup provider support and some UI help. Also probably needs a couple audits from varied perspectives to make sure it solves everyone’s use cases and is accessibility friendly.

      Interested folks (who have expressed interest on Twitter or directly):

      @brennenbyrne (and the Clef gang)

      Probably some others I’ve missed.

      Current repository: https://github.com/georgestephanis/two-factor

      I’ve got the plugin approved for the .org repo, I just wanted to get backup methods fleshed out before starting porting it across.

      What we need help with: Code audits, design help, security audits, accessibility audits, development time fleshing out providers.

    • Weston Ruter 10:54 pm on July 13, 2015 Permalink | Log in to Reply

      Customize Partial Refresh

      Refresh parts of a Customizer preview instead of reloading the entire page when a setting changed without transport=postMessage. The goal with this plugin is to eliminate full-page refreshes as much as possible, as they are extremely bad for performance. This has been implemented in Core now for menus in the Customizer as of 4.3 beta. This plugin currently implements partial-refresh for widgets, but it also will abstract the functionality into a general API for developers to register their own partial-refreshable regions. This plugin has been floating around as a feature plugin for awhile. Blue sky: if we can eliminate full-page refreshes, we can start to introduce controls inline with the preview (e.g. widget controls appearing with their widgets), and even eliminate the Customizer iframe altogether since the Customizer pane could then slide-in on any existing frontend page the user is on without having enter into a completely different Customizer state; when done, they can just collapse the Customizer away and continue on their way browsing the site.

      Current status: existing plugin, development, testing

      Contributors: @westonruter

      Project links:

      Areas to contribute: identifying use cases and designing API for registering partial-refreshable region.

    • Pascal Birchler 12:59 pm on July 14, 2015 Permalink | Log in to Reply

      oEmbed for WordPress Posts

      Basically, we want to make WordPress an oEmbed provider. Users should be able to paste an URL from a WordPress blog and the post gets embedded right away. Difficulties here are discovering other WordPress sites as oEmbed providers and whitelisting them. The oEmbed endpoint requires the WP-API to be in use, so this can’t land in core until the API does.

      Current status: Idea / early development. There’s an existing plugin on GitHub we can build upon and we already have mockups of the desired end result.

      People already involved:


      And all the others who have joined the discussion on Trac.

      Project links

      Ticket: #32522
      Plugin on GitHub: https://github.com/swissspidy/oEmbed-API

      What we need help with: Mostly design and development, especially the oEmbed auto-discovery part.

      I’ll be around tonight for the chat, the others can’t make it unfortunately.

    • Ryan McCue 4:43 pm on July 14, 2015 Permalink | Log in to Reply


      The WP REST API adds a JSON-based REST API to WordPress, allowing accessing and modifying your site from a modern API.


      Ready for merge (version 2). Always more work to continue in the meantime.


      @rmccue, @rachelbaker, @danielbachhuber, @joehoyle


      https://wordpress.org/plugins/json-rest-api/ (v1 only)

      Get Involved

      We’re mostly deep focussing on getting it ready for merge, but we always need help on documentation and associated projects (OAuth, Basic Auth, client SDKs).

    • Joe McGill 1:25 am on July 15, 2015 Permalink | Log in to Reply

      For posterity…

      **RICG responsive images**

      **Big idea:** to bring responsive image markup natively into WP core.

      **Current status:** In development, stable (8,000+ active installs) could be considered for a 4.4 merge but will need some shepherding.

      **Plugin devs:** @tevko, @joemcgill, @dnewton, @jaspermdegroot, with consultation from @wilto (and a host of others).

      WP.org: https://wordpress.org/plugins/ricg-responsive-images/
      GH: https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images

      **Get involved:** We could use dev feedback, more testing (particularly against non-standard setups).

    • dshanske 2:01 am on July 15, 2015 Permalink | Log in to Reply

      Overview #32844 – There is interest in trying to put together a group to work on revamping Post Formats. This would not necessarily be the Post Formats UI that has laid dormant since 3.6, but a serious look at the feature as it exists today and how it can be refined in the same way the long-abandoned Press This feature was refined.

      I’m not looking to propose something with the scope of the WordPress 3.6 work, as I think the starting work is refining how Post Formats work. This includes better defining their use, producing examples of the types(documentation), looking for opportunities to better integrate them into existing parts of WordPress and enhance their functionality.


      I think @helen laid out a reasonable list of goals.

      “…existing content must be considered, as well as migration paths for those who currently use plugins/themes that store into meta. This may include things like auto-detection in Press This, modular content building, creation-only UI affordances, and so forth.”

      I’m willing to put in some time on this, and contribute out of my limited ability. Looking for interest.

    • Ryan Boren 2:36 am on July 15, 2015 Permalink | Log in to Reply


      Working on the latest Today in the Nightly post reminded me that I’ve been wanting a carousel feature plugin. The galleries on this post are handled by Jetpack’s carousel. Clicking/tapping an image pops up the image in a modal. The single images are not handled by JP’s carousel. They get the core behavior of following the bare image link. This is a bad experience, especially on mobile. Even on desktop, clicking the single images is a far worse experience than the carouseled images. Bare image links present no nav. You’re only way back is browser back history. This should work out of the box.



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