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 21: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

  • Eric Andrew Lewis 9:40 pm on February 12, 2016 Permalink |  

    PHP Unit Test Discussion (Feb. 12) Recap 

    We had a lively discussion about our PHP unit tests today.

    Our goal here is to make writing unit tests a straight-forward, understandable experience by updating the PHP Unit Test handbook page.

    During the meeting, we landed on some practical changes for the handbook page we can make soon.

    • VVV has out-of-the-box support for running WP PHP unit tests. We should suggest using it without giving it an obvious endorsement, as it is not officially endorsed by the project.
    • Getting phpunit running with MAMP (the application) is hard. We should link to Boone’s tutorial on the topic.

    The rest of the meeting moved towards outlining our current approach to unit tests, especially in structure. We should discuss if these are best practices, and develop agreed upon standards for the project.

    • Our tests are organized into folders based on component. (browse the phpunit/tests folder)
    • There are a good number of top-level test files in the /tests folder. New tests should not go in these files.
    • We should consider migrating top-level test files into their respective component folders.
    • Tests for a specific function should go inside a single file within a component directory.
    • Generally the test file path has taken the form /tests/phpunit/tests/{component}/{functionInCamelCase}.php
    • Generally a file’s test class has taken the form Tests_{Component}_{FunctionInCamelCase}
    • Test method names should take the format test_{{description_of_what_is_expected}}. For example, test_termmeta_cache_should_be_primed_by_default.

    Please leave a comment here if you have any thoughts.

    I’ll schedule a meeting next week to continue our discussion.

    Thanks to everyone who attended, this was a great meeting.

     
  • Chris Christoff (chriscct7) 5:49 am on February 12, 2016 Permalink |
    Tags: ,   

    Call for Trac Tickets and Recap of 2/5/2016 Bug Scrub 

    On Friday, February 5th at 17:00 UTC, we had our regularly scheduled bug scrub. As a reminder, for the 4.5 release, trac bug scrubs will be held weekly each Friday at 17:00 UTC. Bug scrubs are held in the #core channel of WordPress Slack.

    The Slack archive for last week’s meeting begins here: https://wordpress.slack.com/archives/core/p1454691785001716

    During the bug scrub, the following tickets were covered:

    #25247, #34722, #27272, #22198, #14393, #19627, #34521, #35630, #35692, #20419, #35737, #34887, #34996, #33045, #30352, #35624, #15448, #35736

    Today, on Friday, February 12 2016 at 17:00 UTC the bug scrub will run approximately 1 hour. Participants need not be present for the full duration, and everyone is welcome to attend.

    We’ll start with a list of pre-submitted tickets, before going to an open floor.

    If you would like to submit a ticket for consideration for the bug scrub, please comment below with the ticket number. If you have extensive knowledge of the ticket, attending or adding accompanying text which provides a brief description of each ticket, its current status, and what needs to happen for the ticket would be appreciated. Bug scrubs are a great way to get extra eyes on tickets, feedback on patches, or suggestions on future routes.

    Note: this will be the last pre-submitted tickets/open-floor style bug scrub for this release. All bug scrubs after this will focus exclusively on tickets currently milestoned for this major release in order to help expedite the betas and release candidates of the 4.5 release. Normal open-floor/pre-submitted ticket bug scrubs will resume after the stable release of 4.5.

     
  • Grant Palin 4:13 am on February 11, 2016 Permalink |
    Tags: ,   

    Week in Core, Feb. 2-9 2016 

    Hi everybody! Welcome back to the latest issue of Week in Core, covering changes from February 2nd [36471] – February 9th [36504], changesets [36471-36504]. Here are the highlights:

    • 34 commits
    • 19 contributors with props
    • 114 tickets created
    • 13 tickets reopened
    • 52 tickets closed

    Ticket numbers based on trac timeline for the period above.

    Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

    Code Updates

    Accessibility

    • Simplify the Plugins and Themes tables on the Updates screen. [36477] #34780

    Administration

    • In login_header(), use correct separator for RTL locales. [36487] #35737

    Comments

    Database

    • Use the new wpdb::close() method for closing the DB connection. [36478] #34903

    Docs

    Posts

    • Make the $post param optional in get_post_field(). When $post is null, the current post object will be returned. [36481] #35683

    Taxonomy

    • Allow get_terms() results to ordered by metadata. […] This brings order-by-meta support for terms in line with post, comment, and user queries. [36485] #34996
    • WP_Query taxonomy query vars should be set to first of multiple taxonomies […] for better parity with get_queried_object(), which will return the first taxonomy/term matched by the current query. [36484] #35619

    Themes

    • Pass information about the old theme in the form of a WP_Theme object when the switch_theme action is fired. [36502] #22401

    TinyMCE

    Users

    • Display the new user email notice in user admin too. Also […], use the global $pagenow and add a translators comment for the placeholder. [36504] #35767
    • Use self_admin_url() for the email change confirmation link – prevents sending users to wp-admin/profile.php if they only have access to wp-admin/user/profile.php. [36503] #35766
    • When updating a user, invalidate its ‘userslugs’ cache. [36482] #35750

    Props

    Thanks to @afercia, @azaozz, @boonebgorges, @Chouby, @danielbachhuber, @DrewAPicture, @eherman24, @finnj, @Frozzare, @jadpm, @kouratoras, @markoheijnen, @MikeHansenMe, @ocean90, @pento, @ramiy, @sebastianpisula, @SergeyBiryukov, and @thebrandonallen for their contributions!

     
  • Adam Silverstein 3:11 am on February 11, 2016 Permalink |
    Tags: , ,   

    Core Dev chat notes for Feb 10 

    Agenda:

    Schedule Notes, Status Updates, Open Floor

    Schedule Notes

    • Today is the feature plugin decision deadline: Responsive Preview and Selective Refresh will be merged.
    • Next Wednesday (Feb 17) is the deadline for merge for these, with beta scheduled for the week after, on Feb 24.
    • Reminder: once beta ships, no more enhancements can be committed, so anything that is left or close to finished needs to be shored up in the next two weeks. Enhancements mile-stoned for 4.5 need attention to make it into the release in time.
    • Any help triaging the 4.5 milestone is definitely appreciated.
    • The REST API team’s proposal is to merge the four main endpoints when they are ready, and they are not ready for 4.5. As such, no endpoints are targeted for WordPress 4.5. A summary of last week’s chat is on make/core: leave feedback there or in the #core-restapi Slack channel.

    Status Updates:

    • Image Improvements: @joemcgill
      •  Cache output of `wp_upload_dir()` to improve performance (#34359) is about ready to go in after some unit test updates )
      • Making progress on Improving Imagick file sizes (#33642) and Better animated GIF handling (#28474)
      • @markoheijnen made some interesting progress on generating thumbnails of PDFs in the media library and could use some feedback if you’re interested #31050.
    • HTTPS Improvements: @johnbillion
      • Plan is enforcing HTTPS on a per-feature basis (eg. enqueued assets, post content, redirects, canonical, links).
      • HTTPS-by-default on install will be something to aim for for 4.6, but we’ll see what happens over this next week.
    • Customizer: @westonruter, @celloexpressions
      • Pushed out the new version of the Customize Partial Refresh plugin. Needs testing!
      • Introduces a framework for registering partials (refreshable regions) with complete rewrites of nav menu partial refresh and re-implementation of widget partial refresh to use the new framework.
      • Going to write a Make Core post about it, documenting the API.
      • Biggest question is whether widgets should opt-in for selective refresh by default. Widgets that use JavaScript for their display will need get updated to work with selective refresh.
      • Responsive Preview (#31995) @valendesigns:  need to add unit tests and address any remaining issues
    • Multisite/WP_Site: @jeremyfelt
      • 15 tickets on the 4.5 milestone. Hoping to establish readiness for these over the next week and get some stuff in.
      • Going to start focusing more multisite related energy toward the REST API’s site (and meta) endpoints.
    • Editor: @azaozz, @iseulde
      • No updates this week: planning to get paste shortcuts in and work on mce views.

    Open Floor

     
  • Daniel Bachhuber 4:50 pm on February 9, 2016 Permalink |
    Tags: , ,   

    WP REST API: Version 2.0 Beta 12 

    Happy Tuesday 🙂 The WP REST API team is proud to bring you: 2.0 Beta 12 “Canyonero”. Download it from the plugin repository or from GitHub.

    Here are some highlightsbreaking changes from the changelog:

    • Removes meta endpoints from primary plugin. If your project depends on post meta endpoints, please install WP REST API Meta Endpoints. For the gory history of meta, read #1425 and linked issues. At this time, we recommend using register_rest_field() to expose meta (docs).
    • Returns original resource when deleting PTCU. Now that all resources require the force param, we don’t need to wrap delete responses with the trash state.
    • Uses roles rather than role in the Users controller. Building the REST API gives us the opportunity to standardize on roles, instead of having both roles and role.
    • Moves to consistent use of context throughout controllers. Contexts limit the data present in the response. Here’s how to think of them: embed correlates with sidebar representation, view represents the primary public view, and edit is the data expected for an editor.
    • Removes post_* query param support for GET /wp/v2/comments. The proper pattern is to use GET /wp/v2/posts to fetch the post IDs to limit the request to.
    • Introduces rest_validate_request_arg()/rest_sanitize_request_arg(). Dedicated functions means we can use them for validating / sanitizing query args too. Removes WP_REST_Controller::validate_schema_property() and WP_REST_Controller::sanitize_schema_property().

    As always, we have a detailed changelog as well as the full set of changes if you’re interested.

    What’s the future of the WP REST API? I’d like to leave you with this final thought:

    What came first, the chicken or the egg?
    I egged the chicken, and then I ate his leg

     
    • Joshua David Nelson 7:38 pm on February 9, 2016 Permalink | Log in to Reply

      I feel compelled to end debate of the chicken and egg. The answer is egg. The egg came first, from which a chicken would be born as a mutated version of the chicken’s previous ancestor. That’s how evolution works. Speaking of which, it’s great to be tracking the evolution of the REST API – thanks for the update and hard work!

  • Eric Andrew Lewis 9:49 pm on February 8, 2016 Permalink |  

    PHP Unit Test Documentation Meeting 

    Writing unit tests is absolutely necessary when modifying functionality in WordPress core. Unit tests assure us that our code does what we expect it to do, and that changes we make don’t produce collateral damage.

    How do you write these oh-so-important unit tests? Well, we have documentation on the topic, but it just reads “TODO”. Let’s do!

    We’ll meet in #core on Friday, February 12th 7pm UTC for a working session to discuss and document PHP unit test authoring practices. Come!

     
  • Adam Silverstein 4:58 pm on February 5, 2016 Permalink |
    Tags: ,   

    REST API meeting summary, Feb 4 

    The core REST API team, members of the WordPress.com API team, and other interested developers met to discuss the REST API.  Full logs of the meeting are available on Slack.

    Existing endpoints

    The meeting opened with a discussion of the existing endpoints: what is and isn’t ready. @rmccue summarized:

    • The main focus has been on the 4 “core” objects in WordPress: posts, terms, comments, and users.
    • Posts
      • Password-protected posts are going to be ignored from the API until we have a good solution.
      • Meta
        • Post (and other) meta has been pushed out into a separate feature plugin led by @jeremyfelt. Discussion is on the github repo.
        • The main issue is that there’s no differentiation between meta fields. Meta could be added via the Custom Fields meta box, or by a plugin.
        • Enhancing register_meta() in core would allow opt-in to the meta REST API – requiring some core work. See the patch on #35658 for details.
        • There is no current way to explicitly register meta as public.
        • We need to support object meta (post, user, comment, term) and object types (custom post types, etc)
      • Media
        • Mostly complete (it’s a custom post type).
        • Some special handling around uploading media.
      • Autosaves and post previews
        • Tricky, but we think we have a solution for that moving forward.
        • Working on them in a separate feature plugin instead.
        • This will be an enhancement to the API in the future, and doesn’t block compatibility.
    • Terms
      • Work great.
    • Users
      • Works great; undergoing final review.
    • Comments
      • Works; custom comment types are harder until core better supports them.

    Merge proposal and discussion

    An extensive discussion ensued regarding the possibility and appropriateness of merging the endpoints into core. The discussion continued for over an hour; mainly covering whether we should merge the 4 core endpoints, or wait for a complete API before merging…  and what the definition of a complete API is.

    The REST API team’s proposal is that we merge the 4 core objects in the REST API with full read, create, update, delete support, then add more peripheral features when they’re ready. 

    @matt argued that we wait until the API supports everything you can do in wp-admin before merging.

    The discussion revolved around these proposals and what is best for the WordPress project. Would merging the existing well developed endpoints sooner help or hinder developer adoption, and further iteration/improvement? Would delaying the endpoint merge help or hinder progress?

    Here are some key comments from the discussion.

    • @rmccue  The approach to the API needs to change from “the API team creates all of the API” to “the API team controls the general shape of the API, and each team works with it”
    • @danielbachhuber Options / a Site Resource is more easily viable, as are Plugins and Themes. Widgets and Menus essentially need to be reinvented before they’ll work in a REST API
    • @jnylen It’s a question of when, and how much testing can be done first. Shipping an API that is read-only and incomplete in several key areas feels like a big mistake.
    • @kadamwhite we’re shipping an API with write capabilities but only cookie-based auth will be supported OOTB.
    • @matt  I would be pretty skeptical of merging a partial API into core…  no partial endpoints in core. let’s design a complete API, not half-do it.
    • @rmccue The API is specifically structured around progressive enhancement
    • @jorbin I think only supporting the four core object types allows for some amazing themes and amazing content editors to be created, but doesn’t allow for full wp-admin replacements. I’m ok with that.
    • @jnylen From what I’ve seen so far, I’m most concerned about shipping individual endpoints with missing features.
    • @jorbin I think the best way to pick up the pace is to get key things locked up and get the four core object types in core. This would help core develop API-first for those features
    • @codebykat On the WPCOM side, we’re committed to taking the plunge, but we’re not there yet which means things are untested.
    • @jnylen I think this needs more testing at large scale before shipping, including some of the more difficult and obscure features of WP.
    • @drew Shipping with full wp-admin replacement capability is unrealistic, imo. We need something flexible and stable that developers can use as solid jumping off point. All the rest can get separately iterated.
    • @mike I think that, realistically, to ship the API… we need an MVP, and I don’t think that defining our goalpost as “all of wp-admin” fits that criteria.
    • @matt Full wp-admin coverage is a firm goalpost, it gives us a super clear criteria for when it should be merged into core. is everything possible in wp-admin, possible through the API?
     
    • Matt Mullenweg 7:12 pm on February 5, 2016 Permalink | Log in to Reply

      We got on a bit of a rabbit hole on file editing in WP, and whether that should be in any API.

      I’m inclined toward no, but I think decisions about what we’re not going to support in the API should be made as deliberately as if we were removing the feature from WP itself. We should make that sort of decision explicitly and proactively, not allow things to die on the vine of existing in wp-admin but not the API.

      It’s also going to be difficult because there is often a big gap between what developers do and what people for whom WP is their entire interface do, which file editing accidentally illustrates very well. (What developer would trade their IDE or text editor for a form on a web page?)

      It might be easier to actually build out APIs for everything first and then choose whether to ship them or not than argue about whether they should be built in the first place, which is inevitably a realm of opinion, values, and sparse data.

      • Omaar Osmaan 7:47 pm on February 5, 2016 Permalink | Log in to Reply

        Absolutely- I like the idea of having API in core that allows to replace WP-Admin without loosing any feature it has. While so far I do have the itch of “get it in core faster”, but I really think your strategy is appropriately sound.

        It’s great to see the arguments- and for sure it all would make it only better in the end.

        My 2 cents.

    • Justin Sternberg 8:11 pm on February 5, 2016 Permalink | Log in to Reply

      Agree on iteration/MVP approach. Full wp-admin coverage, to me, is way overkill for initial merge to core. There is value in “paving the cow paths”… Let’s get the MVP working 100% and merged, and figure out what the next most valuable addition will be. Rinse and repeat.

    • K.Adam White 9:05 pm on February 5, 2016 Permalink | Log in to Reply

      The wp-admin parity argument caught me off-guard, which I believe stems from there being two basic types of use-case. Both types of usage are (and should be) valid:

      We (Bocoup, a non-WP-oriented company) have used the WP-API project to take advantage of the existing wp-admin editing interface, and has used the API solely to flow WordPress-authored data into or out of other applications. Without the API we would never have considered using WordPress for these projects: but the existence of a RESTful/non-XMLRPC interface made WP a big win for both us and our clients.

      Matt’s / Automattic’s experience is the complement to ours: Maintain the existing theme/plugin front-end, but put a custom admin interface behind it.

      The original “json-api” plugin was created by MoMA to flow WP data into a Ruby project; We’ve used the API to flow data into Node applications, and Java and C# clients for the WP-API are also under development. Our use-case is not new, and I believe it represents a significantly larger _potential_ target audience than any wp-admin re-skin does (at present). Daniel Bachhuber hypothesized recently that the way we’ll get WP to “100% of the web” isn’t by moving those sites to WordPress, but rather to allow WordPress to be integrated with existing platforms where appropriate.

      Waiting for API parity with wp-admin suits the Calypso use-case, but delaying core integration of API endpoints for basic WP data types will effectively block a significant group of potential adopters coming from external platforms. Right this second may not be the time, but unless we roll the API into core progressively (hopefully no later than 4.6/4.7) I think we are missing a tremendous opportunity.

      “ — Thank you to everyone involved with the project for being involved in this discussion.

    • Mike Nelson 4:44 am on February 6, 2016 Permalink | Log in to Reply

      > I would be pretty skeptical of merging a partial API into core… no partial endpoints in core. let’s design a complete API, not half-do it.

      Did @matt suggest that thinking it would be easier to iterate the API as a plugin than in core? Or what’s the motivation for this suggestion? I think lots of us give his suggestion a lot of weight, but because I wasn’t at the meeting I don’t understand it

      • Matt Mullenweg 9:30 pm on February 8, 2016 Permalink | Log in to Reply

        I’m 100% for continued iteration, and yes I think that would be easier as a plugin than in core.

        Everyone who wants the functionality today can have it in the plugin with just a few clicks, and we can update that with new functionality as much as often as we want, and if something goes wrong in only affects ~10k users. We know that most WP sites have 5 or 6 active plugins, with professionally-developed sites typically 2-3x that.

        In core we can only do major updates 3 times a year, at most, bundled with lots of other things and concerns that go into a major release, and those updates go out to tens of millions of sites. If we break something it’s in the mainstream tech news. What’s included or not depends on the release lead.

    • Philip Arthur Moore 11:03 am on February 6, 2016 Permalink | Log in to Reply

      I haven’t been involved in the development of this at all, but as a plugin/theme/custom web solutions developer I’d have to strongly agree with @matt with regard to setting full /wp-admin/ coverage as a firm goalpost before inclusion. What’s been keeping me from diving into the API and using it over what we have now is that I’m afraid of changes that may break things and not really sure what I can do with /wp-admin/ that I can’t do with the API. If there’s full parity then I can confidently jump into using the API; until then I feel largely like a spectator seeing how the development of the API plays out before overcommitting our resources to learning it and developing for it.

    • Mike Nelson 1:04 am on February 9, 2016 Permalink | Log in to Reply

      I didn’t think [putting the WP API scaffording in core would] increase the plugin usage, I thought it would increase plugins registering their own APIs, because they hadn’t before because of cross-plugin dependency see https://wordpress.slack.com/archives/core-restapi/p1454633785001643

      I don’t know about other plugins, but at least at Event Espresso we put our REST API, which depends on the WP API infrastructure, into our main plugin directly as a result of putting the WP API infrastructure into WP core 4.5. (See https://eventespresso.com/2016/01/rest-api-now-in-ee4-core/)

      We had some reservations though, thinking that maybe we would wait until the WP API endpoints were also in core (because that would be proof the WP API infrastructure would be more solid and less likely to break). It’s possible other plugins are having the same reservation?

      What’s more, the Event Espresso REST API is a little unique in that we’re using a LOT of custom tables, and our functionality is quite independent of WordPress’ posts etc, and so our REST API can exist quite happily without the WP API’s endpoints. I suspect most plugins’ APIs are much more dependent on WP API’s endpoints in order to work. Eg, there’s not much point in a YARPP REST API without WP API. Meaning, if WP API’s core endpoints are still in a plugin, their users STILL need to use the WP API plugin in order to use their plugin’s API… so just adding the WP API infrastructure isn’t much help to them: they need the endpoints too.

    • rclilly 7:18 pm on February 12, 2016 Permalink | Log in to Reply

      After reading this summary, as well as the entire discussion in Slack, I get the sense that, to a certain extent, people are talking past each other.

      @matt, I really don’t understand why you insist on ALL possible endpoints being completely ready before ANY endpoints can be merged into core.The four that are proposed cover a huge part of what many want the REST API for in the first place. I definitely think those four make for a minimum viable product, assuming they are, indeed, ready for prime time. The ability to completely replace the wp-admin goes way beyond an MVP for a REST API.

      My two cents: If there are endpoints ready for prime time, merge them. Let the others remain in the plugin.

  • Chris Christoff (chriscct7) 11:04 pm on February 4, 2016 Permalink |
    Tags: ,   

    Call for Trac Tickets and Recap of 1/29/2016 Bug Scrub 

    On Friday, January 29 at 17:00 UTC, we had our regularly scheduled bug scrub. As a reminder, for the 4.5 release, trac bug scrubs will be held weekly each Friday at 17:00 UTC. Bug scrubs are held in the #core channel of WordPress Slack.

    The Slack archive for last week’s meeting begins here: https://wordpress.slack.com/archives/core/p1454086872000605

    During the bug scrub, the following tickets were covered:

    #35216, #27048, #35010, #34887, #35243, #32602, #26571, #33717, #14853, #34996, and #14134

    Tomorrow, on Friday, February 4 2016 at 17:00 UTC the bug scrub will run approximately 1 hour. Participants need not be present for the full duration, and everyone is welcome to attend.

    We’ll start with a list of pre-submitted tickets, before going to an open floor.

    If you would like to submit a ticket for consideration for the bug scrub, please comment below with the ticket number. If you have extensive knowledge of the ticket, attending or adding accompanying text which provides a brief description of each ticket, its current status, and what needs to happen for the ticket would be appreciated. Bug scrubs are a great way to get extra eyes on tickets, feedback on patches, or suggestions on future routes.

     
  • Andrew Rockwell 7:14 pm on February 4, 2016 Permalink |
    Tags: ,   

    Week in Core, Jan. 26 – Feb. 2 2016 

    Hi everybody! Welcome back to the latest issue of Week in Core, covering changes from January 26th [36407] – February 2nd [36470], changesets [36407-36470]. Here are the highlights:

    • 64 commits
    • 16 contributors with props
    • 83 tickets created
    • 6 tickets reopened
    • 45 tickets closed

    Ticket numbers based on trac timeline for the period above.

    Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

    Code Updates

    Networks and sites

    Database

    • Allow loading when only the mysqlnd extension is loaded. [36434] #33261

    Performance

    • Add a close() method to wpdb, for when the connection needs to be manually closed. [36433] #34903

    Customizer

    • Fix searching for available nav menu items by updating reference to nonce. [36432] #35617
    • Export nonce, theme, and url app settings in preview as exported in pane. [36414] #27355, #35617
    • Improve parity between JS Setting models in preview with JS Setting models in pane. [36407] #27355, #35616

    Media

    • In wp_read_image_metadata() make sure that IPTC keywords are UTF8 encoded. [36429] #35316

    Menus

    • Avoid displaying two spinners when adding selected menu items. [36427] #35682
    • After [36379] prevent “Quick Search” form submission when pressing Enter. [36426] #35374
    • Remove a redundant and unused 0 parameter from the Delete Menu link on the nav menus admin screen. [36419] #35641

    Comments

    • Add back $req variable in comments_template(). Reverts [36322]. [36425] #35473
    • Add a back link to wp_die() comment form submission error display. [36424] #4332
    • Fix set up/tear down of post types in comment query test. [36415] #35633

    Install

    • Improve the install page language chooser button style. [36423] #34547

    UI

    • Remove all the occurrences of the old CSS clearfix. [36422] #26396

    Multisite

    • Add the global cache group sites to restore_current_blog() and wp_start_object_cache(). [36413] #32450
    • Add the global cache group networks to restore_current_blog(). Missed in [36258]. [36411] #35251

    General

    • Simplify action placement in update_metadata(). [36420] #35652
    • Revert changes to wp_validate_redirect()  [35792]. This causes a regression and causes redirects to potentially fail. [35792]  #5114, #34028
    • Pass additional params to get_archive_links filter. [36418] #35573

    Docs

    • Document the difference between site_url() and home_url()[36408] #35238

    External Libraries

    • Update Random_Compat to the latest version (1.1.6). [36421] #35665

    Props

    Thanks to @afercia, @boonebgorges, @dd32, @ericlewis, @helen, @jorbin, @kouratoras, @nexurium, @ocean90, @pento, @rachelbaker, @sebastianpisula, @shamess, @Shelob9, @westonruter, and @wonderboymusic for their contributions!

     
  • Adam Silverstein 3:03 am on February 4, 2016 Permalink |
    Tags: , ,   

    Core Dev chat notes for Feb 3 

    Announcements

    • @danielbachhuber announced a WP REST API meeting, happening tomorrow in #core-restapi on Slack: Thursday, February 4, 2016, 11:00 PM GMT. Full details are posted on the make/core blog.
    • A reminder that the feature plugin decision deadline is coming up next week, Feb 10th.
    • For the “Field Guide” posts, @jorbin proposed organizing around “focuses” and called on any feature plugins that get merged to make a post highlighting the following: anything with potential to break backwards compatibility along with significant new classes, functions, and hooks that you expect plugin, theme, and site developers to use. The goal is to have everything published before beta2.

    Feature Plugin Updates

    • Customizer Device Preview: @celloexpressions
      • Very close. Has UI/UX approval, a11y approval.
      • Waiting for fixes after dev review and security audit.
      • Consensus is that, pending the above, it is approved to merge in 4.5.
      • See #31195 and the related make post.
    • Application Passwords: @georgestephanis
      • Application passwords got split off from two factor auth, so we’re only talking about application passwords (Two-Factor is not dead, and will come back at a later date)
      • Lets you use an application password for XMLRPC and the REST API, instead of your normal password or oAuth 1.
      • Questions and discussion around whether there is a large enough use case to make this a core feature. Consensus is that at this point, it doesn’t benefit enough end users to warrant inclusion, but might after or when the REST API endpoints land in core.

    Focus Status Updates

    • Customizer: @westonruter, @celloexpressions
      • Customizer Pane Resize (#32296): Stalled.
      • Selective Refresh (#27355): Getting very close.
        • Selective refresh works well together with postMessage JS-updates, as the JS update can apply an immediate (approximate) preview while the Ajax request is being made to get the actual rendered content
        • Selective refresh `partials` have associated selectors and settings, so shift-clicking on any of the containers will focus on the corresponding control in the pane.
      • Customizer notification area (#35210): Needs help!
        • In progress, but an initial patch based on available mockups is needed here.
        • This is a dependency for the setting validation model (#34893) and creating page stubs via nav menus (#34923).
      • Transactions (#30937): Punting due to dependency on the REST API and on selective refresh.
    • Image Improvements: @joemcgill
      • Main focus on improving the default Imagick compression settings, some progress this week identifying the main hurdles there.
      • Could use additional opinions on #28474 (animated gif resizing) and whether it’s worth pursuing.
      • Could use some additional eyes on #34359 (particularly on multisite installs)
      • Weekly meeting is Friday at 20:00 UTC.
    • Multisite/WP_Site: @jeremyfelt
      • WP_Site is in with only minor issues surfacing.
      • Considering a `sites` endpoint for the REST API – primary use right now would be to refactor the My Sites menu.
      • A new repository for the site(s) endpoint has been set up on github.
      • Some renewed interest in a network settings API (or expanding the settings API to include networks)
      • Make/core post coming soon.
    • Editor: @azaozz, @iseulde
      • Going through and fixing edge cases for the inline link dialog. Please test!
      • Next will be the extending of “editing shortcuts”.

    View the full logs on Slack.

     
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