WordPress.org

Make WordPress Core

Welcome to the official blog of the core development team for the WordPress open source project.

Here, we make WordPress core. Follow our progress with general updates, status reports, and the occasional code debate.

We’d love for you to help out.

Looking to file a bug?

It’s easy to create a ticket on our bug tracker.

Want to contribute?

Get started quickly. We have some tickets marked as good first bugs for new contributors. There’s more on our reports page, like patches needing testing.

We also have a detailed handbook for contributors, complete with tutorials.

Weekly meetings

We use Slack for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day.

We have a project meeting every Wednesday at 20:00 UTC in the #core channel on Slack. (Find out more about Slack.)

You can find meeting agendas on this blog. You’re welcome to join us or listen in.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Rockwell 4:55 am on January 5, 2017 Permalink |
    Tags: ,   

    Week in Core, December 14th 2016 – January 3rd, 2017 

    Welcome back the latest issue issues (sorry) of Week in Core, covering changes [39599-39665]. Here are the highlights:

    • 67 commits
    • 56 contributors
    • 203 tickets created
    • 24 tickets reopened
    • 145 tickets closed

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

    Code Changes

    Bootstrap/Load

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

    Build/Test Tools

    • Tests: Restore the database connection earlier when switching test groups. [39626-39627] #39327

    Bundled Theme

    • Twenty Seventeen: Fix incorrect $content_width value in theme. [39635], [39650] #39272
    • Twenty Seventeen: Hardens the logic for calling featured image in header.php [39624] #39302
    • Twenty Seventeen: Ensure functions in customize-controls.js don’t count on Customizer sections always being present [39623] #39335
    • Twenty Seventeen: Improves code readability and code standards in files [39618] #39152

    Comments

    • Ignore the ‘comment_order’ setting when determining comment pagination. [39663-39664] #31101, #39280
    • Fix placement of the wp_update_comment_data filter to safeguard filtered data from triggering a database error. [39640-39641] #39380

    Customize

    • Fix visible edit shortcuts for wp_nav_menu() instances using the menu arg (such as in the Custom Menu widget) instead of the theme_location arg. [39622], [39653] #27403, #39101
    • Bump wp_custom_css_cb from running at wp_head priority 11 to 101 to ensure Custom CSS overrides other CSS. [39616], [39651] #35395, #38672, #39270
    • Prevent edit shortcut from losing event handler after selective refresh. [39606] #27403, #39100

    Editor

    External Libraries

    Feeds

    • Replace the RSS2 lastBuildDate date field with the r date specifier. [39614] #39141
    • Do not translate the lastBuildDate field in RSS feeds. [39613] #39141

    Filesystem API

    • Filesystem: Add return statement to WP_Filesystem_ftpsockets->rmdir [39644] #39405

    General

    • Update copyright year to 2017 in license.txt. [39659], [39661] #39433
    • Docs: Misc corrections and additions to inline documentation. [39639] #39130
    • Use interpolation instead of concatenation for all dynamic hook names. [39600] #39148

    Mail

    • Ensure that any phpmailerException exceptions generated by setFrom() are caught to avoid PHP Fatal errors. [39655] #25239, #39360

    Media

    • Move a variable definition outside of conditionals to ensure it’s always available.
      This [39654] #39250
    • Allow PDF fallbacks filter to process custom sizes. [39617] #39231, #38594
    • This [39612] #39250
    • PDF Images: Avoid a PHP Warning when attempting to process a file without an extension. [39607] #39195

    Posts, Post Types

    • Taxonomy: Eliminate redundant and inaccurate dupe check when creating categories from post.php. [39637] #16567
    • Ensure is_page_template() can only return true when viewing a singular post query. [39599], [39608] #39211

    Query

    • Don’t double-escape terms payload in WP_Tax_Query::transform_query(). [39662] #39315
    • Improve documentation for orderby=relevance in WP_Query. [39636] #39336

    REST API

    • Add missing assertions to the view and embed context response data for the Users Controller. [39660] #39399
    • Add the supports property to the Post Type response object. [39647] #39033
    • Remove errant annotation from test_get_items_pagination_headers() method. [39643] #39398
    • Allow schema sanitization_callback to be set to null to bypass fallback sanitization functions. [39642] #38593, #39042
    • Docs: Add and correct @since docs for a variety of functions and methods. [39638] #39343, #39357, #39344, #39130
    • Allow sending an empty or no-op comment update. [39628] #38700
    • Improve the rest_*_collection_params filter docs and fix the terms filter. [39621] #39300
    • Fix PHP warnings when get_theme_support( 'post-formats' ) is not an array. [39620] #39293
    • Do not include the password argument when getting media items [39610] #38977
    • Do not error on empty JSON body [39609] #39150
    • WP-API: JavaScript client – fix setup of models used by wp.api.collections objects. [39603-39604] #39070
    • Add support for filename search in media endpoint. [39598] #39092

    Shortcodes

    • Clarify the docs for pre_do_shortcode_tag and do_shortcode_tag. [39665] #39294

    Taxonomy

    • Redirect to current taxonomy when adding a term without AJAX. [39649], [39652] #39328
    • REST API: Merge similiar error message strings in the Terms Controller. [39648] #39176
    • Ensure that mods to query vars in pre_term_query callbacks have an effect. [39625] #39354
    • Restore the ability to use string-based $args in wp_get_object_terms(). [39611] #39215

    Upgrade/Install

    • Updates: Show the Authentication key settings after selecting the SSH transport in both the modal, and also on the plugin/theme updates screen. [39657-39658] #39057
    • Updates: Remove a stray " from a tag. [39656] #39057

    Thanks to @adamsilverstein, @afercia, @bcworkz, @boonebgorges, @chandrapatel, @ChopinBach, @chris_de, @davidakennedy, @dd32, @dhanendran, @dl, @dlh, @dots, @dreamon11, @dshanske, @garyc40, @gitlost, @iseulde, @jblz, @jesseenterprises, @jfarthing84, @jnylen0, @joemcgill, @johnbillion, @jorbin, @JPry, @keesiemeije, @keesiemeijer, @kkoppenhaver, @kovshenin, @laurelfulford, @MattyRob, @MikeHansenMe, @natereist, @Nikschavan, @obenland, @ocean90, @pento, @peterwilsoncc, @rachelbaker, @ramiy, @sanket.parmar, @sebastian.pisula, @SergeyBiryukov, @sfpt, @shazahm1hotmailcom, @sirbrillig, @sstoqnov, @stevenkword, @szaqal21, @thepelkus, @timmydcrawford, @tymvie, @tyxla, @voldemortensen, and @westonruter for their contributions!

     

  • Jeffrey Paul 4:32 am on January 5, 2017 Permalink |
    Tags: , ,   

    4.7.1 Bug Scrub 

    Thursday, January 5th 12:30pm CST has been scheduled for a bug scrub.

    The bug scrub focus will be on tickets milestoned for 4.7.1 and the conversation will take place in #core. This will be the final bug scrub for 4.7.1 and any tickets remaining in the milestone after the bug scrub will be punted to 4.7.2 or a future release. Reminder that 4.7.1 is scheduled for release on Tuesday, January 10, 2017.

     

  • Matt Mullenweg 10:32 pm on January 4, 2017 Permalink |
    Tags: customizer, ,   

    Focus Tech and Design Leads 

    There are three main focuses this year: the REST API, the editor, and the customizer.

    For the REST API we’re going to work on getting first party wp-admin usage of the new endpoints, and hopefully replace all of the core places where we still use admin-ajax.

    The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.

    The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

    Each focus will have a tech lead, and a design lead, and I’ll be working closely with each to make sure we’re aligned and moving diligently in the right direction even though we don’t have the normal release hooks. These starting leads will be:

    REST API: Ryan McCue and KAdam White.

    Editor: Matias Ventura and Joen Asmussen.

    Customizer: Weston Ruter and Mel Choyce.

    Given there is no set timeline for releases that would normally set a term, these leads are free to bow out at any time they feel they can’t contribute fully and we’ll find a replacement.

    You might be wondering what each lead is responsible for. The REST team gave some thought to this for their focus, and this is the list they came up with:

    Tech Lead responsibilities:

    • identify and ensure implementation of first-class REST API usage within WP-Admin,
    • replacing/refactoring admin-ajax use.
    • overall REST API architecture
    • infrastructure and endpoint performance
    • security at an infrastructure and endpoint (data-exposure) level
    • improving authentication options and documentation
    • working with the Design Lead to build new, or expand on existing, endpoints
    • working with the Design Lead to address usability feedback for the infrastructure and endpoints

    Design Lead responsibilities:

    • usability of endpoints for internal or external clients
    • usability of the infrastructure from the perspective of a API client
    • working with the Editor and Customizer focus teams to collect requirements and gather feedback
    • identifying ways to improve the overall experience for folks building clients or consuming endpoints (like documentation)
     

    • Jon Brown 10:38 pm on January 4, 2017 Permalink | Log in to Reply

      This all sounds awesome and I’m excited to see the fruits of this new paradigm.

      I do have one technical question I haven’t heard addressed… how are these being handled code/repo wise?

      Otto can come after me with a whip… but wouldn’t each of these major efforts be much easier managed as separate git branches than with SVN’s patching/branching system? I just can’t wrap my head around ever being able to merge the results of each of those efforts independently any other way.

      I’m not trying to start yet another svn/git war… just asking, what’s the plan for the fruits of this effort being merged into trunk someday?

      • Matt Mullenweg 10:41 pm on January 4, 2017 Permalink | Log in to Reply

        It is super tempting to also want to change all our tools and workflows at the same time, but we shouldn’t try to innovate in too many areas at once. So no SVN / Git war today. 🙂

        • Jon Brown 5:42 am on January 5, 2017 Permalink | Log in to Reply

          I guess my question wasn’t clear. What’s the plan?

          I totally understand the logic of not switching tools… The existing SVN patch paradigm seems unwieldly for anything this size. Is the plan to utilize SVN branches and merging? figured it out as we go?

      • Ryan McCue 1:33 am on January 5, 2017 Permalink | Log in to Reply

        As well as what @matt said, a lot of these pieces will (hopefully) tie in with each other quite heavily, and I expect we’ll all be working together a fair bit, so separate branches probably wouldn’t help. 🙂

    • Tammie Lister 10:39 pm on January 4, 2017 Permalink | Log in to Reply

      Congratulations everyone leading! Really looking forward to seeing the focuses evolve.

    • Luke Cavanagh 10:40 pm on January 4, 2017 Permalink | Log in to Reply

      Seems an interesting change of focus for WP core. Where will other features as plugins stand, if they do not fit within the three main focus areas?

    • Scott Kingsley Clark 10:47 pm on January 4, 2017 Permalink | Log in to Reply

      I’d like to get the Fields API into the Editor focus if the meta boxes and fields on the screen fits into your definition well enough. There may be a lot of crossover between what the Fields API could take on and the remarks you’ve made above about the Editor focus which would make a great pairing.

      • Matt Mullenweg 10:51 pm on January 4, 2017 Permalink | Log in to Reply

        Could look at it later in the year, I think the first half will be focused on more foundational things.

        • Scott Kingsley Clark 10:59 pm on January 4, 2017 Permalink | Log in to Reply

          OK, I’m just concerned as we add new methods for adding structures that Fields API has even more work to be done in order to unify them. But glad you’re not opposed to it. I can rest soundly now 🙂

      • Nick Halsey 12:13 am on January 5, 2017 Permalink | Log in to Reply

        On the other hand as the editor becomes integrated with the customize API via customize posts/broader live preview, the customize API could potentially be used directly for fields that manage any type of content throughout WordPress (this is already possible, but perhaps not obvious in terms of resulting usability). It’s probably best to wait and see where that heads before going too much further with a separate fields API.

      • Marcus 12:13 pm on January 5, 2017 Permalink | Log in to Reply

        I think Fields API is one of those things that is getting overlooked, yet would benefit the project so greatly by providing standards and consistency for developers working with WP.

        From the consistency/standardization point of view, I envisage similarities with how the introduction of Custom Post Types created a standard for content other than regular posts/pages.

        Whilst I don’t know much about the Customize API, I think Fields API make an awesome foundation for fields used in any other API or UI.

        • Scott Kingsley Clark 1:30 pm on January 5, 2017 Permalink | Log in to Reply

          I imagine that the Customizer API would ultimately fetch configurations from the Fields API to make use of them in its own context, but that Fields API would stretch across WordPress beyond things that need previewing.

    • Rachel Baker 11:01 pm on January 4, 2017 Permalink | Log in to Reply

      Congratulations to all the Focus Leads!
      Defining the responsibilities of the two roles was a valuable exercise for the REST API team. Thanks for sharing @matt.

    • Luke Cavanagh 11:10 pm on January 4, 2017 Permalink | Log in to Reply

      Final question I know performance was mentioned before, where will that focus fit? Thanks for the info.

      • Matt Mullenweg 2:18 am on January 5, 2017 Permalink | Log in to Reply

        What goes in a minor release will broaden a bit, which I know is something we have to approach carefully, but performance is very important and improvements will be something I will consider for being in a minor release.

    • Chuck Reynolds 11:37 pm on January 4, 2017 Permalink | Log in to Reply

      yay progress; very excite… let’s go!

    • Nick Halsey 1:29 am on January 5, 2017 Permalink | Log in to Reply

      Since I’m going to be generally much less available (and completely unavailable during US business hours) starting next week, I’m going to leave my thoughts on priorities and next steps for the customizer here.

      I’ve done some preliminary research on the process of making things in different industries. Preview, and live preview, is always a goal because it provides implementors with the best chance to understand what they’re making as they create it. In most cases a truly live preview is not possible due to physical constraints; for digital products and WordPress, though, live preview is possible and represents the best opportunity for improving user experience. See http://celloexpressions.com/blog/trust-wordpress-with-live-preview/ for details.

      The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

      Because unified live preview is critical to improved user experience and trust, the best approach is probably to implement the new editor experience within the customize API, thus creating it with contextual live preview as an integral part of the experience from the start. Improving the editor within an “admin” interface that lacks live preview doesn’t address the fundamental problems with the current content editing experience and creates something that still has to be entirely rebuilt and reimagined within a live preview context eventually.

      If the editor is built on the customize API first, rather than rethinking the editor and then bringing it into the live preview API, the customize and editor contributors would be able to join forces to focus on improving the content editing experience much more effectively. The customize component has been seeing a lot of contributors helping out (over 60 in 4.7) and their knowledge of the customize API would be a big help in tackling the technical and design challenges of rethinking the editor within the unified live preview context; the opposite is unlikely to happen.

      Either way, these are the next steps that I would prioritize in working toward an improved and unified live preview experience, which could encompass much of the editor focus and would then set the stage for improving the broader approaches to “customization” on top of what’s existing:

      • Implement a term status API so that terms can be previewed
      • Complete the new theme installation experience (proposed plan)
      • Develop a core customize inline editing/partials API within the customize preview
      • Iterate on Customize Posts and the front-end editor plugin to provide inline editing within the customize preview API (this would be the basis for new editor work)
      • Load the customizer directly from the front end, making it feel like a front-end edit mode rather than a mix between the admin and front end
      • Rework option navigation UX in the customize controls pane, UX of inline editing vs. editing in a separate pane, visible edit shortcut UX, and the way posts of any type are accessed to edit (perhaps integrating with menus?) – I know @folletto has thoughts here that would be valuable
      • Iterate on customize snapshots and changesets to provide UI for revisions, drafted changes, and scheduled changes unified across a site’s posts and options
      • Implement term editing within the customizer (unified live preview framework)
      • Merge Customize Posts, with refined UX (this would be a likely place for editor-contents work to happen as well)

      My general feeling is that we need to bring live preview to content editing before the editor and customizer goals above (in the post) can be effectively tackled, so that there’s a complete framework to build those; however, work on these goals can progress simultaneously if expectations are established appropriately at the beginning.

      I’m not sure how much time I’ll be able to contribute moving forward, but my priorities (as a user first) are to advance the proposed roadmap I listed above.

      • Andrew Ozz 4:07 am on January 5, 2017 Permalink | Log in to Reply

        Nice thoughts and ideas. I’ve also been thinking about this and agree with many of the above points.

        My general feeling is that we need to bring live preview to content editing

        Yes. Even not “live preview to content editing” but rather “inline content editing where no preview is necessary”. As far as preview is concerned, the best experience is to edit “the real thing”, i.e. some form of front-end editing directly into the theme.

        Because unified live preview is critical to improved user experience and trust, the best approach is probably to implement the new editor experience within the customize API, thus creating it with contextual live preview as an…

        I’m not sure what “unified” live preview and “contextual” live preview mean. The best “preview” is when something is edited inline. Unfortunately this is not available in the current customizer. The second best is when the editing UI is inline, right at the place that is affected by the edit. This also is not available in the current customizer.

        If the editor is built on the customize API first, rather than rethinking the editor and then bringing it into the live preview API…

        Don’t think this is good. As far as I see the current customizer UI will have to be redesigned together with the way it works. Don’t see a reason why the UI should be similar to a “frameset” site from the late 90’s. We can do a lot better than that 🙂

        Rework option navigation UX in the customize controls pane, UX of inline editing vs. editing in a separate pane, visible edit shortcut UX, and the way posts of any type are accessed to edit (perhaps integrating with menus?)

        Exactly (I read that as UI not UX). Further, the customization will happen from the theme/front-end, the “control” sidebar will go or be replaced with a proper navigation menu, everything will be 100% JavaScript and REST API driven, most controls will be inline or in some form of dialogs (with ample space/not overcrowded) that will have help or hints build right into them, etc.

        • Nick Halsey 7:17 am on January 5, 2017 Permalink | Log in to Reply

          Thanks for the reply. I should clarify some of the terminology I used:

          • Live preview and inline editing (can/should) mean the same thing. The basic idea is that you see the end product as you create it. Inline editing is a more specific form of live preview.
          • Expanding on that, most interactions should probably happen directly “on the site” (or in the preview). However, there are cases where that doesn’t make sense (for example, a theme’s color options or changing a post format) – that’s where some sort of sidebar, modal, popup, or other approach would be necessary, and this is where we need a lot of research and design work to find the best solution. A hybrid solution like this also makes theme compatibility and progressive enhancement with theme-support much more realistic.
          • “Unified” live preview is essentially being able to edit any part of a site within the same editing mode/workflow (without having to publish any changes).
          • “Contextual” live preview would be something like front-end editing, versus an editor that provides live previews of styling for the content area and media within it but is missing the context of the rest of the site, and may not be able to accurately reflect the way all content is displayed as a result.
          • In terms of API, the customize API is currently the core framework/API for live previewing anything. I might use customize API and live preview API somewhat interchangeably because I see this as the best path forward as a basis for building everything; @westonruter could probably discuss the advantages to that direction in more depth.
          • The customize API is 90% of the way to being able to fully manage live previewing any change to a site with controls to make changes happening either inline or in a separate place (the current customize “pane”). Specifically, once “Develop a core customize inline editing/partials API within the customize preview” is implemented on top of the base partials API currently in core, the customize API would support both approaches to making changes pretty robustly, as opposed to starting from scratch. That would also do a lot for the goal of unified live preview (and theme/back-compat) if content editing comes into the same framework that’s already used for many non-content options.

          So I think we’re largely in agreement about end goals, and should spend some time refining the direction on how to get there, both in terms of tech and design 🙂 The current “customizer” should certainly evolve in terms of usability but the internals are beginning to converge with long-standing feature plugins and the editor goals into something that could really take WordPress to the next level with unified live preview and inline editing as a central focus.

    • Ryan McCue 1:35 am on January 5, 2017 Permalink | Log in to Reply

      Looking forward to working with you Matt, as well as all the other leads. Exciting times. 🙂

    • Julien 6:53 am on January 5, 2017 Permalink | Log in to Reply

      Great news, we’re definitely looking at Editor “blocks” features.

    • Davide 'Folletto' Casali 10:16 am on January 5, 2017 Permalink | Log in to Reply

      I couldn’t agree more on the combination of a design and a tech lead, as well as having explicit reference people for each project.

      I’m happy to see this direction, and specifically the people chosen there are probably the best choices I can think of. It’s going to be great. 🙂

    • Joen Asmussen 10:30 am on January 5, 2017 Permalink | Log in to Reply

      🎉

      Interesting times ahead. Can’t wait to see what cool stuff we’ll build together!

    • Mel Choyce 4:21 pm on January 5, 2017 Permalink | Log in to Reply

      Looking forward to working with all the other leads this year! 🙌

  • Jeffrey Paul 3:31 pm on January 4, 2017 Permalink |
    Tags: , , ,   

    Dev Chat Agenda for January 4 (4.7.1 week 4) 

    This is the agenda for the weekly dev meeting on January 4, 2017 at 15:00 CST:

    • Schedule reminder: We need to agree on a timing for a 4.7.1 RC. RC means the list of tickets should be at zero, as a release candidate is supposed to represent software you believe you can release. It is currently at 21. (50 have been closed so far.)
    • Ticket reminder: For any tickets you’ve moved into the milestone, please take action on these in the next week.
    • Getting ready for RC with a 4.7 open ticket scrub

    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!

     

    • Marius L. J. (Clorith) 5:31 pm on January 4, 2017 Permalink | Log in to Reply

      I’d like to see the dev chat address the new release schedule, and how this affects minor updates moving forward, there is way too much confusion without any official word as of yet, and it’s been a month since the reveal (even though it’s been a holiday, it’d be nice if this was released along with the reveal)

      The major concern (I believe) is that we are likely to be breaking a long standing expectation of what is included with a minor release, and why they are considered “safe” compared to a major update at this point (judging by ticket(s) with bugfixes not related to regressions in the latest 4.7 being pushed into the 4.7 branch as well as trunk)

      Somewhat lengthy discussion started at https://wordpress.slack.com/archives/core/p1483136776003730 for reference

      • Jeffrey Paul 8:57 pm on January 4, 2017 Permalink | Log in to Reply

        While clarity on the new release schedule would be nice, the focus today will be on 4.7.1 as I have no insight into “how things will be different in 2017”. I will continue to push to get clarity on the new release schedule and help to get that published as soon as it’s available.

    • Luke Cavanagh 5:48 pm on January 4, 2017 Permalink | Log in to Reply

      Hoping for some official clarity in relation to the new release schedule.

      • Jeffrey Paul 8:58 pm on January 4, 2017 Permalink | Log in to Reply

        Today’s focus will be on the 4.7.1 release and I’m unaware of additional details on the new release schedule. I do know that’s important to many people, so I’ll continue to push for more clarity on this topic. Thanks for the input!

  • Jeffrey Paul 5:30 am on January 4, 2017 Permalink |
    Tags: , , ,   

    Dev Chat Summary: December 21st (4.7.1 week 2) 

    This post summarizes the dev chat meeting from December 21st (Slack archive).

    4.7 Retrospective

    • Reviewing comments on 4.7 Retrospective post on Make/Core
    • We will go through comments and discuss if there are changes to our process that we should recommend
    • Goal is not to second-guess decisions that were made, the goal is to figure out if the process can be improved in future releases
    • Things to start doing:
      • “We failed at getting the field guide and email to plugin dev out early enough. We have aimed to have that out around beta 2 and usually end up getting it out around RC the last few releases. This time it came out the day before (field guide) and day after the release (email).”
        • Coming up with some documentation and ensuring that it’s not just owned by one person is a good way to improve it
        • We should also ensure it is included in the release checklist
      • “The posts explaining new features and changes are helpful, but I think that we need more of them. I follow the trac feed, and sometimes I know that as a plugin developer a particular ticket is important for me to take note of, but it can be difficult to unravel exactly what the final decision was just based on the changesets. An example of something that is going on right now is the a11y team’s work on removing excessive content from headings on admin screens. Often API changes get documented and UI changes don’t, but I’m a perfectionist and I like to stay up to date on the latest design/a11y evolutions as well. I can usually figure out what changes I might want to make in my plugins based on the changes in core, but I’m sure that often most plugin developers don’t even know that there was a change, if they don’t read every ticket.”
        • Request here is to have more Dev Notes and explanations about what is changing
        • It would help to spread the load of writing Dev Notes a bit, sometimes they are time consuming, especially if you’re not much for writing this sort of contextual summary
        • Some components generate a component summary dev note which is a good practice
        • Should we also maybe reach out to the docs team to see if they want/can help?
        • Anyone have ideas for how we get people involved with drafting the note even if they aren’t leading developers on a feature/component?
        • We do list out every change in the “this week in core posts” (shout out to the team that works on those!) already, so there isn’t anything that goes unannounced
        • The solution suggested is more posts, but the problem appears to be that people aren’t seeing changes that they think might affect them
        • Getting to Trac and subscribing to whatever feed is a little hidden. Even Slack notifications is hidden. A more public place would be good.
        • The solution could be to push people to the Week in Core posts, they already list every change categorized by components
        • Someone willing to lead a discussion (likely on make/core) on how to improve this?
        • Action Item: wait and see how lack of timed release cycles plays out
      • “We need to collectively review the “feature plugin merge guidelines” listed here. While development in plugins has become less prominent, most of the bigger projects merging into core in 4.7 (I would exclude the REST API since that’s less user-facing) skipped many of the steps here. A lot of the points don’t apply to most projects – to the point that the checklist is often forgotten entirely. But there remains a need for better quality control and an updated checklist or recommended merge considerations for larger projects should be created accordingly. These written guidelines can better inform merge decisions and assess readiness.”
        • Can we reasonably make full test coverage (covering basic use cases at least) a requirement there?
        • This may be null as feature plugins may not play a significant, or any, role in the future
        • More “wait and see how new process/focus shakes out”
        • Action Item: No more feature plugins
      • “On a related note, clearer procedures about backing out merged features are needed. Particularly if a feature goes through an extensive process to demonstrate readiness and is approved for merge, input on removing the feature during beta/RC should be solicited publicly via make/core posts and scheduled meetings, similarly to the initial merge decision. Otherwise, the decision to remove a feature can seem to ignore the value of the opinions that went into making the decision initially and may not be fully informed about the broader implications with respect to related aspects of a component. If work on a feature seems to stagnate as bugs accumulate during beta and a lead is considering pulling it due to lack of attention, contributors working on the feature should be notified so that they can address the issues or recommend removing the feature based on availability. Perhaps putting more trust in the feature teams and component maintainers that are most intimately familiar with a given project could help ensure that decisions are more broadly considered.”
        • Still a question of who really owns final decision/veto power; @matt as product owner likely
        • Whomever is leading the release has final decision. That’s why they’re a lead. That much should be clear.
        • Action Item: continue to communicate changes clearly and early
        • Release leads and core leads need to be trusted to prioritize based on goals for the release
        • When somebody is unable to solicit feedback, we need to have honest conversations about why this is happening
      • “Add automated acceptance testing for the user flows. If we add these for new features added, we can ensure they work across browsers. And in future releases, these tests can ensure that we don’t break existing flows. Run tests on BrowserStack. See #34693.”
        • Any volunteers to help work on this?
        • Anyone think automated acceptance testing for user flows is a bad idea?
        • It could be difficult to maintain
        • This is done at Automattic: https://github.com/Automattic/wp-e2e-tests
        • Action Item: keep exploring in the ticket
      • “more focus on Trac and tickets, every committer should try to follow Trac on a daily basis. Not to know 100% of the details of each ticket but at least to get a sense of what’s going on. Also, the number of tickets on Trac is increasing more and more, there’s the need of some serious ‘Trac Gardening'”
        • A big ask for every committer following Trac on a daily basis
        • Especially since the vast majority of committers aren’t being donated anywhere near full time (and a large number are 100% volunteer)
        • This is why there’s component maintainers, so that we don’t overburden each person
        • Trac Gardening is something anyone is welcome to do, you don’t need to be a committer
        • Trac Gardening would benefit from some mentorship to be more effective
        • If there could be some mentoring for this – an initial joint meeting to get people started might we get some more interest?
        • We could benefit from improved workflows for managing the resources we do have and to reduce the uncertainty in gardening/contributing in non-code ways
        • Trac Gardening can be a thankless task to a novice who comments on tickets, asks for dev-feedback and then nothing further happens for months. Perhaps the dev-feedback tag needs watching more rather than all tickets.
        • Action Item: generalize 4.7 Bug Scrubs page “to run a bug scrub, announce it here, talk to these people, look at this report in Trac, then ping people on the tickets listed”
    • Things to continue doing:
      • “The combination of a Git startup phase and Slack is excellent. At least for the Twenty Seventeen theme.”
        • GitHub likely helps get new contributors involved, but not sure they stick around
        • GitHub is easier to follow along, post mockups, get feedback, review code
        • GitHub better with searching, labelling, organizing, looking at PRs, realtime updates, making branches and then submitting PRs from branches, plus its app
        • Our current code review process is sub-optimal because there are no workflows to support it (e.g., line-by-line comments on changes)
        • It would be good to separate what is the project management tool vs. version control method
        • GitHub is sub-optimal when iterating on PRs. In Trac, you can make minor changes to a patch and upload it to a ticket. In Github, depending on permissions patch iteration is not straightforward.
      • “Weekly design meetings.”
      • “On the upside, having clear deadlines for when enhancements need to be merged into core is very helpful for prioritizing time and focussing resources. I hope we will continue some form product calendar in the spirit of “deadlines aren’t arbitrary,” even if they take a different rhythm.”
      • “increase the effort to involve different teams in collaborating on features development, where different skills and knowledge are needed, of course.”
    • @jorbin to work on a summary of what was discussed here and post it on Make/Core

    General Announcements

    • Uncertain if anyone is planning on running a core dev chat next week (or any weeks going forward), so watch for agendas on Make/Core or other notifications in #core
     

  • Jeffrey Paul 3:23 am on January 4, 2017 Permalink |
    Tags: , , ,   

    Dev Chat Summary: December 14th (4.7.1 week 1) 

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

    4.7 Retrospective

    • Please provide Retrospective feedback on Make/Core
    • We will review the feedback and then present it for discussion during the dev chat on December 21st and agree on action items on how we can improve in the future

    General Announcements

    • Discussion on overuse of post meta to make searches in queries
      • Utilization of terms as a potentially better option
      • Data could be stored in meta for precision, terms for searchability
      • Not certain this is something that Core needs to provide
      • Best to prototype and demonstrate use case via plugin first
      • Also dev education to understand problem and available, reasonable solutions
      • @igmoweb to write up idea as blog post or Trac ticket to detail concept, gather input from others via comments, and bring back to a future dev chat
    • Should we start requiring JS for most of WP Admin and thus not providing fallbacks?
      • some things that must always be usable without JS (e.g., changing/updating themes and deactivating/activating/updating plugins)
      • the general attitude of JS support (and some CSS back-compat stuff) is really one of “don’t lock the user out” for the most part
      • It’s nice to also be able to keep no-JS support for some of the most basic tasks, like posting
      • no-js MUST work when it comes to things that could break JS or are 100% vital (plugins/themes/login/logout)
      • no-js SHOULD work for basic tasks (i.e. posting)
      • no-js MAY work everywhere else
      • This needs to be defined more formally and we should define what things like “basic tasks” are
      • Plan to hash out language etc. with a draft and request for comments on Make/Core
    • How do we keep bug fixes and component roadmaps going in conjunction with feature dev?
      • Conversation postponed for a future dev chat

    4.7.1 Bug Scrub

    • 4.7.1 open tickets
    • There are 9 tickets that just need merging, everything else is owned by a permanent committer
    • Still no 4.7.1 lead or timeline
    • Could “push” an auto-update to Twenty Seventeen separately from 4.7.1, but that would still need someone to own that process
    • One of the Twenty Seventeen changes relies on a corresponding core change so it would be better for them to go together for 4.7.1
     

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

    Supporting the Future of wp-cli 

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

    To that end there are two big announcements:

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

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

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

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

     

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

    Idea: Uniform Resource Identifiers as an alternative to Shortcodes 

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

    Examples

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

    Object Types

    This approach could be good for:

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

    This is not good for:

    • Layout.
    • Text conversions.

    Inspiration

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

    Benefits

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

    Implementation

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

    Challenge: Variants and Settings

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

    Challenge: Alignment

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

    Challenge: Namespace

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

    Challenge: Extra Queries

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

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

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

     

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            • Weston Ruter 8:05 pm on January 3, 2017 Permalink

              @iseulde All widgets I guess. I mean, would it make sense for there to be a standalone page that just displayed a single Meta widget, for example?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Implementation

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

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

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

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

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

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

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

      Variants and Settings

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

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

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

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

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

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

      Matching URLs that should display as URLs

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

      Extra Queries

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

      And let me say again, LOVE the idea!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Mark Root-Wiley 3:45 pm on January 5, 2017 Permalink | Log in to Reply

      My first reaction is that I like this a lot. I also think most comments that raise specific concerns are quite valid.

      Rather than repeating anything that’s already said, I’ll just share one broad thought: With the new focus on *design*, this especially feels like a technical solution in search of a problem. I like the idea in the abstract, but right now, it’s hard to evaluate without a shared problem it’s attempting to solve.

      Similar to some other discussions I’ve seen lately, starting with data storage doesn’t seem like the best way to approach something that absolutely needs a UI to function well. Developing a UI will almost certainly make clear what problems need solving. As the OP mentions, if a proposed UI frequently requires settings/customizations, then URIs aren’t an appropriate solution.

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

    Week in Core, December 7 – 13, 2016 

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

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

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

    Code Changes

    Administration

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

    Bootstrap/Load

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

    Build/Test Tools

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

    Comments

    Customize

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

    External Libraries

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

    General

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

    Login and Registration

    Media

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

    Misc

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

    Options, Meta APIs

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

    Query

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

    REST API

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

    Role/Capability

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

    Taxonomy

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

    Themes

    Toolbar

    Users

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

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

     

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

    Multisite Office Hours Recap (December 13, 2016) 

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

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

    Today’s chat log

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

    Chat Summary:

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

← Older posts

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