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

  • 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

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

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

     
  • Daniel Bachhuber 11:17 pm on February 3, 2016 Permalink |
    Tags: , ,   

    Thar be a WP REST API meeting tomorrow 

    Curious as to when the WP REST API endpoints will land in WordPress core? Me too!

    We’re meeting to discuss the State of the REST API just under 24 hours from now in #core-restapi on Slack: Thursday, February 4 at 23:00 UTC

    The primary points of discussion are:

    • Existing Post, Term, User and Comment endpoints.
    • New Site, Widgets, Menus, Plugins and Themes endpoints we started on Friday.
    • REST API clients — those that exist, and those that don’t yet.
    • Happy fun authentication methods.

    See you there!

     
  • Samuel Sidler 3:25 pm on February 1, 2016 Permalink |
    Tags: , 4.4.2, ,   

    4.4.2 Release Candidate 

    A Release Candidate for WordPress 4.4.2 is now available. This maintenance release is scheduled for tomorrow, Tuesday, February 2, but first it needs your testing. This release fixes 17 issues reported against 4.4 and 4.4.1.

    WordPress 4.4 has thus far been downloaded over 20 million times since it’s release on December 8. Please test this release candidate to ensure 4.4.2 fixes the reported issues and doesn’t introduce any new ones.

    Contributors

    Thank you to the following 11 contributors to 4.4.2:

    afercia, berengerzyla, boonebgorges, chandrapatel, chriscct7, dd32, firebird75, ivankristianto, jmdodd, ocean90, salvoaranzulla

    Fixes

    A total of 17 fixes are included in this RC (trac log). Notable fixes include:

    • #35344 – Strange pagination issue on front page after 4.4.1 update.This was a very visible issue for certain users with specific settings. While remnants of this issue still exist (see #35689), the bulk of it has been fixed and is ready for testing.
    • Comments – A total of 6 issues were fixed within the Comments component.
      • #35419 – Incorrect comment pagination when comment threading is turned off
      • #35402 – per_page parameter no longer works in wp_list_comments
      • #35378 – Incorrect comment ordering when comment threading is turned off
      • #35192 – Comments_clauses filter (issue)
      • #35478 – 4.4 Regression on Querying for Comments by Multiple Post Fields
      • #35356 – wp_list_comments ignores $comments parameter

    Download & Test

    We need your help to ensure there are no issues with the fixes in 4.4.2. Please download the RC and test!

     
    • Ryan Boren 5:20 pm on February 1, 2016 Permalink | Log in to Reply

      Use the beta tester plugin to reduce testing the RC to a few clicks. Rollback from the beta track to the latest production release is also a click. Details: https://make.wordpress.org/core/handbook/testing/beta/

      • Ryan Boren 5:22 pm on February 1, 2016 Permalink | Log in to Reply

        I have several sites that follow trunk nightlies using the beta tester plugin. To test the 4.4.2 RC, I tried switching those sites from bleeding edge trunk nightlies to point release nightlies using the beta tester plugin. After changing the setting in Tools > Beta Testing and doing an upgrade, I’m still on trunk. Smoothing this would be a nice improvement to beta testing flow.

  • Nick Halsey 2:24 am on January 28, 2016 Permalink |
    Tags: ,   

    Previewing Site Responsiveness in the Customizer 

    The customizer is a framework for live-previewing changes to WordPress sites. And by now, nearly every WordPress theme/site features responsive designs intended to look good on any device. Previewing site changes is just important on mobile as it is on desktop, to ensure that front-end user experience is exactly as intended.

    Bringing these ideas together, #31195 proposes a new feature in the customizer that allows users to quickly preview their site on various device sizes. Here’s a quick walkthrough:

    customize-device-preview

    The proposed feature focuses on simplicity. The device previewer is in the customizer controls footer, near the “Collapse” button. Only three options are available by default, and they’re intentionally ambiguous. Rather than looking like specific devices, the intent is to understand what a site may look like on a roughly tablet-sized, portrait-orientation device or a roughly phone-sized device, in addition to the standard desktop view. A further extension in #34051 may allow larger screen sizes to be previewed on smaller devices with forced horizontal scrolling; for now, the feature is only available on larger devices.

    For Developers

    Along with this feature would come a couple of ways to customize the behavior. Please keep in mind that these are proposed and subject to change.

    The new customize_previewable_devices filter lets you customize the devices available for preview. One use case may be to turn off this feature entirely:

    add_filter( 'customize_previewable_devices', '__return_empty_array' );
    

    Or, developers can add additional custom device preview buttons. The button element will be rendered and the appropriate JS applied to custom devices when the button is clicked; however, developers need to provide CSS to add an icon to the button and to react to the preview size changing.

    In JavaScript, themes and plugins can react to changes in the device size being previewed with:

    wp.customize.previewedDevice.bind( function( newDevice ) {
         // Do something to adapt to the new device being previewed.
    });
    

    This is particularly useful if your theme requires a JS trigger for responsive elements to apply, instead of using CSS solely.

    Summary

    Any feedback and testing is much appreciated. Device previews in the Customizer can be tested with the latest patch on #31195.

    Comments are welcome on this post, the ticket (#31195), or our continuous chat in #core-customize on Slack.

     
    • Josh Pollock 2:44 am on January 28, 2016 Permalink | Log in to Reply

      This is a great idea. I love the responsive preview system in Firefox’s developer tools and think that would be a good reference for this.

    • Brian Layman 4:00 am on January 28, 2016 Permalink | Log in to Reply

      Oh what a cool idea.. Nicely done Nick!

    • Philip Ingram 6:27 am on January 28, 2016 Permalink | Log in to Reply

      Great news and I love the progress. Here’s what I’d like to see (and currently have working on many of my sites – https://www.copy.com/s/t%3A2O1KBgz06kYOcX6A%3Bp%3A%252FLive_Customize.mp4%3Boid%3A898245 but is currently a theme specific plugin).

      1) Ability to drag resize the width of the customizer options panel (also has a numerical input up/down that increments +/- per px and updates the numerical value when a drag resize is completed) – took inspiration from the plugin – https://wordpress.org/plugins/customize-pane-resizer/ – comes in handy for asset galleries and code editors built into the pane and 300px is way too small for that stuff

      2) Common buttons for desktop, large, medium and small (same as above, has numerical input up/down for custom sizes +/- per px w/ live update

      3) To-do – Dragable handles inside the preview wrapper for custom width and height.

      4) To-do – Basic horizontal and vertical rulers with snap definitions, i.e. if you want 50px increments using keyboard shortcuts

      5) Ability to add custom breakpoints via filter array – just like what you are proposing (great idea guys!) Not every theme is built the same right.

      I like how you’re approaching this in minimalist fashion. Just be sure to keep it very open for back end customization so we can push it further without the core team worrying about the bloat. Heck I might even write those customizations into a customizer options panel itself, i.e. add custom breakpoints, toggle grid and rulers etc, very front end developer/enthusiast friendly. I’m liking that way this is shaping up. Thanks again.

    • Philip Ingram 6:50 am on January 28, 2016 Permalink | Log in to Reply

      For those that can’t preview the video linked above. https://i.imgur.com/6fmYFYz.jpg <- (lol, I never knew that imgur stores gifs with jpg handler.)

    • Jeremy Clarke 4:01 pm on January 28, 2016 Permalink | Log in to Reply

      Love this! FWIW we need the same feature for post previews to make sure the content is safe too!

      • hearvox 4:55 pm on January 28, 2016 Permalink | Log in to Reply

        +1 on eventually incorporating a mobile-preview from the Edit Post screen — likely via the Customizer functionalities. Dual purpose: 1. Writers can trap mobile problems in the post before they publish. 2. A mobi-prevu option will get writers thinking about mobile as they write on their desktops.

      • Ryan Boren 3:17 pm on February 4, 2016 Permalink | Log in to Reply

        Calypso has this, and I rather enjoy it. I too would love to have it in core.

    • Mark Root-Wiley 4:13 pm on January 28, 2016 Permalink | Log in to Reply

      This is a great feature and I’m excited to see how it evolves from here. +1 for displaying the dimensions somewhere and I do think draggable resizing could be very useful to combat my main concern…

      It’s hard to say for sure, but I’d be unsurprised if user testing showed people read way far into the breakpoints (such as attributing the phone size to whatever phone they own). Some type of notice or info message saying I think would be good. “Devices come in many shapes and sizes beyond those previewed here.”

      I’ve seen many times people trying to “optimize” their content with manual line breaks, etc. so anything we can do to help people avoid that type of pointless work is good.

  • Adam Silverstein 10:54 pm on January 27, 2016 Permalink |
    Tags: , ,   

    Core Dev chat notes for Jan 27 

    Announcements

    • Extending the Feature Plugin decision and merge deadline by one week, taking them to Feb 10 and 17, respectively. This does not affect the rest of the release schedule, and betas, RC, and release are all the same dates. This gives feature plugins a little more time to have necessary discussions.
    • @ebinnion has graciously continued with the week in core post, and @rockwell15 volunteered to lend a hand.  If you like these posts, please help!  Many hand make light work.
    • @dd32, @jorbin and a few others are working on finishing up 4.4.2. Ticket owners should review the list of tickets tagged for the release.

    Focus Status Updates

    • Customizer: @westonruter, @celloexpressions
      • Posted a recent status update here on the make/core blog.
      • Customize Device Preview is up and ready for testing #31195, with a make/core post coming shortly.
      • Assistance requested with the Customizer Pane Resize plugin #32296.
      • Some movement on adding a notification area to Customizer #35210, with the need for an initial workup – help needed.
    • HTTPS Improvements: @johnbillion
      • Focusing on avoiding mixed content on https sites – a working http site is much preferable to an https site full of mixed content.
      • Working on a feature plugin which implements various granular controls over forcing HTTPS on a site: forcing enqueued assets to https, rewriting URLs in content on the fly to force their scheme to https, forcing redirects to the https version of the site, etc. Individual options with the ability to enforce the lot.
      • Adding a GitHub repo where this will be worked on and also posting a summary to make/core soon.
    • Image Improvements: @joemcgill
      • Good conversation last week about displaying responsive images in the editor.
      • Team could use help with profiling to Improve default Imagick compression settings #33642.
      • The old #feature-respimg channel has been renamed #core-images to be a place to talk about images in any/all capacities.
      • Weekly meeting is Friday at 20:00 UTC.
    • Editor: @azaozz, @iseulde
      • The inline link dialog is in. Please test! #33301
      • Looking into wpviews soon (Using the TinyMCE API).
      • Also looking at improving the shortcuts soon.
      • Could use help investigating using the image editing tools from TinyMCE for the media library.

    Open Floor

    • @veraxus brought up #16031 and the inability of handle new bulk actions in a non-hacky way (you can add the actions in the list, but not handle the action). Is it worth the effort to rework the patch? Will the core team support it?

    View the full logs on Slack.

     
  • Eric Binnion 6:50 pm on January 27, 2016 Permalink |
    Tags: ,   

    Week in Core, Jan. 19-26 2016 

    Welcome back to the latest issue of Week in Core, covering changes from January 19th – January 26th, 2016, changesets [36351-36406]. Here are the highlights:

    • 55 commits
    • 44 contributors with props
    • 99 tickets created
    • 10 tickets reopened
    • 86 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

    • Improve the focus style on the Credits screen. Leads and contributing developers will now look nicer when focused. Also, combines adjacent image and text links for the same resource thus simplifying markup and reducing noise for screen reader users. [36406] #34953
    • Accessibility: Improve the color contrast ratio replacing the residual occurrences of the #777 gray. Uses the existing #72777c on white backgrounds and the new #555d66 “dark medium gray” on darker backgrounds. [36396] #35605
    • Fix the color contrast ratio in the login screen. [36395] #31548
    • Remove title attributes from the Menus screen. [36379] #35374

    Cache API

    • Pass $clean_taxonomy param to ‘clean_term_cache’ action. [36399] #35611

    Comments

    • Fire an action after a comment is removed from object cache. When a comment is removed from the object cache, the clean_comment_cache action is now fired. This provides plugin and theme developers a chance to perform secondary cache invalidation as needed. [36405] #35610
    • In comments list table, $post_id should default to false rather than 0. [36387] #35090
    • Allow comment query results to be limited to comments with comment_post_ID = 0. [36381] #35090
    • Ignore hierarchy in pagination calculation when comment threading is disabled. Merges [36275] to the 4.4 branch. [36362] #8071, #35419
    • Respect all post-related filters in WP_Comment_Query. Merges [36326] to the 4.4 branch. Fixes #35478. [36361] #35478
    • Use the post-filter WHERE clause when querying for comment descendants. Merges [36277] to the 4.4 branch. Fixes #35192. [36357] #35192
    • Always respect $comments array passed to wp_list_comments(). Merges [36276] to the 4.4 branch. [36356] #35175, #35356
    • In comments_template(), don’t run hierarchical queries if comment threading is disabled. Merges [36226] to the 4.4 branch. [36353] #35378

    Customizer

    • Use “(Untitled)” as site title if blogname is empty. Fixes #35579. [36388] #35579
    • Add shift-click on nav menu items in preview to focus on corresponding nav menu item controls in pane. [36383] #32681
    • Hide help toggle button in panel when no description is supplied. This aligns with the .customize-panel-description element which is also excluded if there is no description. [36374] #35540
    • Fix click.preview event handler for jump links and shift+clicks in preview. Fixes #26005. [36371] #32681, #26005
    • Prevent erroneously directing user to login screen when closing. Fixes #35355. [36363] #32637, #35355
    • Respect custom pagination params when using wp_list_comments() in a query loop. Merges [36324] to the 4.4 branch. [36360] #35402

    Documentation

    • Correct return value for is_allowed_http_origin(). [36398] #35607
    • Clarify that mu-plugins can’t be “active” in docs. [36397]
    • Fix parameter documentation ordering in the hook docs for the register_taxonomy_args filter. [36391] #32246

    Editor

    • TinyMCE: add inline link dialog. First run. Links the advanced button to the “old” dialog for now. [36384] #33301
    • TinyMCE: remove the srcset and sizes attributes (if any) after replacing or editing an image. [36376] #35434

    Emoji

    • Work around a mod_security rule which prevents pages with 4 or more instances of String.fromCharCode( from being served. [36359] #35412

    I18n

    • Add the text domain to translate_nooped_plural() calls as well. [36390] #34126
    • Add a test for the add-textdomain.php script. [36389]

    Media

    • In _wp_handle_upload(), move ending brace to a new line. [36373] #35565
    • When reusing the initial values from the global MediaElement config object, the config object should first be cloned. Objects in JS are references that will retain any changes. Fixes #34152. [36364] #34152

    Multisite

    Plugins

    • Pass data consistently on plugin, network plugin, and network theme screens. [36394] #35335

    Query

    • Respect ‘suppress_filters’ when filtering search-related SQL. [36404] #35594
    • Introduce $comment_status and $ping_status params for WP_Query. [36403] #35601
    • Avoid invalid SQL when building ORDER BY clause using long search strings. Merges [36251] to the 4.4 branch. Fixes #35361. [36354] #35361

    Quick/Bulk Edit

    • Remove a no more used jQuery loop for unsupported post formats. See #24096. [36375] #23426, #24096, #35564
    • On the Taxonomies screens, prevent a page reload when pressing Enter on a focused field. Merges [36260 to the 4.4 branch. [36355] #35401

    Posts, Post Types

    • Allow is_post_type_viewable() to accept a post type name. Previously, it accepted only a post type object. [36402] #35609
    • Add tests for is_post_type_viewable(). [36401] #35609

    Taxonomy

    • Populate term cache with proper clone of term objects. Merges [36323] to the 4.4 branch. [36358] #35462

    Themes

    • Themes: Enhance filtering options for allowed themes on a network. [36366] #28436

    TinyMCE

    • Update to 4.3.3. Update the QUnit tests and revert back to testing the non-minified files in /src. [36352] #35539

    Upgrade/Install

    • Switch the locking mechanism to using static methods so that it can be accessed from other upgrade-classes. [36370] #34878

    Widgets

    • Show the “Clear Inactive Widgets” button only after the sidebar with inactive widgets. Merges [36326] to the 4.4 branch. [36369] #35447

    Props

    Thanks to @5um17, @afercia, @azaozz, @berengerzyla, @birgire, @boonebgorges, @chandrapatel, @chriscct7, @danielbachhuber, @dd32, @dmsnell, @dotancohen, @drebbitsweb, @DrewAPicture, @ericlewis, @Fab1en, @firebird75, @Frozzare, @georgestephanis, @iseulde, @ivankristianto, @jeremyfelt, @jmdodd, @johnjamesjacoby, @johnnypea, @kraftbj, @lamosty, @luciole135, @MattGeri, @michalzuber, @mrahmadawais, @obenland, @ocean90, @pauldewouters, @rob, @salvoaranzulla, @scarinessreported, @SergeyBiryukov, @spacedmonkey, @tahteche, @walbo, @westi, @westonruter, and @wonderboymusic for their contributions!

     
  • Konstantin Obenland 6:43 pm on January 27, 2016 Permalink |
    Tags: , shiny-updates   

    Shiny Updates v2 

    Shiny Updates v2

    What is Shiny Updates?

    With the stated goal of “Hiding the The Bleak Screen of Sadness”, the shiny updates team is working on bringing a smoother experience for managing plugins and themes to WordPress.

    Shiny Updates v2 is an effort to continue the shiny updates effort from WordPress 4.2. The original shiny update feature only includes shiny plugin updates. The new version aims to extend this to all aspects of updates, installs, and deletes for plugins, themes in WordPress.

    There are numerous screens in the Admin that allow you to install, update, and delete themes, plugins and WordPress itself. Shiny updates is exploring ways to improve their design and especially to offer a better user experience by improving perceived performance and limiting confusing notifications.

    What does it do?

    The shiny updates plugin currently enables the following features:

    • Deleting single plugins, bulk updating and bulk deleting plugins from the plugin page.
    • Shiny plugin installs from the plugin install screen: multiple actions can be queued up.
    • Shiny theme installs, updates, and deletes, multiple queue-able, including multisite.

    What is still being worked on?

    Currently the team is brainstorming a complete rethink of the core updates page (update-core.php), working to improve clarity and enable easier Update All functionality. Work on that is happening here: https://github.com/obenland/shiny-updates/issues/5

    How can I help?

    Anyone can help by testing the plugin! Download and install the plugin, then test out all the shiny features: try installing, updating, and deleting plug7ins and themes, including bulk actions, on both single and multisite. Does everything work as expected? Are there any jarring flows? Missing notifications?

    Please report any issues on the Github repository, or drop in the #feature-shinyupdates channel in Slack to ask questions or give feedback. It’s also where we have our weekly chats, on Tuesdays 19:00 UTC. Thank you!

    P.S. Props @adamsilverstein for ghost-writing this post.

     
    • Philip Ingram 7:41 pm on January 27, 2016 Permalink | Log in to Reply

      Curious if any discussion has been opened regarding plugin updates via upload? Currently if a plugin exists, the upload fails.

      If I want to update an active plugin, it must provide updating via the core update method, ftp/file manager via overwriting files or I must deactivate, delete, upload and reactivate the plugin (which could uninstall functionality not to mention change functionality while disabled)

      I believe it would definitely improve my workflow if I could simply upload a newer version and be asked if I’d like to overwrite the current version.

      Another concept would be to archive the previous version with a max retainer threshold of x version back. This also helps address issues where a plugin update breaks existing functionality, a simple shiny update roll back/forward could be applied.

    • Ryan Boren 7:59 pm on January 27, 2016 Permalink | Log in to Reply

      Note that if you have the beta tester plugin, feature plugins can be installed from Plugins > Add New > Beta Testing. Details here: https://make.wordpress.org/core/handbook/testing/beta/

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