WordPress.org

Make WordPress Core

Updates from Aaron Jorbin Toggle Comment Threads | Keyboard Shortcuts

  • Aaron Jorbin 6:09 am on September 27, 2016 Permalink |
    Tags: ,   

    Bug Scrubs This Week 

    There are a few upcoming bug scrubs in addition to the regular component ones that you should plan on attending. Both of these scrubs will be taking place in the #core slack room.

    Additionally, thanks to @desrosj for running a 4.7 focused scrub on Monday.

    Want to run a bug scrub? Learn about running your own.

     
    • Aaron D. Campbell 5:57 pm on September 27, 2016 Permalink | Log in to Reply

      Unfortunately, something has come up and I had to reschedule my bug scrub. I updated the time in the post. Sorry to anyone this is less convenient for.

  • Aaron Jorbin 3:30 am on September 21, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for September 21 (4.7 week 5) 

    This is the agenda for the weekly dev meeting on September 21, 2016 at 20:00 UTC:

    If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

     
  • Aaron Jorbin 2:40 pm on September 15, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: September 14 (4.7 week 4) 

    This post summarizes the dev chat meeting from September 14th (agenda, Slack archive).

    Reminders

    As of this meeting, we are 5 weeks from the final deadline to merge major features.
    There are a lot of tickets in the milestone and owners / people who milestoned them need to make sure they are active and moving, or else punt. You can use this report see tickets in the milestone grouped by who moved it there:https://core.trac.wordpress.org/report/61.

    Components and features

    Twenty Seventeen (@davidakennedy, @melchoyce)

    Make sure to checkout both the Announcement post and the latest update. There is no formal meeting this week. Development has started on GitHub. Like many feature projects, it will live on GitHub until it is ready to come into SVN (within the next 5 weeks).

    REST API (@krogsgard, @kadamwhite, @joehoyle, @rmccue)

    Core patches, documentation, and reducing the issue backlog have been the primary focuses. There is a settings registry up (https://github.com/WP-API/wp-api-site-endpoints/pull/13) with a corresponding core patch (https://core.trac.wordpress.org/ticket/37885).

    Feedback is needed on #37885.  Please take a look.

    #38056 is needed for password posts. (update: it has landed).

    The next dev chat is Monday September 19 1400 UTC.

    Media (@mikeschroder, @joemcgill)

    • Still looking for feedback/testing on #22744, but planning to commit soon.
      • If you have a large media library, your help in testing would be particularly helpful.
    • @paaljoachim continued researching UI flows in other platforms and posted a bunch of screenshots in #core-images.
    • Joe shared an outline of what we’re trying to accomplish longer term here in#core-images and would like to talk more about it design side of things during the #design meeting tomorrow, if possible.
    • Still waiting to hear back from folks who were involved in starting up the Core Media Widget #32417 work, but travel has been an issue. Hopefully we’ll have a better update there next week.

    Customize (@westonruter, @celloexpressions)

    • @boone is thinking about/investigating ⁠⁠⁠⁠term_status⁠⁠⁠⁠ for #38015. We have some time to think about it, and could potentially use shadow/draft taxonomies as a workaround for #38014 in 4.7 if needed.
    • tracking the ability to add page stubs or create pages directly from the static front page controls along with this project to facilitate creating pages for initial site setup within the customizer. @westonruter is leading the way on #38013.
    • #34391 is a significant refactoring of code that themes and plugins are encouraged to extend. A corresponding make/core post will follow soon after.
      • Already working with some plugin, theme, and framework authors to minimize breakage.
    • We need some feedback now on #35395 – Custom CSS – @johnregan3 is making great progress.  Please check out the ticket.

    i18n (@swissspidy)

    • #29783 (User Admin Language): in good shape, but not much testing happening so far. We could do much more when #26511 is in core though…
    • #26511 (switch_to_locale()): needs some much needed performance testing. If anyone runs a large WordPress site, I could use your help!
      Also since there are some similarities with switch_to_blog(), I’ll open a new ticket to suggest adding a WP_State interface for such switching functions. Think WP_Site_State, WP_Locale_State, WP_Post_State (see #19572), etc. Not a blocker, but worth keeping in mind for future compatibility.
    • #20491 (JS i18n): I documented the current state in the tasks with responsibilities etc. As of tomorrow I’ll have more time to work on it (mainly on the GlotPress side of things). Also have been thinking about a switch_to_locale() function in JS via Ajax…

    Editor (@azaozz, @iseulde)

    • Post your wishlist items for the editor.

    HTTPS (@johnbillion)

    • Plan of attack for HTTPS work will be published on Make/Core.

    Open floor for tickets and any lingering 4.7 ideas.

    Please review and comment on these tickets:

     
  • Aaron Jorbin 3:27 pm on September 12, 2016 Permalink |
    Tags: ,   

    The Upcoming Week in 4.7: 12 September – 18 September 

    This is the jump-start post for the third week of the WordPress 4.7 release cycle. This release is off to a 🚀 start, and there are 5 weeks remaining for feature projects to be merged. 

    Priorities this week:

    #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call landed recently.  Please make sure to read the associated post and test.

    42 tickets currently milestoned for 4.7 need a patch or unit tests.

    A Media Widget is a commonly requested feature; get involved with #32417 if you would like to make it a reality.

    Core meetings this week:

    All meetings in the WordPress Slack #core channel unless specified otherwise.

    Things to do this week:

     
    • Nick Halsey 4:09 pm on September 12, 2016 Permalink | Log in to Reply

      Don’t forget about the weekly customize meetings on Mondays at 17:00 UTC in #core-customize (for 4.7). It’s on make/meetings, but missing from the sidebar and these posts.

  • Aaron Jorbin 12:16 pm on August 30, 2016 Permalink |
    Tags: ,   

    The Upcoming Week in 4.7: August 30 – September 4 

    This is the jump-start post for the first week of the WordPress 4.7 release cycle. Many projects are still putting together pinkprints for success, so this week is all about getting 4.7 off to a flying start. 🛫

    Priority tickets this week:

    There are currently 3 tickets that require very early consideration.  Please follow them, give feedback, and help test where applicable.

    • #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
    • #37699: Death to Globals Episode #1: A Registry, A Pattern
    • #36335: Next generation: core autoloader proposal

    Core meetings this week:

    All meetings in the WordPress Slack #core channel unless specified otherwise.

    Things to do this week:

    • Meander through the wishlist comments and give feedback where you feel comfortable
    • Working on a project that you would like to target for 4.7?  Make sure to talk to @helen.
    • Schedule a bug scrub.
     
  • Aaron Jorbin 8:02 pm on August 25, 2016 Permalink |
    Tags: ,   

    Bug Scrubs for 4.7 

    Ensuring tickets move towards a resolution is one of the most important things we can work on as a project. Bug Scrubs serve as one of the ways to make this happen. For 4.7, I would like to invite you to run a WordPress bug scrub. Bug Scrubs can have a general focus, focus on a specific component, or focus on a specific report (such as ancient tickets). Want to learn more? Here is a list of “Potentially Asked Questions”. Have an unanswered question? Ask it in the comments.

    (More …)

     
  • Aaron Jorbin 4:26 pm on August 13, 2016 Permalink |
    Tags: , ,   

    Global overloading in advanced-cache.php 

    As a part of the 4.6 release, a change is made to the order of loading files during the bootstrap process. This change included an attempt to protect sites from the overloading of the hook related globals in advanced-cache.php. This change was reverted with [38251]. This means that the 4.5 behavior where if an advanced-cache.php sets one of the globals to an empty array, previously entered records will not exist.

    This is a general reminder to not directly touch the globals in WordPress and to always use API functions. The format that the globals are in is not guaranteed to stay consistent from version to version. If you need to interact with the Plugins API in advanced-cache.php, as of 4.6, you can use the Plugins API (add_action(), add_filter(), etc.).

    How to know if you are using advanced-cache.php

    advanced-cache.php is a drop-in. If you are using any drop-ins, you will see “Drop-ins” at the top of wp-admin/plugins.php as one of the filtering options. If advanced-cache.php is listed and no warning is displayed, your site is using it. This file lives in your wp-content directory as a peer to plugins and themes. Updates to it are not made like updates to plugins. You will never see a notice that there is an update pending. If you did not write this code yourself, you are encouraged to keep up to date with upstream updates.

     
    • Knut Sparhell 6:13 pm on August 13, 2016 Permalink | Log in to Reply

      Please change “advance-cache.php” in the h3 to “advanced-cache.php” to avoid any confusion.

    • Gal Baras 9:51 am on August 14, 2016 Permalink | Log in to Reply

      Will this affect WP Super Cache or WP Fastest Cache?

      • Dion Hulse 12:15 am on August 15, 2016 Permalink | Log in to Reply

        We’ve looked at the popular plugins and have seen no negative side effects for the existing versions of open-source caching plugins, nor have any issues been reported during the 4.6 development cycle.

  • Aaron Jorbin 3:53 pm on August 1, 2016 Permalink |
    Tags:   

    Release Leads: Call for Volunteers 

    WordPress 4.6 will be released in a couple of weeks, and Helen Hou-Sandí is preparing to lead 4.7, the final major release of 2016. With five months left in 2016, it’s time to start considering release leads for 2017.

    Giving release leads time to prepare is beneficial to the success of the release. It might seem advantageous to announce a year’s worth of release leads, but it puts the first and even second release lead at a disadvantage. Going forward, identifying and pre-announcing the next two release leads will help give them time to prepare. For example, at the start of the 4.8 cycle, both the 4.9 and 5.0 release leads should be confirmed.

    Leading a release is a substantial time commitment. It blends aspects of being a product manager, project manager, engineering manager, and release manager. The release lead works across teams to ensure the success of the release. They are supported by the lead developers, permanent committers, and deputies of their choosing. Release leads do not need to be developers, but having experience contributing to WordPress is recommended.

    Here’s how some previous release leads have described the role:

    Leading a release of WordPress is both a highly satisfying and highly draining experience. It’ll take as much of your time as you let it, but this comes with the opportunity to help millions of folks tell their stories and make a living.

    My experience was that it is 75% volunteer coordination and 25% project planning/execution, but this can vary depending on your skills and those of your deputies. Being a release deputy is a great way to give it a try and learn about the process, but with a smaller time commitment.

    I highly recommend consulting your significant other, previous release leads, and your boss before volunteering for either one.

    — Mike Schroder, 3.9 co-lead and 4.5 release lead.

    I found leading a release to be both daunting and supremely rewarding at the same time. When I led the 4.2 cycle, I found it to be a valuable lesson in organizing priorities and resources. I also got a crash course in project management that ultimately translated into approaching my daily work in a much more efficient way.

    It’s fun, though also a lot of hard work corralling all of the little details and coordinating communication between teams. Remember: there’s nothing saying a release lead has to be a developer or a designer or a project manager or whathaveyou. The only real must is having a reasonably good handle on how core development works and the philosophies that govern decision making. Everything else is up to you.

    If you feel like you’re looking to level up on contributing to WordPress, leading a release might be just the challenge for you.

    — Drew Jaynes, 4.2 release lead.

    Are you interested?

    If you are interested in volunteering to be a release lead, please comment here or contact either myself (@jorbin) or Helen (@helen) on Slack.

     
  • 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-prefetchpreconnect, 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

    Alert: A late change was made to <a href=”https://make.wordpress.org/core/2016/08/13/global-overloading-in-advanced-cache-php/”>remove protection for overloading Plugin API related global variables</a> in <code>advanced-cache.php</code>

    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.

    • Jesse Petersen 2:25 pm on August 1, 2016 Permalink | Log in to Reply

      Thanks for the great field guide, @jorbin. The effort is appreciated.

    • Marlon Amancio 2:46 pm on August 1, 2016 Permalink | Log in to Reply

      Great overview! Thanks @jorbin

    • @mercime 1:26 am on August 3, 2016 Permalink | Log in to Reply

      Thanks for the good news @jorbin and to all the contributors for the very cool improvements this dev cycle!

    • sjmur 9:08 pm on August 16, 2016 Permalink | Log in to Reply

      WP_Term_Query is going to be awfully useful for me day to day. Thanks!

      Can’t wait to jump back into the core for 4.7

    • Kevin Vess 1:29 am on August 24, 2016 Permalink | Log in to Reply

      For Internationalization, you said, “You do not have to call load_plugin_textdomain() or load_theme_textdomain() anymore (if you distribute your theme/plugin via wordpress.org).”

      I didn’t include the load_plugin_textdomain() function in my plugin because of this; but since the release of WordPress 4.6 I’m still getting the “This plugin is not properly prepared for localization” message:
      https://translate.wordpress.org/projects/wp-plugins/wp-force-login

      Can you tell me what I need to do to make my plugin prepared for localization? Thanks!

  • Aaron Jorbin 5:15 pm on July 6, 2016 Permalink |
    Tags: , ,   

    Bootstrap/Load updates in 4.6 

    Alert: A change was made to remove protection for overloading Plugin API related global variables in advanced-cache.php

    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 than this article is for you!

    Load plugin.php earlier in wp-settings.php

    plugin.php contains the functions such as add_filter() and add_action() that form the foundation of the WordPress plugin system. The file (and thus those functions) are now being loaded earlier in wp-settings.php. This allows for some hooks to be placed earlier, but also for advance-cache.php drop-ins to use the plugins API rather than directly manipulating global variables. For more information, see #36819.

    Reconcile wp-settings-cli.php with wp-settings.php

    Any time WordPress made a change to wp-settings.php, it inevitably broke WP-CLI. In order to allow WP-CLI to no longer need to maintain a custom fork, a handful of new hooks were added to the bootstrap process. These hooks happen before plugins load. They are designed more for non-web uses such as WP-CLI. For more information about these hooks, see #34936.

    is_ssl() is now located in wp-includes/load.php

    Many advanced-cache.php drop-ins duplicate is_ssl(). They will no longer need to do that as it will be available earlier in the bootstrap process. See #35844 for more info on this change.

    ABSPATH can now be safely defined before WordPress is loaded

    Defining ABSPATH in an auto_prepend_file will no longer cause notices to be generated. This can lead to less complexity for some WordPress specific hosts. See #26592 for more info on this change.

    In conclusion

    The bootstrap process provides the foundation for WordPress. It’s not pure, but dang zimit, it works. These changes are all expected to be backward compatible. Please test and report any regressions on Trac.

    Thanks to the following people who contributed to the Bootstrap component this release. @jorbin @danielbachhuber @DrewAPicture @ocean90 @barry @SergeyBiryukov @johnjamesjacoby

     
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