WordPress.org

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

  • Matt Mullenweg 9:30 pm on December 28, 2016 Permalink |
    Tags: wp-cli   

    Supporting the Future of wp-cli 

    wp-cli is a command-line interface that is deployed and relied upon by almost every major user of WordPress out there. As we head into 2017, I wanted to make sure that its future is certain for everyone who builds on it, and that the major contributors to the project, chiefly Daniel Bachhuber, are able to work on it even more in the coming year.

    To that end there are two big announcements:

    1. The website of wp-cli.org, the code / GitHub, Twitter, and such are all coming in under the WordPress.org umbrella and there will be a CLI Make site with a P2 and all of the resources that used to be under wp-cli.org. There is already #cli on Slack and that will continue. (Will live at https://make.wordpress.org/cli.)

    2. I’m going to be bringing together a number of companies in the WordPress ecosystem to solidify their financial support of runcommand so that Daniel and others can devote more time to making wp-cli better and better through 2017. This is a continuation of the fundraising started a few weeks ago.

    This will all happen the first part of January, and I’m looking to a full and exciting year for wp-cli. Also big thanks to everyone who has chipped in, whether time or money, to support the project in the past. It has been one of the highest impact developments for WP in many years.

    Many of the logistics are yet to be determined. Feel free to weigh in with questions, feedback, etc. in the comments, or join #cli on Slack. We’ll do our best to keep everyone in the loop as things develop.

     

  • Ella Van Dorpe 1:22 pm on December 24, 2016 Permalink |
    Tags: , , ,   

    Idea: Uniform Resource Identifiers as an alternative to Shortcodes 

    The idea is that any objects embedded in a post’s content have their own home and should be seen as separate resources. Data would be stored elsewhere.

    Examples

    • https://example.com/resources/contact-forms/email-ella/
    • https://example.com/resources/charts/php-versions-wordpress/
    • https://example.com/author/iseulde/
    • https://example.com/galleries/yummy-chocolates/
    • https://example.com/surveys/wordpress-editor-2016/
    • https://external.com/some-map-or-form/

    Object Types

    This approach could be good for:

    • Forms such as contact forms, surveys and polls.
    • Visualised data such as diagrams, charts, graphs and tables.
    • Lists of items such as a galleries, playlists and lists of posts.
    • Albums or manually composed collections of items where the presentation is uniquely different from a normal list.
    • Any content that needs to be reused or organised separately. Anything that can be re-sourced. 😉
    • Any external resources.

    This is not good for:

    • Layout.
    • Text conversions.

    Inspiration

    • External embeds work similarly in WordPress through oEmbed.
    • Images, audio and video are embedded by their URL in HTML.
    • Media have their own “attachment” post type in WordPress.
    • Many plugins already have a separate post type to store their data.
    • I’ve seen some news media do this already for things for like graphs (post, resource).

    Benefits

    • A URL (or “link”) is a concept that is already familiar to many users.
    • URIs are designed for these sort of things. Think about images — it would follow the same paradigm.
    • The content is treated as a separate resource, and can be reused, just like shortcodes, but it forces separation.
    • WordPress allows you to create “pretty” semantic URIs, so the resource can be described for a better experience.
    • A cool side effect is that others could embed these easily on their site through oEmbed. WordPress already supports this.
    • If there’s a problem, the URL will act as a fallback.

    Implementation

    A quick way to implement this for WordPress 4.4 and higher is registering a new post type. This will handle most things, you just need to provide a custom embed template with the template_include filter. An external resource can be filtered with the Embed API and TinyMCE View API, even if it doesn’t support oEmbed.

    Challenge: Variants and Settings

    Either each variant of an resource needs its own ID, or settings could be passed with a query string. I think the use of settings should be minimised — for example, columns for a gallery object may be better set per ID. Settings can certainly be useful for things like autoplay, for example YouTube allows you to set the start time.

    Challenge: Alignment

    This is great if the URL is added on a separate line, but aligning the object is not evident. This is a challenge for shortcodes too. At the moment the core galery shortcode does not allow you to allign it, and the caption shortcode has an attribute for it. Similarly the URl could have a query parameter for alignment, but that doesn’t sound ideal. Alternatively the paragraph could be floated, or it needs to be wrapped in a `div` element to float mid-text. Another approach is to always wrap the URLs in a (custom) tag that can have display information. Again, think about how images are embedded in HTML.

    Challenge: Namespace

    Shortcodes would have a similar problem, though slug clashes are probably more likely. Ideally plugins should use their own prefix, but this may be seen as ugly. Another way to avoid clashes with other post types is a sub type for “attachments” or “resources”.

    Challenge: Extra Queries

    I don’t see this exactly as a challenge, as it’s the nature of the concept, but it may be used as an argument against it. Many shortcodes already make use of custom post types to store data and embedding media (or anything else) also requires extra queries. If and how this should be cached is another problem.

    I would love to hear your thoughts on this alternative, especially from those who use shortcodes for this type of objects in the post content. If you already use a custom post type, why not take advantage of embedding instead of creating shortcodes? If you want to embed external resources, why wrap it in a shortcode?

    If you have other alternatives, I’d love to hear about those too!

     

    • Celso Bessa 1:37 pm on December 24, 2016 Permalink | Log in to Reply

      At first glance, seems like a great idea. I am kind of exploring a similar concept in a new product project. +1

      As for the extra queries, taking as certain that 1) those objects will be used in several posts and 2) they probably won’t change often; maybe leveraging query and response caching will be requirement for this type of object/post.

    • Martin Sotirov 1:39 pm on December 24, 2016 Permalink | Log in to Reply

      I like this idea but the title is misleading as these are two separate use cases.

      Shortcodes CAN be used to embed things but I think that’s a kind of misuse. I try to use them only to enable the user to change the layout without knowing anything about HTML.

      • Ella van Dorpe 2:09 pm on December 24, 2016 Permalink | Log in to Reply

        Sure, and then lots of plugins are kind of misusing them, even core. 🙂

      • Jon Brown 3:55 pm on December 24, 2016 Permalink | Log in to Reply

        Some (me at least) would argue using shortcodes for things easily done with HTML is a misuse of shortcodes… that they were intended for when code needed to run, for example galleries, forms, etc,

        This proposal would do away with shortcodes primary purpose for existing. I like the proposal, just not sure feel it’s a shortcodes replacement proposal where shortcodes could be deprecated.

        • Mike Schinkel 10:13 pm on December 24, 2016 Permalink | Log in to Reply

          I think this proposal implemented and shortcodes could easily co-exist.

          However if after numerous versions of WordPress it becomes clear that shortcodes are now redundant and a less ideal solution then they could be deprecated then. But I personally doubt finding them redundant would ever be the case.

    • lkraav 2:34 pm on December 24, 2016 Permalink | Log in to Reply

      I’m using https://wp-types.com/home/views-create-elegant-displays-for-your-content/ to achieve this (or at least similar) embedding concept today. It does require building up templates for how you want the thing to display so really requires above-average user understanding. The process could certainly be simplified towards the concepts presented in this article.

    • PeterRKnight 3:47 pm on December 24, 2016 Permalink | Log in to Reply

      This idea overlaps a lot with developments around widgets (see for example https://core.trac.wordpress.org/ticket/35669)

    • Wayne Allen 4:29 pm on December 24, 2016 Permalink | Log in to Reply

      I can kind of see the point for things that are like external resources, but otherwise the usability seems low (lots more characters). Also I’m not sure what problem this is trying to solve.

    • Weston Ruter 4:40 pm on December 24, 2016 Permalink | Log in to Reply

      Yes, I like this. I’m hoping that a new iteration on widgets (e.g. #35669) can serve as the long-desired content blocks, and embedding an existing widget into a post would require a reference to that widget. It could be done with a new core `[widget]`shortcodes with an `id` attribute, which may work equally well here, but it could also be a URL. It’s just for a widget I’m not sure there would/should be a permalink to that individual widget (there should certainly be a REST API endpoint nonetheless).

      Note that oEmbeds get cached in postmeta so these “shortcode URLs” could also be cached similarly. Nevermind when to invalidate 🙂

      A lot of shortcodes can’t be standalone and thus shouldn’t have a discrete URL. But I suppose this is not what the proposal is trying to address and it wouldn’t replace shortcodes altogether but rather provide an alternative syntax.

      • Ella Van Dorpe 11:33 am on December 25, 2016 Permalink | Log in to Reply

        Yes, this is not a complete replacement for shortcodes, but only an alternative for some types. Do you have any shortcodes in mind that can’t stand alone and are not layout or text conversions?

        • Weston Ruter 7:15 am on December 26, 2016 Permalink | Log in to Reply

          @iseulde I suppose a widget would be an example of something that couldn’t stand alone. Then again, pretty much anything could be served standalone if there was a wrapper page around it. Attachments are envelopes for media and the permalink for an attachment wraps the media in a template. Something similar could be done for other such internal post type oEmbeds.

          • Ella Van Dorpe 9:29 am on December 26, 2016 Permalink | Log in to Reply

            What kind of widgets? 🙂 I guess I would see widgets more as content in content areas where each “block” is something more specific.

    • J.D. Grimes 4:43 pm on December 24, 2016 Permalink | Log in to Reply

      I think this is a great idea, but it would be most usable if it was accompanied by a “resource picker” UI on the edit post screen. And also the ability to create a new resource of a particular type right there. I say this because I’m coming from the perspective of using shortcodes to display tables of aggregated data, not so much a post type that can already be created on another screen and then the URI grabbed and embedded.

      However, as others have said, I don’t think this is an idea that can completely replace shortcodes, because they are also used for formatting and to display very small bits of data (like one piece of metadata for a user), which isn’t worth the resource fetch, IMO.

      Although perhaps one way to reduce the need for fetching the resources with oEmbed would be to detect when they could be created locally to the current request, by simulating the query for the object.

    • iLen 5:07 pm on December 24, 2016 Permalink | Log in to Reply

      It seems to me a good idea, the external web or internet should send the construction attributes of the html type shortcodes – in turn an embed. This with the embed and embed appendix of wordpress could do. I see a lot of use in this.

    • Ricky Lee Whittemore 5:30 pm on December 24, 2016 Permalink | Log in to Reply

      This seems like a great path forward and a picker UI for Visual mode seems logical. Would love for widgets to be moved to post type as well. I prefer the Component/Content Block nomenclature but I can see an argument to use widget as namespace or naming convention.

    • LewisCowles 5:36 pm on December 24, 2016 Permalink | Log in to Reply

      Oh… seems I mis-read it the first time (when I shared to social media), this isn’t replace shortcodes with oEmbed, it’s add oEmbed along with shortcodes and possibly communicate the difference, the situations etc. It’s a lovely idea!

    • FolioVision 6:07 pm on December 24, 2016 Permalink | Log in to Reply

      John Godly came up with the core of this a decade ago with his Sniplets plugin. Sniplets didn’t categorise the content particularly deeply so there could be more done with a content library. I see Sniplets never took off but there are more recent versions of the Sniplets concept which are quite popular and well thought of (@artstorm). That covers the simple uses for me.

      After that there are also shortcodes for the more complex programmatic enhancements. I have trouble differentiating between what you are suggesting Ella and shortcodes. This seems to me to introduce additional complexity to WordPress with only modest benefits. I’m a great advocate for keeping things simple.

      Maybe I’m missing something. If you have time to post a simpler list of benefits to restructuring WordPress in this way, perhaps it would help.

    • Mike Schinkel 10:15 pm on December 24, 2016 Permalink | Log in to Reply

      LOVE, LOVE, LOVE your idea. What’s so beautiful about it is its elegance and how it reuses existing solutions.

      Some feedback that assumes your proposal is for inclusion in core vs. how to write a plugin to do the same:

      Implementation

      It would seem that post types are a perfect fit for this. So much that adding an `’embeddable` => true` argument when calling `register_post_type()` could be used to specify that a post type is embeddable _(unless we wanted all custom post types to be embeddable by default then `’embeddable` => false`)_

      This could be extended to allow the `embeddable` argument to accept an array containing default settings for all embeds of that post type.

      Further, rather than require use of `’template_include’` why not extend the template hierarchy and look for template with the name format of `embed-{$post_type}.php` but default to `embed.php` when no specific embed template is available?

      Namespaces
      This can be dealt with in one of two way; one simple and the other powerful:

      1. Follow the lead of post types; use the rewrite slugs and ignore namespacing as custom post URLs currently do
      2. Use the rewrite slugs and create an Embeds configuration page in the WP admin where all `embeddable` post types are listed and the admin user can change their namespaces and their default settings. This would in some ways be similar to the Widgets configuration page.

      Come to think of it, allowing admin users to change slugs for post types should probably be associated with URLs in general so admin users can use post types from different plugins that have conflicting slugs?

      Alignment
      This could be handled using default settings, and on a one-off basis with a URL parameter (more on URL parameters below.)

      Variants and Settings

      While I agree that many aspects should be handled per ID — because they are facts about the object being embedded — it is not uncommon to have aspects that are related to how the embed is being placed in the document, such as height, width, alignment, etc.

      So I would really hate to see these embedded URLs be required to be wrapped by `

      ` tags; that would destroy most of the elegance of the solution and revert back to a hacked-up extension. URL parameters are tailor-made for creating variants of a URL.

      Embed URL + Variants Edit Dialog
      But I agree that URLs with parameters can be off-putting for less technical users. To address I think we could embrace the fact that WordPress will be able to recognize these URLs when editing able wrap them with on-hover controls for editing the URL and its URL parameters.

      The `embeddable` argument for `register_post_type()` could easily include a list of available URL parameters and their data type so the variants edit dialog could display field formatting and helpers, as appropriate.

      Having an edit dialog would make it easy for non-technical users and it would also act as a training aid to allow them to learn how the URL parameters worked as they would see the URLs being embedded with the same information they typed.

      Matching URLs that should display as URLs

      I did not see this addressed; I think wrapping in a `` with a class like `wp-no-embed` would handle this nicely.

      Extra Queries

      A reasonable caching strategy could easily address this concern. Caching the embed’s HTML into a post_meta field that can be updated when the post type that it points to is updated.

      And let me say again, LOVE the idea!

    • Samuel Wood (Otto) 3:18 pm on December 25, 2016 Permalink | Log in to Reply

      Not really seeing this as a replacement for shortcodes. It fills some of the same gaps, but not really.

      However, the underlying notion of expanding embeds, and possibly even making internal-only embeds (bypassing the extra http overhead with oEmbed) is a very worthy idea. Especially if you extend it beyond the current iframe level.

      But ditch the idea of shortcode replacement therapy. It doesn’t really fit for most cases where shortcodes properly make sense in the first place. It does fit for cases where shortcodes have been misused, which is indeed legion, but not for “correct” use of shortcodes.

      • Pascal Birchler 12:56 pm on December 29, 2016 Permalink | Log in to Reply

        Internal-only embeds already bypass the HTTP overhead, see `wp_filter_pre_oembed_result()` and `get_oembed_response_data()`.

    • chatmandesign 4:55 pm on December 27, 2016 Permalink | Log in to Reply

      As others have noted, this is not a replacement for shortcodes, but Ella clearly didn’t intend it to be. This is basically a solution for handling content re-use within a WordPress site. There are a number of plugins that provide a similar feature currently (e.g., [Spots](https://wordpress.org/plugins/spots/)), and I’ve implemented some custom solutions on a couple sites myself; it seems to be a common enough need that standardizing a solution within core could be beneficial.

      I would tend to agree with J.D. that there should be a UI for picking a resource for inclusion. Currently there’s an shortcode that turns URLs into oEmbed iframes… Might something like an [import] shortcode be the most consistent way to implement this?

    • FolioVision 5:19 am on December 28, 2016 Permalink | Log in to Reply

      Tim, many people including you suggest using custom post types to store this content. Very often the content is a PHP fragment or something else which does not sit well in a normal post. By storing the snippet content as a custom post one is severely limiting its flexibility. Here’s how the author of Post Snippets describes his plugin:

      snippets of HTML, PHP code or reoccurring text that you often use in your posts and pages. You can use predefined variables to replace parts of the snippet on insert. All snippets are available in the post editor via a button in the Visual and HTML modes. The snippet can be inserted as defined, or as a shortcode to keep flexibility for updating the snippet. PHP code is supported for snippets inserted as shortcodes.

      This is a lot simpler than creating custom post types. Integrating an optional WYSIWYG editor would be a lot simpler than adding all the overhead of full custom posts to each snippet.

      Ladies and gentlemen, let us not over engineer WordPress. Simplicity of structure and ease of use should be our watchwords.

    • cavalierlife 9:40 pm on December 28, 2016 Permalink | Log in to Reply

      I’m with FolioVision. Snippet plugins already exist, and if core wants to integrate such a thing, fine, but let’s keep it simple.

    • Mike Glendinning 10:02 am on December 29, 2016 Permalink | Log in to Reply

      Agree that all embeddable content should be a first-class “object” but disagree strongly that URIs should be used to reference these for editing and content management.

      The URI for an object is a generated and changeable attribute, not a key and we already hard-wire too many such references within managed content, making it difficult to move sites between locations, implement some SSL environments, serve responsive images, make use of CDNs and so on. There are already dozens of tickets highlighting these sorts of issues.

      Better, I think that objects reference each other using their managed identity (e.g. post ID) which is then expanded dynamically to the appropriate URI when a page is rendered. Isn’t this sort of thing what a content management system is for? As well as providing much more flexibility, this also enables better context-sensitive editing (e.g. allowing pick-lists for objects and their allowed attribute values).

  • Andrew Rockwell 11:24 pm on December 16, 2016 Permalink |
    Tags: ,   

    Week in Core, December 7 – 13, 2016 

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

    • 69 commits
    • 39 contributors
    • 143 tickets created
    • 29 tickets reopened
    • 100 tickets closed

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

    Code Changes

    Administration

    • Remove the WordPress version number from readme.html. [39583] #35554
    • De-Emphasise the minor (x.y.Z) version in readme.html by including only the major version for the 4.7 branch. [39582] #35554
    • Accessibility: Remove inappropriate content from the Edit Categories and Edit Tags screens headings. [39553] #26601
    • Accessibility: Remove inappropriate content from the Edit Comments screen heading. [39552] #26601
    • Accessibility: Remove inappropriate content from the Network screens headings. [39551] #26601
    • Accessibility: Remove inappropriate content from the Menus screen heading. [39543] #26601
    • Accessibility: Remove inappropriate content from the old Edit Media screen heading. [39542] #26601
    • Accessibility: Remove inappropriate content from the Widgets screen heading. [39541] #26601
    • Accessibility: Remove inappropriate content from the Edit User screen heading. [39538] #26601
    • Accessibility: Remove inappropriate content from the Link Manager screens headings. [39537] #26601
    • Accessibility: Remove inappropriate content from the Add Plugins screen heading. [39536] #26601
    • Accessibility: Remove inappropriate content from the Plugins screen heading. [39535] #26601
    • Accessibility: Remove inappropriate content from the Users screen heading. [39534] #26601

    Bootstrap/Load

    • Bootstrap: Re-initialize any hooks added manually by object-cache.php.
      Prior to 3.1 if a object cache dropin wanted to add actions, they needed to use $wp_filter directly. [39565] #39132

    Build/Test Tools

    • Facilitate SVN and Git being co-located in the same directory. [39577] #39245
    • Remove some more randomness. [39556] #37371
    • Reuse another fixture in the user capability tests. [39555] #38716
    • Remove commented out tests that have existed in an unimplemented state since the dawn of the test infrastructure. [39554] #38716

    Comments

    Customize

    • Prevent navigation in preview when clicking on child elements of preview links that have non-previewable URLs. [39584-39585] #39098
    • Prevent edit shortcut from losing event handler after selective refresh. [39581] #27403, #39100
    • Deprecate page_home nav menu item starter content in favor of home_link; replace usage in Twenty Seventeen. [39561], [39575] #38615, #38114, #39104
    • Allow (optional) url parameter to be omitted in intercepted calls to history.pushState() and history.replaceState() in customize preview. [39547], [39574] #39175
    • Trim whitespace for URLs supplied for external_header_video to prevent esc_url_raw() from making them invalid. [39560], [39573] #38172, #39125
    • Fix ability to shift-click on placeholder/pre-saved nav menu items in preview to focus on corresponding control. [39562], [39572] #39102
    • Use selected user language for edit shortcuts in preview instead of site language. [39545], [39571] #39009
    • Fix inability to delete nav menus by preventing preview filters from being added during customize_save admin ajax request. [39558], [39570] #30937, #39103
    • Prevent scrolling custom_css textarea to top when pressing tab. [39557], [39569] #38667, #39134
    • Use esc_url_raw() instead of wp_json_encode() to eliminate extraneous slashes when outputting background image URL in CSS url(). [39546], [39568] #22058, #39145
    • Prevent single quotes (apostrophes) in custom_css values from unexpectedly causing false positives for unbalanced character validation errors. [39559], [39567] #39218, #35395, #39198
    • Collapse available nav menu items panel when clicking outside over preview or over existing items. [39548] #38953

    External Libraries

    • Libraries: Update zxcvbn from version 1.0 to 4.4.1 [39596] #31647

    General

    • Correctly detect trailing newline when prepending. [39592] #37082
    • Remove most uses of create_function() [39591] #37082
    • Taxonomy: Correct the type for the first parameter of the the_category filter. [39530] #39130

    Login and Registration

    Media

    • PDF Images: Avoid a PHP Warning when attempting to process a file without an extension. [39580] #39195

    Misc

    • Bump the version in package.json to 4.7.1 after [39576]. [39579] #
    • The 4.7 branch is now 4.7.1-alpha. [39576] #

    Options, Meta APIs

    • Options: Prevent unnecessary SQL updates by update_option. [39564] #38903

    Query

    • Docs: Correct param definition for WP_Query::query(). [39550] #38963

    REST API

    • Add support for filename search in media endpoint. [39598] #39092
    • Allow sending an empty or no-op comment update. [39597] #38700
    • Do not include the password argument when getting media items [39595] #38977
    • Do not error on empty JSON body [39594] #39150
    • Treat any falsy value as false in ‘rest_allow_anonymous_comments’. [39566] #39010
    • Allow schema sanitization_callback to be set to null to bypass fallback sanitization functions. [39563] #38593, #39042

    Role/Capability

    • Tests: Use wp_delete_user() during teardown to delete a single site’s user. [39590] #39065
    • Multisite: Replace is_super_admin() with manage_network in get_dashboard_url(). [39589] #39065, #37616
    • Multisite: Handle capability check for removing oneself via map_meta_cap(). [39588] #39063, #37616
    • Multisite: Replace is_super_admin() with update_core for update permissions. [39540] #39060, #37616
    • Multisite: Remove redundant is_super_admin() when checking for edit_others_posts. [39539] #39059, #37616

    Taxonomy

    • Use get_term_link() instead of get_category_link() in get_term_parents_list(). [39593] #17069
    • Restore the ability to use string-based $args in wp_get_object_terms(). [39578] #39215
    • Introduce get_term_parents_list(). [39549] #17069

    Themes

    Toolbar

    Users

    • Style the super admin message on the user editing screen as a notice, not a success message. [39531] #39131

    Thanks to @afercia, @boonebgorges, @bradyvercher, @celloexpressions, @chandrapate, @Christian1012, @david.binda, @dd32, @flixos90, @Hristo Sg, @iaaxpage, @jblz, @jnylen0, @joehoyle, @johnbillion, @jorbin, @JPry, @kafleg, @keesiemeijer, @ketuchetan, @kkoppenhaver, @obenland, @ocean90, @pento, @peterwilsoncc, @rachelbaker, @rafaehlers, @rmccue, @rockwell15, @salcode, @SergeyBiryukov, @sgolemon, @Shelob9, @sirbrillig, @sstoqno, @tomdxw, @tyxla, and @westonruter for their contributions!

     

  • Felix Arntz 5:27 am on December 14, 2016 Permalink |
    Tags: 4.8, ,   

    Multisite Office Hours Recap (December 13, 2016) 

    Multisite office hours are held every Tuesday at 17:00 UTC in #core-multisite. The next will be Tuesday 17:00 UTC.

    The weekly agenda was to discuss long-term goals for multisite and prioritize tickets to work on related to one of the three new focuses, particularly the REST API.

    Today’s chat log

    Attendees: @iamfriendly, @mista-flo, @johnjamesjacoby, @loreleiaurora, @johnbillion, @jeremyfelt, @flixos90

    Chat Summary:

    • @jeremyfelt, @flixos90, @johnjamesjacoby, and @johnbillion sat down for a chat at WCUS to discuss multisite topics and possible future focuses. @jeremyfelt shared his notes from that session. Items of particular interest in today’s chat were:
      • Identify statistics for multisite usage, size of multisites: Possibly sending more general multisite-related metrics during core updates could be helpful and should be further discussed. In addition to whether multisite is enabled and the count of sites (on the main network) it could be helpful for future decisions to know how many sites there are in total, how many networks exist and whether user / site registration is open or not.
      • Implementation of network user roles: A ticket is in place at #39174. @flixos90 requested feedback: Everyone interested is asked to read through the ticket description and provide an elaborate response with how they think network roles should work. Then a discussion based on these approaches can start.
      • Network administrators should be able to enable themes on the site level: It is currently not very convenient for a network administrator to switch back to the network admin to enable a theme when currently working within the site admin.
      • Disable plugins per site in the network admin: Sometimes not all plugins should be visible on all networks or all sites, which is currently not possible. However, even for a disabled theme a network administrator should still be able to “silently” activate it on a site. Plugins would need to be enabled by default, so it would be the opposite way of how themes are currently handled. This also ensures there are no concerns with backward-compatibility. UI-wise an improved flow should be investigated instead of simply pursuing a similar approach to how enabling themes works: Having all the functionality inside the Network > Plugins screen would be helpful, with row and bulk actions for “Network Disable” as well as “Disable for Site…” with the latter having some kind of popover with an autocomplete field for sites. A related ticket to take into account for the implementation is #38652 which @johnbillion opened to introduce singular capabilities for managing plugins.
      • Whichever flow is agreed on for disabling plugins per site or network, once this functionality is implemented, it will probably make sense to “back-port” the behavior to improve the existing theme and maybe even user handling in a multisite.
    • At this point, the highest priority is multisite support for the REST API.
      • The users endpoint should be improved, particularly the implementation of DELETE for a user on a multisite as well as removing a user from a site or setting their capabilities per site via PUT (see #39000 and #38962 for related tickets).
      • A sites endpoint should be added.
      • A networks endpoint is not as important and should for now only live in a standalone plugin if there is interest to implement it.
    • A general question raised was how No-JS fallbacks for REST API functionality in the admin should be handled. Should JavaScript become a requirement to use such new functionality or should the REST API only be used to improve existing PHP-only features? These questions should be discussed in a broader scope than just multisite since they affect all of WP Admin.
    • Possible usage for a REST API sites endpoint:
      • Replacing “My Sites” in the toolbar with a menu that doesn’t load until needed and pulls all sites from the API.
      • The possible autocomplete field for disabling plugins for a specific site (see above) could pull sites from the API.
    • @mista-flo brought up #13743 and asked for feedback. Everyone in the chat agreed that the ability to set a default theme for a network would be a valuable enhancement over the existing constant. For the approach, introducing a new row action “Set default theme” the Network > Themes list table was suggested, alongside an indicator “Default Theme” in that same table. This is an enhancement that can be worked on beside the other important REST API features.
    • A Google document was opened a while ago to gather input for a future multisite roadmap, as a follow-up to 2013’s post. @jeremyfelt highlighted that this document should continue to move forward in order to hopefully be able to publish an actual roadmap in early January.
     

  • Andrew Rockwell 8:34 pm on December 8, 2016 Permalink |
    Tags: ,   

    Week in Core, November 30 – December 6, 2016 

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

    • 150 commits
    • 63 contributors
    • 140 tickets created
    • 17 tickets reopened
    • 104 tickets closed
    • WordPress 4.7 released 🎉

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

    Code Changes

    Administration

    • Accessibility: Remove inappropriate content from the Themes screen heading. [39528] #26601
    • Accessibility: Remove inappropriate content from the Add Themes screen heading. [39527] #26601
    • Accessibility: Remove inappropriate content from the Media Library screens headings. [39526] #26601

    Build/Test Tools

    • Correctly set up the current screen during list table tests so that they don’t fail when run individually. [39481] #38761
    • Specify exact node version in package.json. [39480], [39478] #35105, #38657
    • Remove PHP 7.1 from allowed failures [39424-39425] #37625

    Bundled Theme

    • Default Themes: Update version numbers and readme files for 4.7 release [39496] #38858
    • Twenty Seventeen: Fix CSS specificity problem with CSS feature query for object-fit [39495] #39073
    • Twenty Seventeen: Improve display of video header and header image in modern browsers [39485], [39483] #39035
    • Twenty Seventeen: Add specific font stack for Thai language [39484], [39482] #38937
    • Twenty Seventeen: Improve ARIA for the nav menu. [39451-39452] #39029, #39026
    • Twenty Seventeen: Ensure header text color updates in Customizer preview when cleared [39447-39448] #38993
    • Twenty Seventeen: Fix broken menu toggle in Customizer after menu items are added [39419], [39423] #38992
    • Twenty Seventeen: Fix style issues with gallery image links [39418], [39422] #38969
    • Twenty Seventeen: Hide front section panels on page load of Customizer. [39417], [39421] #38951
    • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39416] #38995
    • Twenty Seventeen: Better handling of custom headers when no image is set. [39413-39414] #38995
    • Twenty Seventeen: Make spacing on pages without comments consistent [39404-39405] #38972
    • Twenty Seventeen: Make sure header text color is applied when color schemes are active. [39397-39398] #38980
    • Twenty Seventeen: Make fixed navigation apply at correct height on front page, without header video or image [39394], [39392] #38927
    • Twenty Seventeen: Provide a background color fallback for non-webkit browsers on input styles [39388] #38939
    • Twenty Seventeen: Allow child themes to easily extend custom color patterns [39386] #38949
    • Twenty Seventeen: Make screen reader text on scroll arrow more meaningful [39384] #38970
    • Twenty Seventeen: Keep header videos from extending past footer. [39380-39381] #38950

    Comments

    • Merge a similar string between comments.php, XML-RPC and the REST API comments controller. [39508] #39013

    Customize

    • Prevent infinite full refresh from occurring when selective refresh falls back for a nav menu that has items excluded from rendering via filtering. [39510-39511] #38612
    • Defer populating post_name for auto-draft posts in customized state until posts are published. [39506-39507] #39078
    • Ensure changeset_uuid query param is removed from the customize.php window’s location once a changeset has been published (committed) with starter content. [39504-39505] #39081
    • Prevent posts/pages imported via starter content from being dropped when adding post/page stubs via nav menus and the dropdown-pages control. [39502-39503] #38114, #34923, #39071
    • Ensure textarea for Custom CSS displays as code (in LTR) when an RTL language is active. [39499-39500] #35395, #39085
    • Ensure a custom_css post insertion gets an initial post revision. [39479], [39477] #30854, #38672, #35395, #39032
    • Custom CSS: Change the help link to something better for users. [39467], [39466] #39015
    • Fix posts limit query arg for WP_Query from incorrect number to posts_per_page. [39434-39435] #39022
    • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39411] #38114, #38928
    • Reject a changeset update when a non-future date is provided and also ensure that a published changeset always gets set to the current date/time. [39409-39410] #30937, #38943
    • Fix handling of the nav menu item labels (titles) that match defaults (original titles) and fix the display of item type labels. [39395], [39393] #38015, #38955

    Feeds

    General

    Help/About

    Media

    • Accessibility: Improve keyboard accessibility avoiding confusing tab stops in the Media views. [39529] #30599
    • Docs: Add inline documentation for image-edit.js. [39493] #38748
    • Fix regression with display of small images in media library. [39399], [39396] #38965
    • Docs: Document the usage of the global $wpdb in _filter_query_attachment_filenames(). [39390] #38973

    Misc

    • Tag 4.7 [39525] #
    • WordPress 4.7 “Vaughan”. [39524] #
    • Post-RC3 bump. [39519] #
    • WordPress 4.7 RC3. [39516] #
    • Post-RC2 bump. [39474] #
    • WordPress 4.7 RC2. [39473] #
    • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39415]

    Options, Meta APIs

    • REST API: Register the admin_email setting in single site only. [39470-39472] #38990
    • REST API: Site URL setting should not be present on multisite installations. [39468] #39005
    • REST API: Correct the admin_email setting description for single site installs. [39406] #38990
    • Multisite: Display different descriptions for multisite or single site installations. [39407] #38990
    • Options: Pass the $passed_default parameter to the 'default_option_{$option} filter in add_option(). [39382] #38176, #38930

    Plugins

    REST API

    • Comments: Merge similar strings between comments.php and the REST API comments controller. [39490-39491] #39014
    • Merge similar date strings in the revisions and comments controllers. [39488-39489] #39016
    • Treat any falsy value as false in ‘rest_allow_anonymous_comments’. [39487] #39010
    • Docs: Add missing REST API-related args to register_post_type() and register_taxonomy(). [39462-39463] #39023
    • Merge similar strings in a comments endpoint parameter description. [39457] #39036
    • Fix bug where comment author and author email could be an empty string when creating a comment. [39446], [39444] #38971
    • Fix handling of some orderby parameters for the Posts controller. [39440-39441] #38971
    • Disable DELETE requests for users in multisite. [39438-39439] #38962
    • Return a WP_Error if meta property is not an array. [39436-39437] #38989
    • Add test for creating a comment with an invalid post ID. [39408] #38991
    • Fix incorrect uses of rest_sanitize_value_from_schema(). [39400-39401] #38984

    Role/Capability

    • Don’t assign the delete_site capability to anyone on single site installs. [39494] #38326
    • Multisite: Replace is_super_admin() with manage_network for admin bar permissions. [39492] #39064, #37616

    Taxonomy

    • Docs: Update an @since as there will not be a 4.6.2 before 4.7. [39475-39476] #37291
    • REST API: Capability check for editing a single term should use the singular form. [39464] #35614, #39012
    • REST API: Use the correct error message when editing a single term. [39460-39461] #39017
    • REST API: Fix incorrect capability check on term create. [39402-39403] #35614, #38958
    • Performance: Revert [38677] from the 4.7 branch. This avoids fatal errors caused with recursive calling of term functions within the get_terms filter. [39454] #21760

    Themes

    • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39412] #38114, #38928

    TinyMCE

    • Fix the styling of notices generated by the editor UI. [39501] #38917

    Users

    • Clarify the return value of get_current_user_id() for non-logged-in users. [39486] #39051
    • REST API: Require the reassign parameter when deleting users. [39426-39427] #39000

    Thanks to @andizer, @mor10, @adamsilverstein, @afercia, @azaozz, @boonebgorges, @celloexpressions, @ChopinBach, @clorith, @coffee2code, @davidakennedy, @dd32, @desrosj, @dlh, @flixos90, @georgestephanis, @helen, @helen, @hnle, @iaaxpage, @imnok, @jbpaul17, @jeremyfelt, @jnylen0, @joedolson, @joehoyle, @joemcgill, @johnbillion, @jorbin, @kadamwhite, @karmatosed, @ketuchetan, @laurelfulford, @littlebigthing, @lucasstark, @melchoyce, @michaelarestad, @mikeschroder, @mt8.biz, @nacin, @netweb, @ocean90, @ovenal, @pento, @peterwilsoncc, @presskopp, @rachelbaker, @rahulsprajapati, @ramiabraham, @ramiy, @rensw90, @rianrietveld, @rmccue, @samuelsidler, @sayedwp, @SergeyBiryukov, @sstoqnov, @The PHP tea, @timmydcrawford, @utkarshpatel, and @westonruter for their contributions!

     

  • Aaron Jorbin 7:32 pm on December 8, 2016 Permalink |
    Tags: , retrospective   

    4.7 Retrospective 

    A retrospective meeting on the WordPress 4.7  release will be held during the week of December 19th. In order to properly prepare for that retrospective and make the time as productive as possible, I would like to encourage everyone to comment below with things they would like to bring up. To help, here are three good questions to ask yourself:

    • What should WordPress start doing as a part of the development process?
    • What should WordPress stop doing as a part of the development process?
    • What should WordPress continue doing as a part of the development process?

    Please remember when commenting to keep the discussion professional and focused on ways the process of creating WordPress is either already working great or can be improved.

     

    • Aaron Jorbin 7:35 pm on December 8, 2016 Permalink | Log in to Reply

      We failed at getting the field guide and email to plugin dev out early enough. We have aimed to have that out around beta 2 and usually end up getting it out around RC the last few releases. This time it came out the day before (field guide) and day after the release (email)

    • Darren Ethier (nerrad) 7:41 pm on December 8, 2016 Permalink | Log in to Reply

      I’m curious as to how the announcement by Matt about changes to the development process is going to affect this retrospective process. It might be beneficial if there was some clarity surrounding that change brought up at the meeting perhaps? It may be hard to talk about improvements that can be when there’s some ambiguity about what developing WordPress core will look like in 2017.

      • Aaron Jorbin 8:03 pm on December 8, 2016 Permalink | Log in to Reply

        I can’t speak for @matt, but I imagine that the feedback generated will help inform the process in 2017 and going forward.

      • Jeffrey Paul 8:32 pm on December 8, 2016 Permalink | Log in to Reply

        I’d prefer we frame this Retrospective with the current state of core development in mind. Let’s identify the start/stop/continue doing items based on the current approach and as @jorbin says I’m certain it will help inform any changes in the process next year.

    • J.D. Grimes 9:02 pm on December 8, 2016 Permalink | Log in to Reply

      The posts explaining new features and changes are helpful, but I think that we need more of them. I follow the trac feed, and sometimes I know that as a plugin developer a particular ticket is important for me to take note of, but it can be difficult to unravel exactly what the final decision was just based on the changesets. An example of something that is going on right now is the a11y team’s work on removing excessive content from headings on admin screens. Often API changes get documented and UI changes don’t, but I’m a perfectionist and I like to stay up to date on the latest design/a11y evolutions as well. I can usually figure out what changes I might want to make in my plugins based on the changes in core, but I’m sure that often most plugin developers don’t even know that there was a change, if they don’t read every ticket.

      I also think that continuing to plan releases for particular dates and stick by those deadlines is helpful for me as a plugin developer. It helps me to plan plugin releases, because I can coordinate them with WordPress’s release cycle. By coordinating the release cycle of my plugins with WordPress, I can test any extensions against the new versions of both the plugin and WordPress at once, instead of having to duplicate effort in that regard.

    • Nick Halsey 2:49 am on December 9, 2016 Permalink | Log in to Reply

      We need to collectively review the “feature plugin merge guidelines” listed here: https://make.wordpress.org/core/handbook/about/release-cycle/features-as-plugins/#feature-plugin-merge-criteria

      While development in plugins has become less prominent, most of the bigger projects merging into core in 4.7 (I would exclude the REST API since that’s less user-facing) skipped many of the steps here. A lot of the points don’t apply to most projects – to the point that the checklist is often forgotten entirely. But there remains a need for better quality control and an updated checklist or recommended merge considerations for larger projects should be created accordingly. These written guidelines can better inform merge decisions and assess readiness.

      Only one feature posted a visual record on make/flow during 4.7. Prior to beta, that was also the only feature to publish any user testing on make blogs. There should have been far more of that happening, especially given the large number of significant user-oriented features in 4.7. I don’t think any frontend user testing of Twenty Seventeen was ever published either, which would have been a good way to identify potential usability issues.

      On a related note, clearer procedures about backing out merged features are needed. Particularly if a feature goes through an extensive process to demonstrate readiness and is approved for merge, input on removing the feature during beta/RC should be solicited publicly via make/core posts and scheduled meetings, similarly to the initial merge decision. Otherwise, the decision to remove a feature can seem to ignore the value of the opinions that went into making the decision initially and may not be fully informed about the broader implications with respect to related aspects of a component. If work on a feature seems to stagnate as bugs accumulate during beta and a lead is considering pulling it due to lack of attention, contributors working on the feature should be notified so that they can address the issues or recommend removing the feature based on availability. Perhaps putting more trust in the feature teams and component maintainers that are most intimately familiar with a given project could help ensure that decisions are more broadly considered.

    • petj 12:27 pm on December 16, 2016 Permalink | Log in to Reply

      What should WordPress start doing as a part of the development process?

      • make it more clear *how* to contribute with code. Where and how to upload. That kind of information. I know this is a total beginner issue, but it was a major challenge for me to figure out how-to. I think you’d get more code from contributors in that way.

      What should WordPress continue doing as a part of the development process?

      • The combination of a Git startup phase and Slack is excellent. At least for the Twenty Seventeen theme.

    • Weston Ruter 10:28 pm on December 20, 2016 Permalink | Log in to Reply

      Start:

      • Increase user testing base for new features, particularly to include people who specialize in QA being part of the ticket lifecycle.
      • Add automated acceptance testing for the user flows. If we add these for new features added, we can ensure they work across browsers. And in future releases, these tests can ensure that we don’t break existing flows. Run tests on BrowserStack. See #34693.
      • Integrate PHP_CodeSniffer into our build/test tools, allow patches to be checked against coding standards. See #34694.

      Continue:

      • Weekly design meetings.

      • Steven Word 9:12 pm on December 21, 2016 Permalink | Log in to Reply

        I like these ideas. I was talking to a few people at WCUS about the idea of CI for patches in Trac. It would be really nice to see if patches still apply / lint in the patch dev process.

    • Joe McGill 6:44 pm on December 21, 2016 Permalink | Log in to Reply

      I share @celloexpressions concerns about new features being merged without going through the level of scrutiny we’ve previously set for ourselves. While it is not possible/practical for every new feature to go through a plugin development cycle, many of the items in the feature plugin checklist are still applicable. The risk of rushing features is even greater during cycles where we’re trying to ship a new default theme that depends on new features. Video headers and panels are examples of such features from this cycle, even though only one (video headers) ended up in Core.

      Besides having clear criteria and processes for merge decisions of new features, I would also recommend that new features be identified early in release cycles and that we make sure there is at least one core committer responsible for giving oversight (at minimum) to new features during the cycle. This should help us keep a closer eye on the progress being made on new features, and removes confusion about who will be responsible for merging the feature once it is ready. In my previous experience as a contributor to the responsive image feature project in 4.4 (before I had commit access), having @azaozz be part of the process was invaluable and helped us avoid roadblocks when it came to code review and getting code merged into core.

      On the upside, having clear deadlines for when enhancements need to be merged into core is very helpful for prioritizing time and focussing resources. I hope we will continue some form product calendar in the spirit of “deadlines aren’t arbitrary,” even if they take a different rhythm.

    • Andrea Fercia 7:08 pm on December 21, 2016 Permalink | Log in to Reply

      > Integrate PHP_CodeSniffer into our build/test tools, allow patches to be checked against coding standards.
      This would be great and should apply to JavaScript too, especially considering the relevant part JavaScript will probably play in the next future. While there are JavaScript standards for both coding and documentation, I’ve noticed there’s room for improvements even in files or sections of code that were recently committed.

      Start doing: more focus on Trac and tickets, every committer should try to follow Trac on a daily basis. Not to know 100% of the details of each ticket but at least to get a sense of what’s going on. Also, the number of tickets on Trac is increasing more and more, there’s the need of some serious “Trac Gardening” 🙂

      Continue doing: increase the effort to involve different teams in collaborating on features development, where different skills and knowledge are needed, of course.

      Stop doing: ignoring Trac 😉

    • mattyrob 9:35 pm on December 21, 2016 Permalink | Log in to Reply

      I think the good and bad can be summed up in a single word – Communication.

      Things have improved but could still be loads and loads better.

      • Trac is practically ignored or so it seems with many takes years old.
      • Coders are encouraged to contribute code but tickets or patches can lie dormant for long periods of time before being closed as ‘wontfix’ without any apparent consideration of the individual who opened the ticket or created the patch (declaration of conflict – this has happened to me more than once).
      • New features for developers should have a field guide issued as soon as the code is committed, not when a new version is released. The field guide should be a working document and it’s fine if it changes, but more notice of new features and core changes is needed – not RC and ideally before beta even.

      In order to improve communication:
      Perhaps there should be some consideration the core leads spend an equal amount of time on documentation as the core code to get that side of things on the same pace as the core code.
      Perhaps development teams should be consider – small fluid groups with a core lead who can act as a mentor to those keen to contribute but new to this.
      Limit the number of new ‘features’ in any release. WordPress is very mature as a product now, adding new stuff may seem like the way to improve but let’s make sure everything that’s already done is being done as well as it can be.
      Stop releasing a new theme with core each year, or at least break it out and away from the core development. It’d would certainly take a lot of traffic out of the Trac.
      Targetting getting the number of tickets in Trac reduced – the current number simply cannot be managed and it’s getting to the stage where duplicates are frequent and overlap is common.

      I think that’s enough for now 😉

  • Jeffrey Paul 7:16 pm on December 8, 2016 Permalink |
    Tags: , , ,   

    Dev Chat Summary: December 7th (4.7 launch week) 

    This post summarizes the dev chat meeting from December 7th (Slack archive).

    Reminders

    4.7 Issues Reported

    • Caches not always clearing, not something we can fix, but seems to be the most common problem
    • Couple of reports around fatals related to WP_Hook, one traced to APC the cause of the other is still unknown
      • #39132: WP 4.7, object-cache.php breaks the site if APC is not enabled in php
    • We’re unable to pinpoint why lots of folks who meet the requirements still don’t have PDF thumbnails
      • Are there more specific requirements beyond “you need Imagik, ImageMagick and Ghostscript” perhaps specific versions?
      • Many problems so far there have been outright lack of Ghostscript installed, so having the gs info when reporting bugs would be great
      • Discussion continued on capturing ghostscript, Imagick and ImageMagick versions details via a plugin (e.g., a hidden wp-admin/debug.php, https://wordpress.org/plugins/health-check/)
    • Several reports of rest_cannot_edit and similar things from the users endpoints
    • Reports of people getting denied access to the admin area, issue appears to all be caching plugins not being cleared properly
    • #39104: Customize: starter content home menu item needs to be a link, not a page
      • This is concerning for back-compatability and needs to have a coordinated Twenty Seventeen update. The usability implications are somewhat concerning for new sites being created with 4.7.0.
    • #39146: plugin.php gives error on do_all_hook() function
    • #39150: Empty JSON Payload Causes rest_invalid_json
    • Thanks to @macmanx and @clorith and all of the people volunteering in the forums! Would be great for everyone to help answer questions in the forums, its a great way to understand the problems that users are having.

    4.7.1 Planning

    • Discussion on targeting 4.7.1 before the holidays in December 2016 or aiming for January 2017
      • Timing depends heavily on the severity and type of issue(s), and not the amount of issues
      • Target is to get close to a 4.7.1 RC by the end of the year
      • Two bug scrubs happening this week (see the Bug Scrubs reference in Reminders section above) that will give us an idea of what’s realistically close to being ready for a December release.
    • No immediate Release Lead for 4.7.1
    • Handbook reference for releasing minor versions

    4.7 Retrospective

    • We failed at getting the field guide and email to plugin dev out early though. We have aimed to have that out around beta 2 and usually end up getting it out around RC the last few releases.
    • We will post a general request for feedback on Make/Core to capture Retrospective input
    • We will review the feedback and then present it for discussion during the dev chat on December 21st and agree on action items on how we can improve in the future
     

  • Jeffrey Paul 10:16 pm on December 7, 2016 Permalink |
    Tags: ,   

    Bug Scrubs for week of December 5th 

    The following times have been scheduled for bug scrubs this week:

    Thursday, December 8th 10:00am CST. Focus will be on tickets milestoned for 4.7.1 and the conversation will take place in #core.

    Friday, December 9th 20:00 UTC. Focus will be on Customize tickets milestoned for 4.7.1 and the conversation will take place in #core-customize.

     

     

    • iLen 4:25 am on December 8, 2016 Permalink | Log in to Reply

      Excellent, be aware of the new changes that come with version 4.7.1.
      I will also be uploading some requirements that I have found and possibly be new standards in the wordpress core.

  • Aaron Jorbin 9:05 pm on December 5, 2016 Permalink |
    Tags: , ,   

    WordPress 4.7 Field Guide 

    WordPress 4.7 is shaping up to be the best WordPress yet!  Users will receive new and refined features that make it easier to “Make your site, YOUR site”, and developers will be able to take advantage of 173 enhancements and feature requests added.  Let’s look at the many improvements coming in 4.7…

    RESTing, RESTing: 1, 2, 3

    The foundation for RESTful APIs has been in core since 4.4, and 4.7 sees the addition of Content Endpoints after a healthy discussion. We’ve defined four success metrics as part of the merge discussion and you can help by building themes and plugins on top of the API, using the API in custom development projects, and utilizing the API for a feature project, core features, or patches. So, dive in, start playing around, and let us know what you build!

    REST API Merge Proposal, Part 2: Content API

     

    It don’t mean a thing, if you ain’t got a theme

    No matter if you are building themes for public consumption, as a bespoke project for a major public company, or anything in between WordPress 4.7 has something to help you.

    Theming with Twenty Seventeen

    Video Headers in 4.7

    Starter content for themes in 4.7

    Visible Edit Shortcuts in the Customizer Preview

    Whitespace changes in navigation for 4.7

    Post Type Templates in 4.7

    New Post Type Labels in 4.7

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

    The Voyages of USS Media

    Two notable changes, enhanced PDF support in the media library and changes to the default fallbacks for image alt attributes, are explained in separate posts.

    Enhanced PDF Support in WordPress 4.7

    Improving accessibility of image alternative text in 4.7

    Media also received other exciting enhancements and bug fixes you should check out.

    Around the World

    The way users understand the words on WordPress are important and now users will be able to select their personal preferred language.

    User Admin Languages and Locale Switching in 4.7

     

    For Whom Customization Tolls

    The customize component will now support the ability to create pages within live preview during site setup; will have a faster, smoother, and more accessible navigation; will automatically persist your changes in the background while you browse your site and switch themes; and will let you fine-tune your site with custom CSS.

    Customizer Improvements in 4.7

    Customize Changesets Technical Design Decisions

    Changes to Customizer Sliding Panels/Sections in WordPress 4.7

    Extending the Custom CSS editor

     

    Reading, Writing and Teriffic

    Whether you’re creating content in the WordPress Admin or concerned about comment moderation, we’ve got updates that will be sure to please you.

    Editor changes in 4.7

    Comment “allowed” checks in WordPress 4.7

     

    The Foundation of WordPress

    For those who like to get “under the hood” of WordPress, we’ve got some improvements that will hopefully make your life easier.

    Changed loading order for current user in 4.7

    Multisite Focused Changes in 4.7

    Attributes for Resource Hints in 4.7

    wp_list_sort() and WP_List_Util in 4.7

    WP_Taxonomy in 4.7

    Fine grained capabilities for taxonomy terms in 4.7

    WP_Hook: Next Generation Actions and Filters

    Registering your settings in WordPress 4.7

     

    But Wait, There is More!

    Over 447 bugs, 165 enhancements, 8 feature requests, and 15 blessed tasks have been marked as fixed in WordPress 4.7. Some additional ones to highlight include:

    • Make media library searchable by file name (#22744)
    • Improved Custom Background Properties UI (#22058)
    • Hue-only Color Picker (#38263)
    • Fix Sections that .cannot-expand (#37980)
    • Allow Plugins to do Comprehensive Late Validation of Settings (#37638)

    Please, test your code. Fixing issues now, before 4.7 is released, helps you and helps millions of WordPress sites.

     

  • Helen Hou-Sandi 6:26 am on December 3, 2016 Permalink |
    Tags:   

    There is a quiet RC2 now available – it is a fair number of commits (50+), so please take a look through those and test as you can.

     

← Older posts

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar