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

  • Andrew Ozz 2:00 am on July 29, 2016 Permalink |
    Tags: , , , ,   

    Editor changes in 4.6 

    In WordPress 4.6 TinyMCE is upgraded from version 4.3.10 to 4.4.1. There are numerous bug fixes and several new features, most notably a new inline theme (changelog).

    The wpview editor plugin (that is responsible for showing gallery, video, audio, and oEmbed previews) was updated to use the TinyMCE API for non-editable elements. This brought some small changes and improvements in the UI, for example “views” are draggable now. On the back-end the wp-mce-view-unbind event was removed as it doesn’t exist in the API. It was intended for cleanup/unloading but was never very reliable. If a plugin needs to unload instance dependent scripts, it can use mutation observer to monitor when the view node is deleted. See #36434 for more information.

    wpview remains an experimental API, though with each iteration it is getting closer to being finalized. As an experimental API, breaking changes are expected. As always, please test your plugin now if it modifies or depends on the editor, especially if you use experimental features like wpview.

     

  • Eric Binnion 3:40 pm on July 28, 2016 Permalink |
    Tags: ,   

    Week in Core, July 19 – July 26 2016 

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

    • 49 commits
    • 35 contributors
    • 73 tickets created
    • 4 tickets reopened
    • 67 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

    • System fonts: Adjust the smaller tabs so they appear as tabs. [38153] #36753
    • System fonts: Don’t quote single-word font names, per our coding standards. [38152] #36753

    Build/Test Tools

    Comments

    • Introduce the cache_domain argument for WP_Comment_Query to allow caching to a unique set of cache buckets. [38117] #37419
    • Tests: Include the check_comment function tests in the comment group. Adds @group comment notation to the Tests_Comment_CheckComment class. Introduced in [32519]. [38114] #37356

    Cron API

    • Docs: In wp_schedule_single_event(), add a note about scheduling an event to occur within 10 minutes of another event with the same action hook. [38148] #37455

    Database

    • Replace incorrect use of E_USER_NOTICE in wpdb::_real_escape() with the version number where the message was added. [38133] #36403

    Editor

    • Inline link: Remove proxying through WordPress to test if an URL exists. Fix and enhance the regex that tests if the URL is well formed. [38159] #36638
    • Improve styling of “Add Media” button on mobile and make it more consistent with media buttons added by plugins. [38132] #36999
    • Link check: Use wp.a11y.speak() to announce bad URLs. Do not add a title to the link toolbar. Better error message. [38126] #36638

    Feeds

    • Docs: Add missing class, method, and property DocBlocks for feed classes. [38112] #36295

    Filesystem API

    • Filesystem API: Change the default value for the $context parameter of get_filesystem_method() and request_filesystem_credentials() to an empty string. [38138] #37412

    General

    • Docs: Fix typo in hook description for customize_save_validation_before. [38140] #37318
    • Docs: Fix formatting, tense, verb conjugation, and other syntax for wp-includes/* elements introduced or changed in 4.6. [38121] [38125] #37318
    • Docs: Add missing inline documentation in WP_HTTP_Requests_Response. [38120] #37318, #33055

    Media

    • Docs: Update the description of the $box argument of wp_nav_menu_item_taxonomy_meta_box() for consistency with [38129]. Missed in [38130]. [38142] #37211
    • Docs: In meta box functions, clarify that “Meta box ID” refers to the id attribute of the meta box and not a numeric ID. [38131] #37211
    • Docs: Correct and expand the docs for the $taxonomy argument of wp_nav_menu_item_taxonomy_meta_box(). [38128] #37211
    • Docs: Correct and expand the docs for the $post_type argument of wp_nav_menu_item_post_type_meta_box(). [38127] #37211
    • In wp_nav_menu_item_taxonomy_meta_box(): Rename the $taxonomy parameter to $box for clarity and consistency with other meta box functions. [38130] #37211
    • In wp_nav_menu_item_post_type_meta_box(): Rename the $post_type parameter to $box for clarity and consistency with other meta box functions. [38129] #37211
    • In get_page_uri(), don’t prepend a parent page slug if it’s empty. [38145] #36174

    Plugins

    • Use history.pushState() to customize the URL during searches. history.pushState() requires an event handler for popstate which doesn’t exist (yet). [38154] #37233
    • Add a missing space between classes on “ element for custom columns of the Plugins list table. [38149] #37460
    • List Table: Improve WP_Plugins_List_Table::search_box() which was added in [38033]. [38146] #37230
    • Improve Ajax search of new plugins. [38119] #37233
    • Accessibility: Ensure only text is sent to aria-live messages. [38115] #37382
    • Make search field placeholder translatable. [38141] #37230

    Posts, Post Types

    • Remove a redundant function_exists( 'mb_strlen' ) check in get_sample_permalink_html(). mb_strlen() is always available since [32114]. [38147] #30633
    • Unit Tests: Add a @ticket reference for test_get_page_uri_without_argument(). [38144] #26284
    • Unit Tests: Move get_page_uri() tests to post/getPageUri.php, added in [37345]. [38143] #26284

    Post Thumbnails

    • Remove an unused nonce in _wp_post_thumbnail_html(). [38137] #12922
    • Only update featured images when saving a post. [38118] #12922

    Script Loader

    Themes

    • Docs: Fix typo in wp_title() description. [38135] #37442
    • Docs: Change type of WP_Upgrader_Skin::$result to string|bool|WP_Error. [38134] #32246

    TinyMCE

    • Fix the calculation for the inline toolbar vertical position. [38160] #37481
    • wpView:
    • Add the wpview-wrap class and pass third param to the getNodes() callback for back-compat.
    • Attach the mutation observer that resizes a view iframe inside the iframe to minimize memory use/leaks.
    • Remove the wp-mce-view-unbind event. It has never been particularly reliable and now it doesn’t fire when the user deletes a view by typing or pasting over it.
    • Restore changing of a view iframe body classes when the editor body classes change. [38158] #36434
    • TinyMCE, wpView: bail early when the iframe node is not attached to the DOM. We can’t load any HTML in it as here is no iframe.contentWindow in these cases. [38157] #36434
    • Fix selecting an image on touch in iOS Safari for TinyMCE 4.4.1. [38156] #37427
    • Upgrade to 4.4.1, changelog: https://www.tinymce.com/docs/changelog/#version441-july262016. [38155] #37427, #37476

    Upgrade/Install

    • Prevent an endless self-calling loop in wp_tempnam(). [38151] #33999

    Thanks to @adamsilverstein, @afercia, @afineman, @andizer, @azaozz, @bradt, @Chouby, @chriscct7, @crstauf, @DrewAPicture, @flixos90, @FolioVision, @gma992, @helen, @ideag, @inderpreet99, @iseulde, @ixkaito, @joemcgill, @jorbin, @medariox, @mehulkaklotar for initial patch, @mikeschroder, @netweb, @ocean9, @ocean90, @pento, @peterwilsoncc, @rachelbaker, @rahulsprajapati, @rahulsprajapati for initial patch, @ramiy, @SergeyBiryukov, @stevenkword, and @swissspidy for their contributions!

     

  • voldemortensen 10:34 pm on July 27, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: July 27, 2016 

    WordPress 4.6 Release Candidate, announcements and our next steps

    WordPress 4.6 Release Candidate 1 was made available for testing today. If you have any plugins or themes, please starting testing them against WordPress 4.6.

    As always, Release Candidate availability also means there is a string freeze in place and all commits must be reviewed by two or more permanent committers and made by a permanent committer. No exceptions. Guest committers can commit to unit tests at any time.

    There are currently 2 tickets in https://core.trac.wordpress.org/report/6. These and any future tickets shouldn’t be open for longer than 24 hours.

    WordPress 4.6 Release Candidate

    About page

    Unfortunately, the About page wasn’t able to be committed to trunk prior to RC1, but @hugobaeta has been working hard to get it ready. You can see a draft here: https://cloudup.com/cDgw_UvCluc

    WordPress 4.6 still needs a tagline. What should a tagline cover?

    • What do you think people will be the most excited about?
    • What would actually make you keep reading an about page and possibly feel excited to go try something out?

    Much discussion happened during the meeting. You can read the conversation and suggested tag lines starting here: https://wordpress.slack.com/archives/core/p1469651308001266

    Component announcements/updates

    • Trac issues are hopefully fixed.
    • To improve the review workflow during RC @ocean90 is looking into a fix which currently prevents us from branching earlier.

    Open discussion

    #29204 was brought up, but its unfortunately to late to be resolved in the 4.6 release cycle.

     

    Full meeting logs can be found here: https://wordpress.slack.com/archives/core/p1469649667001211

     

  • Dominik Schilling 6:56 pm on July 27, 2016 Permalink |
    Tags: , ,   

    Weekly Dev Chat Agenda for July 27 — Fourteen Weeks Later 

    Agenda for the weekly dev meeting on July 27, 2016 at 20:00 UTC:

    • WordPress 4.6 Release Candidate, announcements and our next steps
    • About page
    • Component announcements/updates
    • Open discussion

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

    See you in the chat!

     

  • voldemortensen 10:47 am on July 27, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: July 20, 2016 

    WordPress 4.6 Beta 4 and current progress

    Beta 4, the last beta before RC1, was released today. Please test and report all bugs you encounter on Trac.
    There are still 9 open tickets that should be closed by RC1 next week. https://core.trac.wordpress.org/report/5

    Dev notes, field guide, email to plugin authors, 4.6 OMGWTFBBQ Draft Post

    • @jorbin started outlining/drafting the field guide and will have a first draft in the next 24 hours for committers to review.
    • The email to plugin authors will be sent in conjunction with the release of RC1.
    • The 4.6 OMGWTFBBQ Draft Post is a post by the support team. You can find it here: https://make.wordpress.org/support/2016/07/4-6-omgwtfbbq-draft-post/. The support team especially appreciate suggestions for the “Not a Bug” section (these are items which are intentional changes, but may seem like a bug or glitch to users offhand, like Dashboard fonts being different).

    About page

    Feature Pointers

    There are no feature pointers planned for 4.6. If your feature is planning on using a feature pointers, please consider if you really need to.

    Let’s find a tagline.

    The brainstorming document can be found here. There are a few suggestions for a tagline already, but please add them to the doc. Please keep it serious.

    Project updates

    register_meta()

    @jeremyfelt published an updated dev note for the recent change (https://make.wordpress.org/core/2016/07/20/additional-register_meta-changes-in-4-6/). It was shipped with beta 4 and also announced in the release post.

    Font Natively

    There are currently some alignment issues related to line-height. These will continue to be worked on as needed. Please report any other issues you may run into.

    Component announcements/updates

    None.

    Open discussion

    None.

     

    You can read the full chat logs here: https://wordpress.slack.com/archives/core/p1469044867000364

     

  • Ryan McCue 10:34 am on July 27, 2016 Permalink |
    Tags: , , http-api   

    HTTP API in 4.6 

    For WordPress 4.6, the HTTP API (wp_remote_request() and family) have undergone a large internal change. Rather than using a WordPress-specific HTTP library, WordPress now uses the open-source independent Requests library, developed by yours truly.

    Why Requests?

    The WP_HTTP library in previous releases has been primarily maintained by myself and @dd32, with my support time split between the two libraries. Both libraries are very similar, and code has been shared between them (when licensing permitted) in the past. Requests follows the same development philosophies as WordPress: developing for the masses with broad PHP support, and maintaining backwards compatibility.

    By switching to Requests, a library without any WordPress-specific dependencies, WordPress benefits from input from the wider PHP ecosystem and community

    Requests also has a huge number of unit tests, with test coverage at 92% of the codebase and increasing. It’s also used by other projects via the Composer ecosystem, including wp-cli’s HTTP functionality.

    What has changed?

    From your perspective as a developer, nothing should have changed visibly. You can and should continue to use WP’s HTTP functions the way you always have.

    (Note: For the 4.6 development cycle and beta 1, the HTTP functions returned an array-like object. Many plugins and themes in the real world are using direct is_array() checks, so it was decided to pull this functionality back a bit to be safe, see #37097.)

    Some new functionality has been introduced. In particular, the array returned from wp_remote_request() now includes a new http_response value, which contains a WP_HTTP_Response object (technically, WP_HTTP_Requests_Response). This shares functionality with WP_REST_Response objects introduced in WordPress 4.4, allowing common functionality to be developed for both APIs. In future releases, WordPress may introduce new WP_HTTP_Request objects as well, allowing common middleware to be used across both APIs.

    In addition, all of Requests’ features are now available in WordPress. This includes things like better HTTP standard support, case-insensitive headers, parallel HTTP requests, support for Internationalized Domain Names (like böcean901.ch), and many other internal improvements.

    Some new features are only available when using Requests::request() directly (such as parallel requests), however, these will be introduced into new WordPress-specific APIs in future releases (#37459). This release is focussing on switching internal implementation and remaining stable.

    For more background on the change, see #33055.

     

    • Primoz Cigler 2:11 pm on July 27, 2016 Permalink | Log in to Reply

      Great news! Reusing existing popular libraries from the broader PHP community is the way to go, especially if they follow modern dev workflow (composer etc).

      Ryan, as I am familiar with Guzzle and you are author of the Requests, would you mind sharing the main differences between these two libraries and your motivation for creating Requests over using Guzzle? Thank you!

      • Claudio Sanches 2:19 pm on July 27, 2016 Permalink | Log in to Reply

      • Ryan McCue 4:56 am on July 28, 2016 Permalink | Log in to Reply

        A few of the reasons are covered in the Why Requests doc posted by Claudio, but there are other reasons specific to WordPress.

        Guzzle is a full REST API consuming library, including a lot of tooling around using APIs, whereas Requests is a simple HTTP library. (That doesn’t make REST requests impossible or anything, it just means it doesn’t offer anything targeted at APIs.)

        Requests is also a lot closer to being a WordPress-y API, purely because my philosophy when creating it was the same as WordPress’. Although it offers more advanced APIs, at the core, Requests offers up a function which makes a request and returns some response data. It doesn’t require usage of conceptually more complex things than arrays and simple object usage.

    • Nashwan Doaqan 4:12 pm on July 27, 2016 Permalink | Log in to Reply

      Great! .. Thanks for all the effort. 🙂

    • Jacob Santos 7:35 pm on July 27, 2016 Permalink | Log in to Reply

      If I am being honest, the HTTP API was always meant to be temporary. It is one of the reasons I advocated using the functions and warned against calling the main class directly.

      It was a simple implementation to pull in the various requests, using curl and fsockopen. I believed I looked for third party libraries, but none included all of the transports or didn’t have a sensible API separation of concerns. One had everything in the single class.

      If I had a vote, I would have requested guzzle. Even if it required contributing fopen transport.

      I will say it is annoying that library authors don’t continue support for previous php versions. However, I have said my goodbyes to php5.2 a long time ago. Any host that still supports that version is really not worth the money. I suspect that they are cheap or free hosts, but damn, php5.2 is almost a decade old. It is also only 7.2% of total usage. I believe php4 was dropped also when it dropped below 10%.

      I would rather wordpress increase to php5.3 and include and support and older version of guzzle than introduce another 5.2 library. More people use and support guzzle currently than the Requests library. 600k for requests vs 17 million + 15 million for guzzle. I do not believe adding 2 more devs to an older guzzle will comvince them to support the older version, but it would allow for a better upgrade path from guzzle supporting 5.3 to the latest guzzle. Backporting and testing should also be easier.

      Requests looks too much like the original wordpress code from when dd32, peter westwood and I wrote it for my comfort. The argument could be made that it requires the less permissive GPL license since it appears to derive from the wordpress code base. Moving to a library that has a more open license with less controversy would make more sense in case someone wants to challenge the Requests license in the future.

      • Ryan McCue 4:50 am on July 28, 2016 Permalink | Log in to Reply

        I think the rest of your points are already covered above or elsewhere, but I wanted to note on the licensing: Requests was entirely written from scratch, and does not incorporate any of WP_HTTP. There have been a few patches created for WP_HTTP that have been ported across to Requests, but the patch authors (namely, me and @dd32) have agreed to licensing those contributions under the ISC license, so there’s no issue with that.

        Most contributions have been in the opposite direction: improvements in Requests have been ported to WP_HTTP. Given that I wrote those patches and contributed them to WP under the terms of the GPL, there’s also no issue with those.

  • Aaron Jorbin 7:18 pm on July 26, 2016 Permalink |
    Tags: , ,   

    WordPress 4.6 Field Guide 

    Many of the changes in the forthcoming WordPress 4.6 are developer-focused changes that take place under the hood. Please remember to test your plugins, themes, and sites with WordPress 4.6 before the release. An hour of testing today can save you days of anguish later.

    Enhanced Meta Registration

    register_meta() is getting some updates to enable greater flexibility and features in the future (such as inclusion in the Rest API). Until now, register_meta() took four arguments. In WordPress 4.6, this will decrease to 3, with the third one being an array of arguments. When register_meta() is used with the old signature in WordPress 4.6, it will continue to function but will now return false. Please read the initial post outlining why register_meta() has been updated and the followup detailing further enhancements.

    Persistent Comment Cache

    Since WordPress 2.6, the comments API has purposefully not used a persistent cache. Over the past 20 releases, changes have been made to purge the problems from the comments API that caused this. If you have a plugin which modifies comment data directly please change them to make use of the various comment API functions or use clean_comment_cache(). You can hit this changes announcement for more info.

    New Object: WP_Post_Type

    Rather than a standard object, there is now a WP_Post_Type for each registered post type. Three functions and three actions have been changed to use this new object. WP_Post_Type provides methods to handle post type supports, rewrite rules, meta boxes, hooks, and taxonomies.

    🛫 Open Sans, 🛬 Native Fonts

    With the continued evolution of system fonts allowing for all devices to have a beautiful looking admin, WordPress 4.6 updates the font stack. To keep your custom admin pages looking consistent with the rest of the WordPress admin, you are encouraged to audit your CSS. The new font stack is:

    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;

    When using this font stack, it must be called using the font-family property, and not the font shorthand. This works around an issue in Microsoft Edge. Additionally, the only font weights used in core now are 400 for general text and 600 for heavier text.

    Shiny Updates

    One of the user-facing features in 4.6 is an update to Shiny Updates, first introduced in 4.2. For developers, the change to pay attention to is that the JavaScript under the updates handle has been refactored and updated to support plugins and themes. If you are dependent on that handle, make sure to read about the shiny updates changes.

    Resource Hints in 4.6

    Resource Hints is a rather new W3C specification that “defines the dns-prefetch, preconnect, prefetch, and prerender relationships of the HTML Link Element (<link>)”. These can be used to assist the browser in the decision process of which origins it should connect to, and which resources it should fetch and preprocess to improve page performance.

    In 4.6, WordPress adds an API to register and use resource hints. The relevant ticket is #34292.

    Developers can use the wp_resource_hints filter to add custom domains and URLs for dns-prefetch, preconnect, prefetch or prerender. One needs to be careful to not add too many resource hints as they could quite easily negatively impact performance, especially on mobile.

    WP_Term_Query

    WordPress 4.6 will introduce WP_Term_Query. This new class brings parity between taxonomy term queries and WP’s other content type queries: WP_Query, WP_Comment_Query, and WP_User_Query. And – as in the case of posts, comments, and users – the get_terms() function has been converted to a wrapper for the new WP_Term_Query.

    Internationalization

    Everyone should be able to use WordPress in the language they want. WordPress 4.6 makes a number of changes to assist with internationalization and localization. Some of the highlights include:

    • Just-in-time loading for translations. You do not have to call load_plugin_textdomain() or load_theme_textdomain() anymore (if you distribute your theme/plugin via wordpress.org).
    • Community translations are now favored over translations which are included in your theme/plugin.
    • Localized jQuery UI datepicker.
    • Support for comment number declension in get_comments_number_text(). See #13651.
    • Fallback for TextDomain header field in get_plugin_data(). See #36706.
    • Updated list of continents and cities for the timezone selector. See #37554.
    • Support for the German (Switzerland) locale in remove_accents(). See #37076.
    • Improved support for month name declension. See #36790.

    Pre-instantiated Widget Registration in 4.6

    Since WP_Widget was introduced in 2.8 the register_widget() and unregister_widget() functions required the class name (string) of a WP_Widget subclass to be supplied. As of 4.6 these functions also accept a class instance (object) of a WP_Widget subclass as well. See #28216.

    Two key benefits of allowing objects to be instantiated are:

    1. Widgets can now be instantiated and registered with constructor dependency injection.
    2. New widget types can now be added dynamically, such as adding a Recent Posts widget for each post type, per #35990.

    New and Improved Customizer APIs

    The customizer has four major changes in WordPress 4.6. The most prominent is a new collection of APIs for validation of setting values. Included in this new notifications API for the customizer.

    Additional changes include some CSS cleanup. Custom controls that use part of the core UI and subclass WP_Customize_Media_Control no longer need to create their own CSS styles that duplicate core rules. Because the markup and styling have changed significantly, please test any custom controls, CSS, or JavaScript that is related to media controls in the customizer.

    If your code uses the customizer, you are encouraged to review the changes.

    Bootstrap/Load Updates in 4.6

    Every time WordPress is loaded, it goes through the bootstrap or loading process. In WordPress 4.6, there will be a few changes to the process focused on making pieces available earlier. Many of these changes will have no effect whatsoever on the vast majority of WordPress sites. However, if you are the type that maintains your own advanced-cache.php drop-in, host/run large profile sites, or work on tools that bootstrap WordPress is odd ways, you need to know about the following changes:

    • Load plugin.php earlier in wp-settings.php
    • is_ssl() is now located in wp-includes/load.php
    • ABSPATH can now be safely defined before WordPress is loaded

    Multisite Focused Changes

    This release, work continues on multisite with a focus on improved APIs and performance. Some highlights include:

    • New WP_Site_Query and WP_Network_Query classes to query sites and networks in a standardized way.
    • Enhancements to WP_Site and WP_Network objects including lazy-loading for site details.
    • A new helper function get_current_network_id() to find the current network’s ID.
    • wp_get_sites() has been deprecated. get_site(), get_sites(), get_network(), and get_networks() are the future.

    External Library Updates

    • Masonry was updated to version 3.3.2 from version 3.1.4.
    • imagesLoaded was updated to version 3.2.0 from version 3.1.4.
    • imagesLoaded can now be enqueued without Masonry being enqueued. For backward compatibility reasons, imagesLoaded remains a dependency for Masonry.
    • MediaElement.js was updated to version 2.22.0 from version 2.18.1.
    • TinyMCE was updated to version 4.4.1 from version 4.3.10.
    • Backbone.js was updated to version 1.3.3 from 1.2.3.

    Summaries for each of these updates and links to full changelogs are available.

    But Wait! There’s More!

    Over 280 bugs, 125 enhancements, 7 feature requests, and 18 blessed tasks have been marked as fixed in WordPress 4.6. Some additional ones include:

    Please, test your code. Fixing issues now, before the release, helps you and helps millions of WordPress sites.

     

    • Jason 3:49 pm on July 28, 2016 Permalink | Log in to Reply

      I would dearly love it if you guys would update the custom menu widget to be “Multi-site” aware, so I could pull menus from other sites on the network and use them. We use Multisite to encapsulate departments but the overall site design requires some semi-static menus that span multiple sites.

      I wrote my own plugin that replicates the feature but if it was built in to the official version it’d be fantastic.

  • Dominik Schilling 1:25 pm on July 25, 2016 Permalink |
    Tags: ,   

    This Week in 4.6: July 25 – 31 

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

    The first release candidate will land on Wednesday at 18:00 UTC. Our target until then is to get the ticket count in the 4.6 milestone down to 0. To hit this goal we have to work on 10 tickets. The release candidate will also mark a soft string freeze. Now is a good time to review some of the string changes in 4.6 and/or to check whether help texts are still accurate.

    Priority tickets this week:

    • General
      • #36753 Native Fonts (needs-patch)
      • #37458 Resource Hints: improve filtering (needs-patch)
      • #37246 4.6 About Page (needs-patch)
    • Editor
      • #36638 Detect broken URLs in the editor (needs-testing)
      • #36434 Consider TinyMCE’s implementation of contenteditable="false" for views (needs-testing)
      • #37427 wpView not working well in IE and iOS Safari (needs-testing)
    • HTTP API
      • #37456 HTTP API regression in transmitted content and headers (has-patch)
      • #37437 Requests_Cookie::parse() unable to parse WP_Http_Cookie object coming from WP_Http::request() (has-patch)
    • Plugins
      • #37233 Shiny Updates: “Add New Plugin” shiny search issues (needs-patch, needs-testing)
    • Bundled Themes
      • #37426 Prepare bundled themes for 4.6 (needs-patch, needs-testing)

    Meetings this week:

    Bug Scrubs

    Weekly Chats

    Notable updates from last week

     

  • Dominik Schilling 7:15 pm on July 20, 2016 Permalink |
    Tags: , ,   

    Weekly Dev Chat Agenda for July 20 — Thirteen Weeks Later 

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

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

    See you in the chat!

     

  • Jeremy Felt 6:27 pm on July 20, 2016 Permalink |
    Tags: , ,   

    Additional register_meta() changes in 4.6 

    In the last 2 weeks, the direction of register_meta() has changed significantly from the original write-up. There was a meeting to discuss some of the changes and a recap of that discussion. Some other discussion after that meeting led to a much more simplified version of register_meta() that is now shipping in 4.6.

    Here’s what registering meta looked like in 4.5. This meta key has sanitization and authorization callbacks.

    register_meta( 'post', 'my_meta_key', 'sanitize_my_meta_key', 'authorize_my_meta_key' );

    The above code will continue to work in 4.6, though will not be considered completely registered. The callbacks will be registered, but the key will not be added to the global registry and register_meta() will return false.

    Here’s what registering meta looks like in 4.6. This meta key will have sanitization and authorization callbacks, and be registered as public for the WordPress REST API.

    $args = array(
    'sanitize_callback' => 'sanitize_my_meta_key',
    'auth_callback' => 'authorize_my_meta_key',
    'type' => 'string',
    'description' => 'My registered meta key',
    'single' => true,
    'show_in_rest' => true,
);
register_meta( 'post', 'my_meta_key', $args );

    The above will register the meta key properly and return true.

    There will no longer be a check for unique object types and subtypes for meta keys. There is no CURIE like syntax involved. Instead, be sure to uniquely prefix meta keys so that they do not conflict with others that may be registered with different arguments.

    Additional helper functions get_registered_metadata(), get_registered_meta_keys(), unregister_meta(), and registered_meta_key_exists() have been added to make the innards of the global data more accessible.

    The $wp_meta_keys variable should not be altered directly. It is possible that its structure will change in the future.

    Any code currently using register_meta() and expecting pre-4.6 behavior will continue to work as is. Please report any breaks in compatibility that might be found.

    For the full history, see #35658. 🙂

     

     

     

← 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