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

  • Felix Arntz 4:18 pm on January 23, 2017 Permalink |
    Tags: ,   

    Improving the Settings API for accessibility and ease-of-use 

    On January 2nd the first meeting to discuss improvements of the well-known, but not well-loved Settings API took place in #accessibility. After a healthy discussion the next meeting was set to take place last Monday. Since the suggested improvements are not solely related to accessibility, the location for the meeting was moved to #core. This post is a recap of what was decided during these two meetings.

    Archives of the full conversations:

    Attendees: @afercia, @flixos90, @helen@joedolson, @johnbillion, @rianrietveld, @sc0ttkclark

    First Meeting

    The original reason for calling these meetings were several accessibility problems on WordPress settings pages. To quite some extent, these are related to the table markup that is automatically printed by the current Settings API. On a related note, it was mentioned that being required to write callback functions for rendering each and every field is a major drawback. Providing default callbacks would thus not only make it easier to work with the API, but also further improve accessibility as these callbacks would all be reviewed by the team. So the two main goals that were figured out were:

    • Add some basic support to automatically render fields so that plugin developers no longer need to write their own callback functions for basic fields.
    • Get rid of the table structure to improve accessibility. Furthermore the accessibility team should also ensure that the markup generated as the core field output is accessible.

    The first meeting was also centered on whether these improvements should be tackled through means of the Fields API project, a new “Settings API v2” or improving the existing Settings API. In the end it was decided to continue working with the existing API, mainly for the following reasons:

    • The Fields API project is a huge effort that will still take a while until it can possibly be merged into core. Still, it will follow up with the changes that will be introduced in the Settings API, as @sc0ttkclark pointed out. While printing fields is certainly the focus of the Fields API, introducing a few technically simple callbacks in core at this point will not be a problem as these can be migrated to the Fields API ones at any time.
    • While the existing Settings API has its problems, it appears to be possible to handle the necessary improvements without running into backward-compatibility issues. A completely new Settings API could have further benefits, but it would leave many users behind that would need to manually migrate, and furthermore would take much longer to scaffold and implement.

    After the meeting, a general ticket for the task was opened at #39441. The ticket description provides more information on how the two identified goals should be accomplished. In addition to the technical details, the first part of the accessibility measures will be to create an HTML-only prototype of what a better settings page would look like. It should be created without the limitations of the Settings API, so that the result can be the best possible example for what the enhanced Settings API should produce.

    Second Meeting

    @rianrietveld had four items on the agenda for the second meeting.

    • At first, everyone was asked to review the patch that @flixos90 provided on the above ticket. The patch only applies to introducing default field callbacks, so it still lacks adjustment of the table markup and a proper accessibility review, but it shows a possible technical approach.
    • Related to the patch, a tiny plugin was created and uploaded to the ticket as well. This plugin allows for easy testing of the functionality. For easier collaboration and possible iterations, that plugin has now been moved to GitHub. Feel free to try it out with the patch applied.
    • Some results of an accessibility test for form elements that was conducted by the accessibility team were revealed as a preparation for the prototype settings page in HTML. A few major issues to consider were discussed, for example the requirement of IDs on every field, the proper usage of fieldset and legend elements and the problematic usage of <input type="number"> for Dragon NaturallySpeaking speech recognition software. For creating the HTML prototype, it was decided to focus on replicating the core settings pages “General” and “Discussion”.
    • For the next step of the efforts, @afercia volunteered for creating the prototypes. As of now, the field markup he created for the two replicated settings pages can be inspected on GitHub (last two items in the list). These will probably be discussed in the next meeting.

    If you are interested in helping out, there are several ways for you to do so: Please review the suggested improvements, the HTML prototypes and/or the technical approach. Feedback can be provided on the ticket, this post or by participating in the upcoming meeting/s. The Settings API meeting takes place biweekly on Monday at 17:00 UTC, so feel free to drop by. The next meeting will be on Monday, January 30.

     
  • Mel Choyce 7:48 pm on January 19, 2017 Permalink |  

    Customization in 2017 

    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.

    Matt

    One expectation I want to start with is, customization isn’t just improving the Customizer — our goal is to improve the entire process of setting up a site, from initial installation to something you’re comfortable launching, to making changes to an existing site that has been live for some time. To that end, our goal is to help people accomplish the following:

    • “I want to make a site that I’m proud of that helps me succeed.”
    • “I want to make a site my clients are proud of that helps them succeed.”

    The current customization flow in WordPress doesn’t generally facilitate either of those goals without a great amount of work, prior knowledge, and often a lot of additional development. That’s fine if you’ve hired an agency, or you’re a developer building yourself a website — but not fine if you’re a freelance site builder/implementer (a market I see every day in my local community) or are trying to build something for yourself with limited time and budget. If you can install WordPress, either manually or through a host, we should provide you with the tools to build out a website that accomplishes your personal and business goals.

    With these goals in mind, what can we accomplish in the first couple months of the year?

    • Demo content on theme switch for an existing site. [#38624]
    • Pain points with lost widgets and menus when switching themes.
    • Exploring a better customization-focused onboarding experience.
    • Adding an media widget. [#32417]
    • Adding formatting options to the text widget. [#35243]
    • Adding a code editor to the Custom CSS control, and make additional enhancements. [#12423, #38707]
    • REST API endpoints. [#39634, #38900]
    • Improving Custom Logos. [#38329, #36191]
    • Some more minor Customizer improvements [#37471, #38953, #39389] and continued bug fixing.
    • What else? Please comment.

    Throughout the rest of the year, there’s a lot of larger projects that we’ll collaborate with the editor team on:

    • Content blocks, so we can build a better layout editor that helps people build a site that fits their individual needs. [Post]
    • Revisions, so you can visually see the changes you’ve made to your site and revert if you mess up. [#31089, #21666]
    • Drafting, reviewing, publishing, and scheduling changes, so you can get your site looking just right before you push your changes live. [#31089, #28721]

    Some of these, like revisions in the Customizer, we can prioritize sooner.

    By the end of 2017, we hope you’ll be able to:

    • Have an onboarding experience with smart defaults that guides you towards building the site you want, faster.
    • Build complex, dynamic layouts for your WordPress sites, regardless of your theme.
    • Move any piece of content on your site to a different part of your site, just by dragging and dropping it where you want.
    • Allow you to preview and select page layouts before you create your page.
    • Edit every piece of content where you see it, instead of needing to hunt for it.
    • Set up a basic website without having to jump in and out of multiple admin screens.
    • Live preview any settings that affect how your site looks.
    • Revert changes and see your revision history.
    • Maybe even build your whole site from your phone?

    What other customization flows do you think we need to improve? We need your input to help make a better way to build sites with WordPress.

    We’ll be doing weekly meetings every Monday. The next meeting is Monday at 1:00PM EST. Join us in #core-customize in Slack to get involved!

     
    • BinaryMoon 9:20 pm on January 19, 2017 Permalink | Log in to Reply

      I’d like to see an improved process for custom/ static front pages. ie not having blog posts on the homepage. The current process is a bit on the painful side.

    • Tammie Lister 9:30 pm on January 19, 2017 Permalink | Log in to Reply

      Love how you’ve turned this into user experience expectations at the end of the year. Really excited to see a plan for this year and what will be accomplished.

      It feels like you’ve got everything here and I totally agree with the notion that the entire process should be looked at in this.

    • imath 9:58 pm on January 19, 2017 Permalink | Log in to Reply

      Hi,

      Everything you’ve detailed is great and i’m amazed about the great improvements that were made possible thanks to the Cutomizer in the user experience, many thanks for all the great work about it.

      There’s one thing that is, imho, lacking some customisation possibilities. It is the content people are receiving from WordPress sites within their mailboxes. It’s plain old text today (unless you activate plugins).

      BuddyPress made great improvements on their notifications process making possible to send them in a multipart alternate way (html + plain text) + having a customisable email template within the customizer.

      There’s are tickets on Trac that are pretty old which could get some attention so that WordPress is also really awesome in People mailboxes :

      I think this is an area that could benefit from a core API Themes could use to be able to build email templates that are as beautiful as how they are shaping the Site’s front end.

    • David A. Kennedy 11:32 pm on January 19, 2017 Permalink | Log in to Reply

      One thing that comes to mind from a flow perspective, even though it may not be experienced a lot or high priority: theme switch flow.

      There’s a lot of a site that gets reset on a theme switch: widgets, menus, did you know you should probably resize your thumbnails. etc. It might be worth hooking into a site setup flow on theme switch and/or figure out some other ideas to make the reset less painful and less work for users.

    • Anthony Hortin 3:37 am on January 20, 2017 Permalink | Log in to Reply

      When is the Customizer going to be made wider? People have been literally begging for this since the Customizer was first introduced and yet still nothing has been done about it. The existing Customizer experience, with the tiny single column, is horrible. There was even a Trac ticket created for this, almost 2 years ago – https://core.trac.wordpress.org/ticket/32296

      I really hope the new editor changes aren’t going to be built into the Customizer. Users don’t want to be editing their content within the Customizer. It’s bad enough trying to use it just to update theme options. it seems like everything is being pushed into the Customizer and the the rest of the Dashboard has been completely forgotten. Users want to see a new editing experience on the Posts on Pages screens, not in the Customizer where all their theme options and sites settings are. The Customizer is not the place for editing content.

    • HunterHawley 3:59 am on January 20, 2017 Permalink | Log in to Reply

      Love to see a plan for this year. As a WordPress developer, and not a mobile developer, one thing I’ve always wanted to see is either an interface or an API for integrating your WordPress database with mobile apps. A way of easily creating dynamic apps with updates coming from the WP site itself.

    • Morten Rand-Hendriksen 4:23 am on January 20, 2017 Permalink | Log in to Reply

      This is a great and ambitious list of enhancements. I think one of the most important points to bring to the discussion here is to base this work off extensive qualitative and quantitative user testing and research. We need to know what the average WordPress site owner wants and needs and how to meet their goals while moving the platform forward. This would be the time to start a large scale user research project and promote data-driven design and development, especially in relation to user-centered features like customization.

    • Ulrich 7:02 am on January 20, 2017 Permalink | Log in to Reply

      Pain points with lost widgets and menus when switching themes

      I think this trac issue is related https://core.trac.wordpress.org/ticket/19912 Also related this is a block post by a friend https://ms-studio.net/notes/painless-theme-switching-in-wordpress/

    • Ross Wintle 10:45 am on January 20, 2017 Permalink | Log in to Reply

      A couple of thoughts:

      There were some things that 4.7/Twenty Seventeen did that were really helpful like default content. And that may totally be the answer to this issue, but I’ve always wondered why there isn’t a simple workflow for putting a site into “blog” mode or “website mode” or more generally “X mode”.

      Default content helped with this a little, but you still need to set things like the stupidly-difficult-to-understand
      “front page displays” option.

      You guys must have explored this, but I’ve always wanted the install process to do something like:

      What sort of site are you creating?

      [a Blog/news site] [a regular website]

      When you select blog/news site, the traditional front-page options are left, a blog post gets created, comments are turned on, etc. You could then be given the option of writing your first post, or choosing a theme and customizing the site.

      When you select regular website, comments are turned off, pages are hoisted up the menu to where posts are, and you’re asked to name your first page, which is created as the front page.

      I’m pretty sure this is all being discussed, but as a first step some stuff like this would really help. The number of times I have to go through this setup process for a non-blog-style website is insane. It needs install modes.

      Secondly, this is kind-of prompted by:

      “That’s fine if you’ve hired an agency, or you’re a developer building yourself a website — but not fine if you’re a freelance site builder/implementer (a market I see every day in my local community) or are trying to build something for yourself with limited time and budget.”

      but is actually developer related.

      I find creating simple customizer options really hard. I would LOVE to have a simple abstraction of the customizer API built into core. Just so, for example, I can do something like (apologies if this is a bit fluent/Laravelly):

      $wp_customize()
      -> add_section(‘Homepage options’, ‘is_front_page’)
      -> add_text_option(‘banner_text’)
      -> add_image_option(‘banner_image’)

      This could create all the postMessage JS for me, create the option, add the section and add the option to the section.

      It would just remove a barrier to quickly setting up simple options in the customizer, which I assume are the most common use case (willing to be disproven).

      Currently I have a library of snippets that I need to copy/paste/search/replace with and have to keep referring back to the docs to make sure I get everything right.

      As a freelance developer building small custom sites for clients on a budget, I would use the customizer far more often if the API were simpler.

      Thanks

      • Weston Ruter 5:39 pm on January 20, 2017 Permalink | Log in to Reply

        I think there is good overlap here with #38624 (demo content on theme switch for an existing site) which would open the door for having sets of starter content. There could be a set of starter content for blog or brochure site which the user could chose between.

    • nickmanderfield 12:02 pm on January 20, 2017 Permalink | Log in to Reply

      Visual revisions will be very welcomed here. Is this extending to pages and posts, going beyond the explained customizer? Copy and pasting entire post saves to private demo pages to visually compare revisions is quite time consuming, especially with intricate page builder pages.

      (Typo “Adding an media widget. [#32417]” should be “a”)

    • Goran Petrovic 3:42 pm on January 20, 2017 Permalink | Log in to Reply

      Hi,

      Is it possible to add options from custom meta boxes in Customize just for that post or terms meta boxes just for that term?

      Best regards,
      Goran

      • Weston Ruter 5:36 pm on January 20, 2017 Permalink | Log in to Reply

        It is possible, but not yet in core. The Customize Posts plugin has facilities for adding controls for posts and postmeta. There is no plugin yet for managing terms and termmeta as far as I am aware, though it is on my wishlist.

        • Goran Petrovic 8:31 pm on January 20, 2017 Permalink | Log in to Reply

          Thanks.

          I have idea how to make it.
          I can after save customize get values and save on post_meta or term_meta table…

          But best options will be when you register meta box he also show in Customize…

    • Helen Hou-Sandi 5:31 pm on January 20, 2017 Permalink | Log in to Reply

      For once I think we’ve managed to pick a good word for this process – customization, as opposed to building. Maybe a reasonable way to look at this in conjunction with editor improvements is that one is more about customizing things to get where you want (which implies starting with strong and smart defaults) and the other is about building out X content area. There’s definitely still overlap, but as I’m thinking through each of these focus areas, I’ve found this to be a helpful way for me to think about what the motivations and goals should be.

    • clearfickle 12:00 am on January 21, 2017 Permalink | Log in to Reply

      How about finally enabling js files to be listed in the appearance editor?

    • Nick Halsey 7:12 pm on January 21, 2017 Permalink | Log in to Reply

      The biggest thing not explicitly mentioned in the post is that everything should be able to be edited and live-previewed in a unified experience. More explicitly, this means that content can be edited within the customization interface, and this should include both posts and terms.

      There are a few other items that I think need to be prioritized for the next few months:

      • Term status API, so that we can live-preview terms and term meta.
      • Expanding the partials API to facilitate inline editing, so that that can be used in implementing the eventual block-based UX and things don’t have to be edited in the controls “pane”.
      • Framework for discovering and installing themes. #37661 is ready to go and has a detailed plan of action. Let’s get it back into trunk, fix the obvious bugs, and start exploring ways to improve the theme-browsing UX and related APIs/theme directory stuff. Then, we can incorporate themes into the site setup and customization/redesign flows within the customization experience and adapt that technical foundation to new flows as needed.

      A new theme browser integrated with a site setup flow and the customize API would be an excellent improvement so that users start from a theme rather than customizing something that may not be even remotely close to what they want. Themes are the biggest thing that impacts customization; without the right theme to start from, everything else we do will have a limited impact on users. The current “theme switcher” is basically unusable and frankly not something that is acceptable to live alongside a shiny new customization experience.

      • Weston Ruter 5:30 pm on January 23, 2017 Permalink | Log in to Reply

        I think “everything should be able to be edited and live-previewed in a unified experience” is entailed by:

        • Edit every piece of content where you see it, instead of needing to hunt for it.
        • Live preview any settings that affect how your site looks.

        But in any case I agree, and that both posts and terms need to be able to be created and updated with live preview. Most of the work on posts and terms would be done in the editor view, but the editor view should be seamlessly part of the customizer view, so you can switch between them.

        Expanding the partials API to facilitate inline editing

        Agreed. This goes hand-in-hand with bootstrapping the customizer onto the frontend so that you can seamlessly just customizing without having to navigate to customize.php.

    • Hardeep Asrani 9:03 am on January 22, 2017 Permalink | Log in to Reply

      Along side having a syntax editor for CSS control, it will be great to have it for Theme/Plugin editor as well.

    • morespinach 6:32 am on January 23, 2017 Permalink | Log in to Reply

      The intent is well written and much needed (about time in 2017!) but the items are way too trivial things here. Widgets? Seriously? Who cares.

      Please make the custom fields setup an intrinsic part of WP Core. Writing custom post types in functions.php and then using some plugin or another (ACF, Metabox, etc) to do anything sensible is so…2001. Please make this an intelligent portion of WP, so enterprises and serious websites can do this in a more elegant manner.

      Related to this are features such as a precise and detailed audit log of every “post” (item of content type) being created, edited, sent for approval, launched, expired, etc. This should be shown at the bottom of each “post” (of any content type).

      Similarly, wiring security of WP to other systems inside a large organisation such as ActiveDirectory, via some kind of mechanism such as OpenID or the popular tools. This would go a long way.

      I hope we can see more meaningful discussions of this nature instead of widgets. Platforms such as Craft etc are shaping up nicely. It’s time WP became a proper platform for serious content management in 2017, instead of its blog-legacy-but-now-a-bit-more persona based on a maze of plugins.

    • George Olaru 12:03 pm on January 23, 2017 Permalink | Log in to Reply

      I’d love to see a simple and straightforward system implemented for a Visual Grid/Columns inside the Editor. We’re already working on something based on rendered shortcodes which seem to integrate pretty good in the current editing flow. I did a small recording video on how it’s working now: http://pxg.to/2jfdPcj

    • Abhishek Deshpande 1:47 pm on January 23, 2017 Permalink | Log in to Reply

      How about Adding Search Options in Settings,

      Simple Options like To Include / Exclude Registered Types, Media attachments, Author Info etc.

  • Jeffrey Paul 7:35 pm on January 19, 2017 Permalink |
    Tags: , , ,   

    Dev Chat Summary: January 18th (4.7.2 week 1) 

    This post summarizes the dev chat meeting from January 18th (agendaSlack archive).

    4.7.x Releases

    • Moving to monthly checkins for 4.7.x releases
    • A few people stepped up to lead a future 4.7.x releases, a great way to get involved in the release process. If you’re interested in leading a future minor release, ping @samuelsidler anytime.
    • For 4.7.2, we haven’t set a schedule yet, but we’ll be checking tickets and commits in early February to decide if we should release. @jnylen0 will be the release lead.
    • Reminder for those who helped get 4.7.1 out, please check the handbook to see if updates are needed to help @jnylen0 on 4.7.2.
    • @jnylen0: some API stuff I want to get into a potential 4.7.2, but let me know about other tickets you’d like to milestone
    • Outside pressure on MIME issues not as horrific as one might have expected (ticket #39550: Some Non-image files fail to upload after 4.7.1)
    • Potential that since people using special MIME types (which are the most likely to get caught by this bug) are already aware of having to add in custom mimes, adding in the “unbreak” plugin to fix the problem right now isn’t seen as insurmountable.

    REST API team update

    • kicking off the new year by defining the scope of our activities, and prioritizing what is most critical to do first
    • @kadamwhite, @jnylen0, @tharsheblows, @kenshino, & others working on expanding the documentation
    • As we’ve moved the support for the REST API from the “WP-API” github repo, we’re seeing a few repeat questions that can be clarified with better docs & docs organization
    • Today we finished grouping existing docs from the old wp-api.org site into “Using” and “extending” buckets, which are reflected in the left nav; next up, we’ll be adding more docs for using the basics of what’s there
    • @rmccue leading the technical investigations into what to prioritize from an implementation standpoint (see: January 9th 4.8 kickoff meeting notes)
    • a lot that could be converted to use the API within WP-Admin, but change for the sake of change has never been a core value of this project
    • Whereas for something like list table actions, there’s a lot of inconsistency within the admin and converting some of those areas of functionality to use the REST API endpoints would be a clear win
    • We’re using a Trello board to track the areas of investigation
    • the Multisite and BuddyPress teams are both investigating how best to improve or create API endpoints tailored to those use cases
    • @flixos90 did an excellent writeup of our users endpoint discussion
    • We are sorting out how user and site membership management and display should work for the users endpoint.
    • master ticket #39544: REST API: Improve users endpoint in multisite
    • the REST API team intends to continue using the feature projects model to structure proposed API enhancements (such as menu support), with the added requirements of starting from a design document, and checking in with a core committer for periodic review to avoid the feature project from becoming silo’d
    • Multi-site is the first such feature project that’s officially under way.
    • For 4.7.2 we should be looking for related bugs around the existing functionality
    • @jnylen0: propose that we continually evaluate test and documentation coverage for new additions, as an excellent way to find bugs before they ship and we are stuck with them
    • Regarding bugs, to all: when (not if) you find a documentation issue or omission, or find an area where the API does not behave as expected, you are all welcome in #core-restapi at any time and we welcome the feedback.
    • We’re glad to see that the support questions so far tend to fall in a few specific buckets, but this is a new thing and the more eyes on it, the more likely that we’ll be able to identify the key areas where improvement will really drive admin or customizer improvements.
    • REST API team meeting is weekly at Monday 14:00 UTC in #core-restapi, and we welcome one and all to come chime in about how you’d like to see this used

    Customizer team update

    • Please read and contribute to the discussion happening on the “What makes a great customization experience?” post
    • Also recommend reading through the meeting that happened earlier today in #core-editor. There’s going to be a lot of overlap, especially as the editor team starts working on content blocks. Lots of discussions have been happening there and in #core-customize related to what we focus on for customizer in the immediate term.
    • We’re identifying some smaller, quick wins we can do to improve the customization experience while content blocks are being built.
    • Update coming on Make/Core soon for more ways to get involved and a separate post from @karmatosed on Make/Design for some ways to help us test the existing customization flow
    • Customize team meeting is weekly at Monday 17:00 UTC in #core-customize, please do join us for general brainstorming and ticket triage (see also: prior meeting notes)

    Editor team update

    • Please read and comment on the “Editor Technical Overview” post
    • Recap of #core-editor meeting on a target of a prototype plugin for exploring these concepts from @matveb: Yes, target could be:
      • Data structure.
      • Parsing mechanism.
      • General UI for block display / controls.

    Trac Ticket(s)

    • #39535: Canonical redirects disallow tag named comments
      • @asalce: looking to get owner on the ticket and review of patch
      • will ping @markjaquith or @dd32 as maintainers of Canonical component
     
  • Andrew Rockwell 3:41 am on January 19, 2017 Permalink |
    Tags: ,   

    Week in Core, January 11th – 17th, 2017 

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

    • 165 commits
    • 44 contributors
    • 87 tickets created
    • 9 tickets reopened
    • 83 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

    • List Tables: Pass the $which parameter to restrict_manage_posts filter instance in WP_Media_List_Table, missed in [37422]. [39917] #38772
    • Improve tab character width in Plugins and Themes editor. [39897] #38684

    Build/Test Tools

    Bundled Theme

    • Twenty Seventeen: Remove duplicate global $post declaration in twentyseventeen_front_page_section(). [39909] #39590
    • Twenty Seventeen: Correct @param entries for twentyseventeen_custom_colors_css filter. [39901] #39575
    • Twenty Seventeen: Remove extra asterisk from a translator comment so the comment could be parsed correctly. [39894] #39116

    Cache API

    • Docs: Add missing @param type for wp_cache_get_last_changed(). [39900] #39571

    Database

    • dbDelta: Ignore index subparts when checking for duplicate indices. [39921] #34870

    Editor

    External Libraries

    Formatting

    • Tests: wpautop() should not add extra before. [39914] #39307
    • Fix wpautop() to stop adding paragraph tags around “. [39912] #39307

    I18N

    • Move “Site Language” setting above “Timezone”. [39885] #38562

    Media

    • Use a consistent error message for file type errors on uploading. [39891] #33242

    Misc

    • Post-4.7.1 version bump for 4.7 branch. [39883]
    • Only show major version in readme.html for 4.7 branch [39871]
    • Media: Fix exif_imagetype check in wp_get_image_mime [39851-39861]
    • Tests: Replace broken codeispoetry.png file. [39848-39849]
    • Use plural string ‘Maintenance and Security Releases’ since we have two now [39847]
    • REST API: Change which users are shown in the users endpoint. [39844]
    • Media: Improve image filetype checking. [39832-39842]
    • Updates: Translate plugin data on the Updates screen. [39808]
    • Themes: Fix markup for theme name fallbacks. [39807]
    • Multisite: Use wp_rand() in signup key creation. [39795-39806]
    • Mail: Disable wp-mail.php when mailserver_url is mail.example.com. [39772-39782][39784]

    Plugins

    • Docs: Use a consistent description for $plugin parameter in various plugin API functions. [39890] #36333
    • Docs: Improve the DocBlock for validate_plugin(). [39889] #36333

    Posts, Post Types

    • Increase the height of post slug input to prevent certain characters from being cut in Firefox on Windows. [39905] #28084

    REST API

    Taxonomy

    • Docs: In wp_set_object_terms(), add a note that passing an empty value as $terms argument will remove all related terms. [39893] #36690

    Text Changes

    • Taxonomy: Add an explanation for “Parent” dropdown for hierarchical custom taxonomies. [39895] #23447

    Themes

    • Add a unit test for get_theme_feature_list() to make sure that the list of theme features pulled from the WordPress.org API returns the expected data structure. [39906] #28121
    • Docs: After [37083], change “HEX format” to “3- or 6-digit hexadecimal form” for clarity. [39888] #36336
    • Use curly braces for variables inside strings in `get_page_template() to explicitly specify the end of the variable name. [39884] #38625

    TinyMCE

    • Strip browser inserted <u> and <font> tags from inside links when copying and pasting in IE and Edge. [39916] #39570
    • Ensure the inline toolbar is shown and properly positioned when there are several wpview blocks in the editor and the user selects one after the other. [39910] #38849
    • Prevent the inline toolbar from appearing on partially selected wpview nodes. This can happen when HTML is initially loaded in the editor and wpview is the first node, or sometimes on repeatedly pasting the same wpview. [39904] #38849
    • When inserting a wpview, place the caret after is so the user can continue typing without interruption. [39903] #39337
    • Improve removal of spaces from empty paragraphs when loading HTML in the editor. [39902] #39437

    Upload

    Users

    • Introduce signup_site_meta and signup_user_meta for filtering signup metadata in wpmu_signup_blog() and wpmu_signup_user(), respectively. [39920] #39223
    • User Query: Cast $user_total as an int. [39915] #39297
    • I18N: Reference correct placeholder in a translator comment added in [30333]. [39908] #30264
    • Display the name of user being edited on Edit User screen. [39907] #28182
    • Docs: Make $meta parameter description in multisite signup and registration functions more consistent. [39887] #38781
    • In wpmu_signup_blog() and wpmu_signup_user(), pass unserialized signup meta data to after_signup_site and after_signup_user filters introduced in [34112], to match the documented value. [39886] #38781

    Widgets

    • In unregister_sidebar(), rename the $name parameter to $sidebar_id for consistency with is_registered_sidebar(). [39892] #35147
    • Add nonce for widget accessibility mode. [39760-39771] #23328

    Thanks to @aaroncampbell, @afercia, @afzalmultani, @Ankit K Gupta, @azaozz, @barryceelen, @ccprog, @dd32, @diddledan, @DrewAPicture, @dspilka, @F J Kaiser, @gitlost, @iandunn, @iseulde, @ixkaito, @jackreichert, @jblz, @jeremyfelt, @jnylen0, @joemcgill, @johnjamesjacoby, @kuck1u, @MaximeCulea, @Mista-Flo, @netweb, @ocean90, @pavelevap, @pbearne, @pento, @peterwilsoncc, @Presskopp, @rachelbaker, @raggedrobins, @rmccue, @runciters, @seanchayes, @SergeyBiryukov, @Soean, @swissspidy, @theMikeD, @tmatsuur, @vortfu, and @wpsmith for their contributions!

     
  • Jeffrey Paul 3:53 am on January 18, 2017 Permalink |
    Tags: , , ,   

    Dev Chat Agenda for January 18th (4.7.2 week 1) 

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

    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!

     
  • Matias Ventura 4:52 pm on January 17, 2017 Permalink |
    Tags:   

    Editor Technical Overview 

    As we start looking at the editor from a technical perspective it’s important we identify the main obstacles and requirements we face before we start conjecturing solutions. As @matt wrote before, the editor focus aims to make writing rich posts effortless. This has taken the path of treating a post as being composed of distinct pieces of content called blocks. These pieces should be easy to insert and manipulate, providing rich and contextual interfaces to interact with as you craft a post.

    So how do we go about turning this into a reality? Content in WordPress is, fundamentally, HTML-augmented text; that is to say, it has no inherent data structure. This has been a very important aspect of WordPress and a force for the open web—it speaks to the sense of ownership and freedom WordPress gives you, since it’s always easy to get the full content of your publications—yet the lack of structure gets in the way of the goal to treat content as composed from individual pieces. (This reality also became an issue for the development of post formats a few years ago, but I digress.)

    It’s relatively easy to add structure, but it’s not trivial to do so in a way that doesn’t harm data integrity, portability, and the cohesiveness of the post_content. So let’s lay out a first requirement:

    ① Shape of the Data: Portable Text

    To ensure we keep a key component of WordPress’ strength intact, the source of truth for the content should remain in post_content, where the bulk of the post data needs to be present in a way that is accessible and portable, while still providing additional structure on top of HTML semantics for our editing tools. Data needs to be praised and respected. This additional structure would hopefully be invisible to the document’s display context, as it ensures the rendered content is viewable in situations that may not be aware of blocks at all. (Think of email clients, RSS, older editor versions, mobile editors, database dumps, etc.)

    Storing things separately means post_content becomes either a pointer or duplicated data, which fragments the source of truth since they can get out of sync easily. (A few content block plugins do this by storing structured data in postmeta and pure data in post_content.) On the other hand, storing things together means structure can become gibberish if it’s not formatted properly before display.

    How can we then offer users a great experience when creating or manipulating content without sacrificing the spirit of integrity and data reliability that is expected from WordPress? Good representations of the data would also make it easier to develop robust collaboration tools in the future by allowing us to lock things in a more fine grained way. I believe this is important to figure out soon to allow us to prototype quickly, so I’ll follow up with an initial proposal by the end.

    Honouring HTML leads to a second requirement:

    ② Simplicity and Semantics of Representation

    Unless we are improving the semantics of the document we should minimize what markup we add to identify a block; for example, avoid adding extra DOM elements or attributes, both for simplicity and standards sake. WordPress has been a champion of web standards, and we should not venture away from this quality. How can we add structure in a way that remains invisible to the output (as meaningful content as possible) but gives the necessary hooks to infer a structured view for editing purposes?

    While we discuss how to structure the content to include invisible demarcation of blocks, the aspect of their nature leads to a third requirement:

    ③ Static & Dynamic Blocks

    Blocks can be either static or dynamic. That is to say, some blocks can be stored with all the necessary aspects needed for their display, while others need to be processed before generating their final output (shortcodes, embeds, widgets, etc). This distinction is important because the most common two blocks people will naturally use are text and images. We should not break their clarity as we treat them as blocks.

    
     # Static
    Here’s some text.

    # Dynamic
    [text id=123] // Pulls "Here's some text" from somewhere.

    This conceptual separation of blocks is useful for designing our project, yet they generate abstract complexity which users should not be exposed to, leading to a fourth requirement:

    ④ Consistent Experience

    One of the biggest benefits of blocks is that composing a post becomes more intuitive and reliable. Everything is inserted under the same assumptions; discovering what can be inserted is a natural part of inserting content. To the user all blocks behave in a consistent and familiar way, even if they provide tailored UIs for their controls.

    The user should also be able to edit a post in a different system (mobile, REST, older version of core, apps like Mars Edit, etc), even if they lose the advantages of block editing. That’s another reason why post_content as source of truth matters, compared to storing a JSON structure in postmeta. Having things in two places means they can get out of sync depending on what tool you used to edit.

    These nuances of data, UI, and display lead to a final and more general requirement, which is understanding the system we’ll be crafting:

    ⑤ The System

    The editor experience has three fundamental aspects to its system: the UI used to manipulate a block; the demarcation of the block; the rendered output of the block. These are all separate concerns, from the tools we craft to edit a post, to the document syntax that holds the data structure, to the way the final output is generated to be displayed as HTML. (With static blocks that last aspect may be of no significant concern since the document doesn’t care about the presence of static blocks, it just displays them.)

    Picturing these concerns as connected but fundamentally separate would help us figure out the best design and technical solutions for each stage, while avoiding us taking aggressive moves by coupling expectations. For instance, JavaScript is a natural technology to look at when it comes to the ability to manipulate and interact with content blocks, yet it may not be the best at all when it comes to rendering the final post to a viewer. Avoiding painting the whole flow under the same light should allow us to focus efforts, because we don’t have to change everything.

    ❶ Coda

    As a final coda, and following @joen‘s design exploration, let’s keep in mind that our first goal should be to set up a reliable foundation to allow us to iterate quickly and test assumptions. I propose we focus initially on a few static blocks (text, image with and without caption, quote) to limit scope of the project.

    In which ways can we fulfil ① and ② from the above requirements?

    Shortcodes fall short in that they are not invisible, they are opaque, not standing to the scrutiny of semantics, and are also painful to parse. Alternatives could be data-* attributes in the HTML elements or custom elements (paving the way for web components, perhaps), yet we need to be careful with adding cruft.

    One other possibility is to look at HTML comments as a way to provide explicit demarcation to post_content without affecting the node structure of the document for something that is inherently spurious to the HTML semantics. WordPress already uses comments for the more tag (<!--more-->) and splitting content into pages in a way that has proven to be quite robust.

    It could look something like this:

    <!-- wp:image -->
    <figure>
      <img src="/">
      <figcaption>A picture is worth a thousand words</figcaption>
    </figure>
    <!-- /wp -->
    

    There are drawbacks, benefits, and implications with each that we should discuss separately. Are there any other possible solutions?

    Please, join us in #core-editor if you are interested. We’re holding weekly meetings in Slack, Wednesdays at 19:00 CET.

     
    • Mike 5:33 pm on January 17, 2017 Permalink | Log in to Reply

      There is a trend towards the use of more attributes and elements. The editor needs to allow for this or for others to create a plugin to do this.

      • programmin 10:07 pm on January 17, 2017 Permalink | Log in to Reply

        How does it not already? Are you referring to how KSES strips out data-attribute=”attributes” in html?

    • Davide 'Folletto' Casali 5:34 pm on January 17, 2017 Permalink | Log in to Reply

      Thanks for outlining this so crisply. Stating all the requirements clearly is something often overlooked, and I feel it’s a great starting point. I’m sure there are going to be things to be expanded in the following weeks, but seeing everything together in this way is excellent.

      Agreed on all the pieces. Let’s the discussion move forward! 🙂

    • FolioVision 7:09 pm on January 17, 2017 Permalink | Log in to Reply

      Wow, that’s quite an essay on the content editor. We’ve been doing this for a long time and know the lay of the land. We even built a WYSIWYG editor we can’t give up (we tried for two years). First in praise of the WordPress editing experience: the Media Library has grown to be very powerful and easy to use. It’s awesome. We were delighted to retire the original image editing module we were using last year and fully integrate the Media Library.

      Still what are the issues with WordPress content editing which drive us to maintain a separate WYSWIYG editor?

      Hint, it’s not the money, thousands of hours have gone into this purely GPL and non-commercial product. It’s not boredom. We have too much to do in three lifetimes and very short weekends already.

      It’s not shortcodes. Shortcodes are great and reliable ways to easily and visibly add content to posts. As soon as you start trying to hide the pieces, reliability falls through the cracks. It’s why lawyers still use WordPerfect.

      Why were we unable to give up our own FCK WYSIWYG editor? Code and javascript mangling. The WordPress TinyMCE editor does not reliably maintain paragraphs and linebreaks. It’s a bit WYSYMightNotGet. When creating complex nested tables and code examples our editor never fails (don’t thank us, thank FCK in Poland, we just maintain a solid WordPress port).

      What is missing with the shortcodes and code inside a fairly utilitarian textbox is true WYSIWYG. The only way to preview a post properly is to open it up with “View Post” and then reload the page to see any changes. This is slow and clunky.

      We’ve done what we can to improve WYSIWYG by in our editor by allowing with just the tiniest modification of your theme CSS real WYSIWYG. This only covers the CSS though and not the javascript or the short codes.

      What would make the WordPress editing experience amazing would be a live preview tab which turns the shortcodes and media into their visuals.

      We’ve looked long and hard at alternative edit experiences (updating FCK to CK was very hard and there aren’t really any world changing benefits: CKeditor is roughly the same experience albeit, better behaved on mobile). When we looked around at an editor to build for WordPress we settled on redaktor.js. Andrew Oz is very sceptical about Redaktor’s suitability for WordPress (licensing issues aside, just speaking technically):

      I like it too. However it’s far from being ready for anything more than
      comments/bbPress editor. Been following several jQuery based editors,
      all have little more than the default browser contentEditable functionality.

      This one is definitely more polished than most but still lacks a lot of
      things. For example: no plugins, no way to extend it other than hack
      into it, very minimal APIs, try copying and pasting something from
      another browser tab, then look at the HTML. And a big one: no undo/redo
      for all actions?

      I don’t know… Probably some will as it is nice. However considering
      the amount of work needed, not sure if that would be enough. Roughly it
      would take a good team of several full-time developers at least a year
      to bring it closer to TinyMCE.

      Nearly all JS editors get off the ground fast by adding UI to the
      browsers built-in contentEditable functionality. Once there, most try to
      tackle few more tasks and stop. The next step requires a lot of work:
      creating APIs, dealing with tons of browser quirks, etc.

      Currently there are several other editors at approximately the same
      stage. The problem is that a lot of the functionality for editing HTML
      should be in the browsers. It can be handles much better there than
      trying to extend the limited contentEditable mode with JS.

      So unless the browser vendors decide to sit down and make and implement
      a nice specification for editing of HTML, don’t see how this situation
      would change.

      We are a long way from 2012. Redaktor is awesome visually, very fast, beautiful preview, lightweight fast editing tools for media. In short everything we’d like the WordPress editing experience to be. In my opinion, TinyMCE will never have that shiny and fast and brilliant feel. It’s in neither the personality or the technology of the software.

      Alas Redaktor is not open source. A platform license would be $199. I’d happily pay it myself for WordPress but it cannot be as it’s against our community GPL principles.

      Perhaps there is something else out there which comes close and does have an open source license or at least a split license like CKeditor and FCKedit?

      That’s the holy grail. The same editing capabilities in the editor, legacy shortcodes but fast responsive and with **immediate full preview**.


      What we should avoid at all costs would be to deprecate shortcodes and create endless compatibility issues. Such a decision would cripple the platform and leave most of our shared library of powerful and obscure plugin obsolete.

      • chatmandesign 4:51 pm on January 18, 2017 Permalink | Log in to Reply

        I’m a big fan of CKeditor. It’s a popular enough option for this I have to assume the WordPress team already has reasons they haven’t adopted it so far, but it really seems like a perfect fit here:

        1) Available under GPL license.

        2) Includes built-in support for managing blocks of content.

        3) Extensible architecture supports plugins.

        4) Robust, battle-tested, actively maintained—and used by a host of major companies and projects, so it will likely stay that way.

        5) As an added bonus, it supports inline editing that could be integrated into the Customizer or some form of front end editor.

    • buzztone 11:45 pm on January 17, 2017 Permalink | Log in to Reply

      Really helpful overview – I look forward to following development of this project.

    • Joy 12:03 am on January 18, 2017 Permalink | Log in to Reply

      I agree with @FolioVision that shortcodes should remain intact, and would even go so far as to say that they should be the basis of content blocks. Why isn’t there a list of registered shortcodes available when editing a post? Why can’t the editor show the shortcode as a block with the parameters editable? Why wouldn’t the preview call do_shortcode() to show what that block looks like? And why can’t widgets be handled the same way, as part of the content?

      • Xavi Ivars 12:15 am on January 18, 2017 Permalink | Log in to Reply

        And that’s what (more or less….) Shortcake already does as a plug in: shortcodes can register UI to define how they should be edited, appear rendered in the WYSIWYG editor and in plain old-style text in the text editor

    • Weston Ruter 1:35 am on January 18, 2017 Permalink | Log in to Reply

      Thanks for the great writeup. I see a lot of alignments between this and the solutions being prototyped in the JS Widgets feature plugin. The plugin specifically aligns in terms of “the UI used to manipulate a block” and “the rendered output of the block”, leaving “the demarcation of the block” to encoding data via structured HTML/Microdata/comments. Likewise in:

      JavaScript is a natural technology to look at when it comes to the ability to manipulate and interact with content blocks, yet it may not be the best at all when it comes to rendering the final post to a viewer.

      The JS Widgets plugin specifically focuses on the use of JavaScript for managing the block’s attributes (widget instance) whereas by default PHP is used to render the block to HTML.

      WordPress needs to have a standard interface for how to define a block which can represent its state, present a UI for manipulating its state, and render its state onto a template. The widget provides such an interface, and with modernization and iteration I think the widget can serve as a standard interface for defining a block which can be used both in post content as well as in widget sidebars and elsewhere.

      Also, a general note that the JS Widgets plugin is focused on improving the WP_Widget API itself. It is not concerned with widget areas (sidebars) and thus is not focused on how widgets are managed in sidebars on the widgets admin page or via the widgets panel in the customizer. Rather, the plugin is about iterating on fundamental widget building block and allowing it as an interface to be leveraged and re-used in other contexts, such as to manage content blocks in the editor (as prototyped for the Post Elements in Shortcake). It’s also not concerned with the storage of widgets, as in the case of Shortcake post elements the instance data is stored as shortcode attributes, though the instance data could be stored as data-* attributes, inside of HTML comments, in HTML5 Microdata, and so on.

      • Matias Ventura 4:36 pm on January 18, 2017 Permalink | Log in to Reply

        Thanks! The stages I see us progressing from would be:

        • Define structure of post_content document that includes representation for both static and dynamic blocks.
        • Parsing of document on the fly to infer more manageable structure (JSON representation).
        • Implementation of general UI layer around manipulation and insertion of blocks.
        • The system to generate final output of dynamic blocks.

        Those last two could converge in a single API, but I think we’ll see if that’s the best path once we get closer to prototyping it.

    • Weston Ruter 1:47 am on January 18, 2017 Permalink | Log in to Reply

      Also, circling back to Twenty Seventeen and its “front page sections” feature (subset of #37974). There’s a lot of overlap between that proposed feature and nav menu items, as well as with widgets and blocks in the editor. I think it is key that we define a common interface that can be used in all of these contexts. The nav menu item in core could be re-implemented using a specific kind of such block, and the nav menu should be a block container just like a widget sidebar is a block container and the post content is a block container, though each may have restrictions on the kinds of blocks they allow. They should all re-use the same underlying block API which is a thing that has a set of attributes, a UI for managing them, and a method for rendering them onto a template.

    • dmccan 2:38 pm on January 18, 2017 Permalink | Log in to Reply

      Thank you for laying out the challenges and requirements. A couple of things came to mind:

      • While I think it is a good idea to limit the scope in order to set up a reliable foundation, there is value in identifying the types of ‘blocks’ that we might want to support in the future. Such a backdrop would be good before starting to iterate so that we know that an architecture is capable.
      • From a user perspective, the #1 shortcoming of the editor is the lack of true, easily editable columns. There are true (not shortcode) column solutions available for WordPress.
      • There are two dimensions: layout and content. From a layout perspective, ‘blocks’ are content that fits into rows and columns. In the requirements discussion, perhaps layout needs to be addressed.
      • In the Coda section you mention data attributes and HTML comments for demarcating blocks, what about divs with reserved class names? That is standards compliant. Bootstrap got a lot of mileage out of that approach.
      • Matias Ventura 4:24 pm on January 18, 2017 Permalink | Log in to Reply

        While I think it is a good idea to limit the scope in order to set up a reliable foundation, there is value in identifying the types of ‘blocks’ that we might want to support in the future.

        Definitely! Starting small should not stop us from considering if our solutions are a good fit for more complex blocks.

        I purposely left out layout considerations at this stage (including columns) because they are a bit ortogonal to the basic requirements here. It’s probably worth focusing on how to address layout in a separate instance, starting with the design goals for it. There are questions like «Do we have layout blocks (column, box) that hold child blocks?» or «Do you setup layout placeholder that you fill in or is layout a result of disposition of blocks?» that have their own complexities.

        > what about divs with reserved class names?

        This is partially questioned in ②. We should avoid creating spurious DOM nodes for the sake of representing “blocks”, unless the semantics of the document are improved by doing that. The requirement is about separating the demarcation of where a block begins from the markup of the block.

        The demarcation should be simple and consistent to allow easy parsing, but it should not pollute markup. For instance, the best representation of many blocks are native HTML elements and wrapping them in divs with classes would worsen the document representation (a paragraph, a blockquote, etc).

        Thanks for the thoughtful reply.

    • jhned 3:04 pm on January 18, 2017 Permalink | Log in to Reply

      Here’s how I currently put “blocks” in my page content: I use Advanced Custom Fields Pro to set up flexible content layouts, that are generated and appended to the post content using the `the_content` filter. The problem with that is that I end up with tons of post meta boxes on complicated pages, which slows editing down.

      I think the best way for us to achieve this idea is to go full front-end editor. Reason 1: tinyMCE is notorious for stripping out markup. Reason 2: editing on the front-end gives users an accurate view of how the “blocks” are going to look. Reason 3: the UI for each block could be focused on the data, and then silently insert any markup necessary in the background.

      In addition to your points, @matias, I would also suggest that we ought to create an API for developers to define custom blocks, much like how we have the Shortcode API.

    • davidperez 3:45 pm on January 18, 2017 Permalink | Log in to Reply

      Why don’t go to allow insert widgets inside content? Shortcodes are hard for users. With blocks of widgets are more intuitive and the user can set all fields needed for th block easily….

    • Mark Root-Wiley 4:29 pm on January 18, 2017 Permalink | Log in to Reply

      Just want to say that this is great and makes me feel much better about some of my concerns about the future of WordPress. Getting Portability and Semantic listed as top priorities is awesome! I also think that if the editor is truly going to get overhauled, following the WCAG Authoring Tool Accessibility Guidelines from the start should be a priority. I assume that as with most accessibility work, tacking it on afterwards will almost certainly be a nightmare while including it up front won’t just make the tool accessible but more usable.

    • chatmandesign 4:32 pm on January 18, 2017 Permalink | Log in to Reply

      It seems to me that associating editable blocks with chunks of editor content without mangling the “pure data” is essentially about how to best store metadata for those chunks. I think there are two good options:

      1) HTML data attributes. Storing metadata related to chunks of HTML is literally why they exist, so it seems like a pretty good option. The benefits here are that we’d be leveraging an existing standard, instead of creating something new where it may not be needed; it keeps the metadata with the data it belongs to; and is easily extensible without risking conflicts (providing name spacing is used). The only real downside, as you noted, is that it adds some cruft to the markup—however, a post_content filter could be added to remove editor-related data attributes in display contexts.

      2) Store editable block metadata in postmeta, associated with HTML elements by ID. Storing metadata about posts is the whole purpose of the postmeta table, after all. The benefits here are largely similar: we’d be leveraging an existing WordPress system, rather than trying to create something totally new, and it’s easily extensible with name spacing. The big difference is that the metadata is stored completely outside the content itself; I think whether that’s good or bad overall may be debatable, but one definite positive is that it adds no cruft to the markup (beyond IDs, which is pretty minimal), and no extra filtering step is necessary.

      I think the big question then is: how tightly coupled should the block metadata be to the blocks themselves? The answer depends how we’re going to use it. The implication in this post is that the post_content should be raw, valid HTML that’s ready for output without extra steps to generate content from it (unlike with the existing shortcode system), and I’m inclined to agree with that for static blocks. In that case the metadata is _only_ relevant to the editor, so I don’t see any benefit to keeping the metadata stored in the HTML itself. The HTML only needs to store the final result.

      If we want to support truly dynamic blocks that pull in current data from elsewhere without requiring a manual post re-save, there are more factors to consider. In that case, the data can’t really be stored in the post. These would require some processing to display, with the block metadata potentially pointing to an external data source. It’s not too much of a stretch to imagine that sensitive data like API keys might get stored in the block metadata by some plugins—I don’t think that would be best practice, but I could easily see it happening—which makes me think that in the case of dynamic blocks, storing the metadata in the HTML could increase the risk of unintended data leaks.

    • James Nylen 6:08 pm on January 18, 2017 Permalink | Log in to Reply

      Instead of `` I think the closing tag should be `` for clarity.

      Do we anticipate a need for these custom “tags” to be nested? This is probably something we should decide up front and either plan for, or prevent.

      • James Nylen 6:11 pm on January 18, 2017 Permalink | Log in to Reply

        WP ate my HTML comments… for clarity. Instead of !-- /wp -- it should be !-- /wp:image --.

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

        I think many of them will have to be nest-able, especially once we get into the customization and layout side of things.

    • Greg Ichneumon Brown 12:50 am on January 20, 2017 Permalink | Log in to Reply

      I think one other thing to add to the list is speed on the front end. We’ve seen many cases where just outputting the final rendered content (especially on APIs) means processing the post content with very large regexp logic (especially the shortcode logic) that then can make returning a dozen posts from an api take many seconds. Most of this was all CPU time. We’ve looked at caching and other options on WP.com, but they’ve been very complicated.

      In summary: performance is a feature, particularly of our APIs and it may be good to start testing that early on.

    • Dan Boulet 12:15 am on January 22, 2017 Permalink | Log in to Reply

      Just an idea: What if the definition of each “block” was declared using a CSS-like syntax (like [Emmet.io’s Abbreviations syntax](http://docs.emmet.io/abbreviations/syntax/)):

      `.gallery>figure.gallery-item>.gallery-icon>a>img.attachment-thumbnail^^figcaption.gallery-caption`

      The post content could be scanned for markup matching the pattern on the fly, and convert it to editable blocks within the editor.

      The same pattern could be used to generate the markup which is inserted when adding new blocks.

      This is probably a simplistic solution, but it offers a few big advantages:

      • No superfluous code in the markup. Simple and portable code.
      • What is saved in the database is exactly what will be used in the front-end, no additional processing required.
      • Backwards compatibility. A post written three years ago could suddenly contain editable blocks if its content includes markup which matches a block pattern.
  • Mel Choyce 4:59 am on January 17, 2017 Permalink |
    Tags:   

    Customization Meeting Notes: January 16, 2017 

    We had a meeting today in #core-customize to kick off the customization focus in 2017. Here’s a summary of what we chatted about:

      • Check out https://make.wordpress.org/design/2017/01/13/what-makes-a-great-customization-experience/ and https://make.wordpress.org/design/2017/01/11/what-makes-a-great-editor/ for some great discussion, and share your own thoughts.
      • What are your biggest customization pain points?
        • WordPress doesn’t help you setup your site according to your goals.
        • What’s a featured image? What’s a header image?
        • Moving (“dancing”) in and out of panels hunting for what you’re trying to edit is difficult.
        • Why can I click on one thing to edit it but not another thing?
        • User expectations from @ianstewart: https://wordpress.slack.com/archives/core-customize/p1484590206000728
        • If you can’t see it, how can you edit it?
        • We need an improved flow for content editing as part of customization that better ties that together with the surface-level tools.
        • Moving, adding, and deleting chunks of content and “features” in a design should be possible.
      • What if the customizer panel is blank, and stuff shows up only when the user clicks something in the preview? Would they be able to do everything they need?
        • We made a step towards this with Edit Shortcuts in 4.7.
        • But, Edit Shortcuts is a bandaid.
        • Need a balance of contextual tools and global controls.
      • How many tickets can we close by iterating on a whole flow?
      • What are the drawbacks of direct manipulation?
        • (Direct manipulation = I see it, I tap/click it to edit.)
        • Focused on what you see in front of you right now, rather than your whole site across multiple screen sizes.
        • It’s easy to mess up the site layout and design if you can control everything.
          • This is where “undo” could be handy.
          • Hard to tell if you’re customizing something locally or something globally.
        • Should we separate content, layout, and design?
      • @karmatosed is going to be leading user research and testing:
        • Have a series of posts on here on make/design asking for input, focusing on how people are using the Customizer to build sites for themselves and for clients.
        • Have people test the Customizer and report bugs to Trac.
        • Frequent Trac triage of Customization component.
        • Have a public “call for testing” for every new feature or flow iteration. Would be good to integrate these into local WordCamps and meetups as well.
      • We need to continue working on the technical architecture of the Customizer in preparation for future features and customization flows:
        • Changesets: #31089.
        • REST API for Changesets: #38900.
        • Customize Snapshots: GitHub PR.
        • Bigger features we know we want to support in the future need to be scoped and architected now, while we’re designing, so they’re ready to be implemented later.
          • I think it’s important to identify the big picture technical stuff, the things we’ll know we need for sure to support implementing the fuzzy design that will come clearer into view. It will take many months to implement. We can’t wait for design to be “finished” before we start development. It needs to be iterative. — @westonruter
      • Potential wins in the 3 months?:
      • Many of the features and flows we want to build out in the future (drafting changes, revisions, content blocks) need to be worked on in collaboration with the Editor team.

    We also continued the discussion past the meeting time. The conversations were a bit too long to summarize, but you can catch up starting here.

    If you’re interested in getting involved, please add your input to the “What makes a great customization experience?” thread and join us in Slack.

     
  • Jeffrey Paul 11:50 pm on January 16, 2017 Permalink |
    Tags: , , ,   

    Dev Chat Summary: January 11th (4.7.1 week 5) 

    This post summarizes the dev chat meeting from January 11th (agendaSlack archive).

    4.7.1 Update

    2017 Release Schedule

    • 4.7.1 will NOT be last in the 4.7 branch, so it’s best to start on anything that needs to go in 4.7.2 immediately
    • Proposal from @samuelsidler:
      • Since we don’t have a set release date for WordPress 4.8, I’d like to propose we look at applicable 4.7.x issues about once a month, and decide if we should ship a release.
      • For 4.7.2, I think we should take a look at issues at the beginning of February, during devchat, and decide if the issues warrant a release, then ship about a week later.
      • That would mean we’d be looking at a release around February 14, but we’d update the schedule after looking at the specific issues.
      • We’d want to evaluate issues the week of February 6 and make a call.
      • I think we said regressions and minor bug fixes are okay in 4.7 at the moment, but we can evaluate other fixes on a case-by-case basis.
    • General agreement on approach, though date for 4.7.2 to be confirmed in February
    • Plan to choose someone soon to lead 4.7.2, maybe at or before next week’s devchat, to keep things moving along. @jnylen0 @aaroncampbell @voldemortensen @swissspidy interest in leading that or future releases. If you have interest, ping @samuelsidler as he’s compiling a list of those interested.
    • @davidakennedy: I’d imagine we’ll package up default theme updates more in minor release. Though, we can also release those whenever to .org. I’d like to think through a schedule for that. Maybe looking at things monthly, and making a decision.

    Trac Tickets

    • #39309: Secure WordPress Against Infrastructure Attacks
      • @paragoninitiativeenterprises: propose making it a point of focus for 4.8
      • @aaroncampbell: may not fit as a focus for 4.8, since those should be in the editor, customizer, and API areas. But good to talk about and try to figure out steps forward.
      • @paragoninitiativeenterprises: recommend against punting too far into the future
      • @samuelsidler: let’s think through how to implement it and work on patches for that, then decide which release to put it in
      • @westonruter: Security and performance hardening are ongoing and not limited to focuses
      • @paragoninitiativeenterprises: would like to see this land ASAP, will work on a patch with necessary tests and any necessary back-compat and post to the ticket
    • #38418: Add telemetry (aka usage data collection) as opt-in feature in core)
      • @lukecavanagh: thoughts from the group?
      • @brechtryckaert: personally in favor of usage data collection, but we’ll need to be very upfront about it upon release to avoid criticism; also worried what the impact would be on loading times/slowdown due to communication with the servers that store the data, would all depend on the way it’s implemented.
    • #39157: Feed returns 404 when there are no posts
      • @stevenkword: looking for feedback on approach on adding new conditionals and what to do now. Issue was addressed in 4.7 but caused a regression and code was reverted for 4.7.1.  After 4.7.0 landed, before the reversion, an updated patch was committed that resolved the regression, but it introduced new getters to WP_Query.
      • @stevenkword: would like to find a resolution for this for 4.7.2, but need some opinions how to solve it.
      • Will ping @peterwilsoncc and @dd32 to look at it
     
  • Andrew Rockwell 8:42 pm on January 14, 2017 Permalink |
    Tags: ,   

    Week in Core, January 4th – 10th, 2017 

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

    • 93 commits
    • 35 contributors
    • 100 tickets created
    • 8 tickets reopened
    • 80 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

    • Docs: Remove incorrect @param tags for admin_print_footer_scripts-{$hook_suffix} and admin_footer-{$hook_suffix} dynamic actiona. [39755] #39527

    Build/Test Tools

    • Build: Update pinned version of grunt-cssjanus for the 4.0 branch to hopefully please the build. [39747-39748] #29038

    Bundled Theme

    • Twenty Seventeen: Expand a changelog entry added in [39742] with the new item name. [39752] #39489
    • Twenty Seventeen: Correct @param entries for twentyseventeen_content_width, twentyseventeen_custom_colors_saturation and twentyseventeen_social_links_icons filters. [39733] #39488
    • Twenty Seventeen: Correct @param entry for twentyseventeen_front_page_sections filter. [39732] #39488
    • Twenty Seventeen: Introduce a theme-specific filter twentyseventeen_starter_content for customizing the starter content array. [39720] #39109
    • Upgrade: Fix the installation of TwentySeventeen upon upgrade from an early version. [39687] #38551, #30799, #39138

    Comments

    • Docs: Use correct closing tag in submit_field description in comment_form(). [39753] #39508

    Customize

    • Correct a comment in get_theme_starter_content() added in [39561]. [39751] #39104
    • Docs: Correct @access entries and duplicate hook references in WP_Customize_Selective_Refresh. [39734] #39501
    • Prevent removal of underline upon hover/focus for nav menu deletion links. [39696] #37527, #39444
    • Remove extra left padding in core for site title and widgets in preview. [39695] #38651, #39349
    • Ensure theme_mod-cache of custom_css lookup of -1 short-circuits a WP_Query from being made. [39694] #35395, #39259
    • CDon’t query for postmeta for Custom CSS (for not-current-themes) and Customizer Changeset posts. [39692-39693] #39194
    • Ensure theme_mod-cache of custom_css lookup of -1 short-circuits a WP_Query from being made. [39688] #35395, #39259
    • Update customize.php URL with changeset_uuid param the instant a change is made instead of deferring until the changeset update request responds. [39686] #39227
    • Remove extra left padding in core for site title and widgets in preview. [39685] #38651, #39349
    • Prevent removal of underline upon hover/focus for nav menu deletion links. [39677] #37527, #39444
    • Docs: Correct @access tag for WP_Customize_Partial::id_data property. [39674] #39464
    • Docs: Add missing @since and @access tags for WP_Widget_Form_Customize_Control::to_json() and ::render_content(). [39673] #39463

    Database

    • Docs: Move install_network() DocBlock after the function_exists() call. [39709] #39478

    Editor

    • Docs: Use 3-digit, x.x.x style semantic versioning for @since entries in wp-admin/js/word-count.js. [39739] #37718
    • Docs: Add documentation for wp-admin/js/editor.js. [39738] #38933
    • Always add page-template-default class to the editor body when the template is not specified. This matches the behavior on the front-end. [39678-39679] #39368

    External Libraries

    Feeds

    General

    • Docs: Add missing @since entry for Walker::unset_children(). [39741] #39506
    • Update copyright year to 2017 in license.txt. [39698-39707] #39433
    • Docs: Correct rest_insert_* duplicate hook references in REST API. [39671] #39371
    • Docs: Add missing session_token_manager duplicate hook reference in wp-includes/class-wp-session-tokens.php. [39670] #39371
    • Docs: Correct comment_email duplicate hook reference in wp-admin/includes/class-wp-comments-list-table.php. [39669] #39371
    • Docs: Add missing duplicate hook references in wp-admin/includes/ajax-actions.php. [39668] #39371

    I18N

    • Docs: Correct @access entries for WP_Locale::init() and WP_Locale::register_globals(). [39737] #39504
    • Add post type context to “Featured Image” post labels. [39667] #39458

    Mail

    • In PHPMailer 5.2.7 the case of the Send() method changed to send(), update our call for consistency with the library. [39691] #39469

    Media

    • Docs: Use 3-digit, x.x.x style semantic versioning for @since entries in wp-admin/js/image-edit.js. [39740] #38748

    Menus

    • Posts, Post Types: Add a @since entry for archives post type label introduced in [35382]. [39666] #16075

    Misc

    Options, Meta APIs

    • Docs: Add variable to @param entry for whitelist_options filter. [39708] #39477

    Posts, Post Types

    • Use an existing string for “Invalid post type” error message. [39756] #39171
    • Docs: Add missing @param tag for show_post_locked_dialog filter. [39710] #39479

    Query

    • Docs: Add missing @since and @access tags for WP_Date_Query::is_first_order_clause(). [39672] #39462

    REST API

    Security

    • Docs: Make @deprecated entry for wp_kses_js_entities(), deprecated in [38785], consistent with other entries. [39758] #39541

    Taxonomy

    • Docs: Correct @since and @access tags for WP_Term_Query::get_terms() and WP_Term_Query::parse_orderby_meta(). [39675] #39467

    Themes

    • Docs: Add missing @since entries for WP_Theme class methods. [39736] #39503
    • Docs: Correct the DocBlock for get_header_video_url(). [39676] #39468

    Upgrade/Install

    • Docs: Move install_global_terms() DocBlock after the function_exists() call. [39754] #39526
    • Avoid creating nonce during installation. [39697] #39047
    • Updates: Properly define $filesystemForm to handle error in modals. [39689-39690] #39057
    • Avoid creating nonce during installation. [39684] #39047

    Users

    • Docs: Change @param type for $user_object in WP_Users_List_Table::single_row() from object to WP_User to be more accurate. [39757] #39536
    • Docs: Correct @access entry for WP_User::filter property. [39735] #39502, #39278

    Thanks to @ocean90 @Presskop, @aaroncampbell, @adamsilverstein, @asalce, @azaozz, @BharatKambariya, @celloexpressions, @chiragpatel, @dd32, @dlh, @ireneyoast, @Jaydeep Rami, @karmatosed, @keesiemeijer, @ketuchetan, @michalzuber, @monikarao, @Nikschavan, @nullvariable, @pento, @priyankabehera155, @prosti, @ramiy, @rmccue, @sanket.parmar, @sebastian.pisula, @SergeyBiryukov, @sirbrillig, @stevenkword, @teinertb, @terwdan, @timph, @truongwp, and @westonruter for their contributions!

     
  • Felix Arntz 11:22 am on January 11, 2017 Permalink |
    Tags: , , ,   

    Controlling access to REST API user functionality for multisite 

    Following last week’s discussion in #core-multisite (read the recap) this week’s office hours agenda was to continue the chat about the multisite-related enhancements for the REST API users endpoint, focussing heavily on how to access the required functionality. Here is a wrap-up of the discussion.

    Chat log in #core-multisite

    Attendees: @jeremyfelt, @jnylen, @nerrad, @ipstenu, @earnjam, @kenshino, @maximeculea, @mikelking, @lukecavanagh, @flixos90

    Now that the way on how one should be able to modify user roles per site was clarified last week, this week the focus laid on where one should be able to perform those actions. The current state of the wp-json/wp/v2/users endpoint in multisite is:

    • The users overview accessible with a GET request to wp-json/wp/v2/users only lists users that are part of the current site.
    • When creating a user with a POST request to wp-json/wp/v2/users, that user is created and added to the current site. When providing the roles parameter, the passed roles are added to the user, otherwise the user will still be part of the site, but without any role. See #38526 for background.
    • It is possible to both read and edit any user from any site with a request to wp-json/wp/v2/users/<id>, regardless of whether the user is part of that site.
    • A DELETE request to wp-json/wp/v2/users/<id> results in an error. See #38962 for background.

    After the discussion about how to be able to add a specific user to a site, update their site capabilities and remove them from a site, this week’s chat revolved around where these actions can be accessed, as they are for the most part network-specific actions not available to a site administrator. The approach that was agreed on is:

    • The users overview at wp-json/wp/v2/users should continue to only show users of that site by default, but a request like wp-json/wp/v2/users?global=true should show all users in the WordPress setup. This parameter must only be available to network administrators though, more specifically users with the manage_network_users capability. In the future a network parameter might also be introduced for support of multi networks, but at this point core does not support querying users per network. Accessing global users should be available from all sites in a setup instead of only from the main site. While this approach makes these endpoints duplicates of each other, it has several benefits like preventing the requirement for cross-domain requests, allowing easier API discovery and not requiring the main site of a setup to be exposed to REST API calls to a sub site.
    • Assigning an existing user to a site and removing a user from a site should generally be only available to network administrators, and the site administrators of the site that is being interacted with.
    • Similarly, editing a user that does not belong to the current site should only be possible for a network administrator. Currently this is available to site administrators as well which is probably wrong.
    • Deleting any user completely should only be available to a network administrator. A good way to handle the reassign parameter needs to be found though.

    Before coming to the conclusion that dealing with multisite functionality at the existing users endpoint, the possibility of introducing a multisite-specific endpoint only available on the main site was discussed. However this was considered not practical due to the nature of how users work in WordPress. Having separate endpoints for other network-wide functionality might still be a possibility though as long as that component solely affects the network admin, so this idea is something to keep in mind for thought about further network functionality endpoints in the future.

    Back to the users endpoint, one related question that came up is:

    • Should the sites a user belongs to be available at the wp-json/wp/v2/users endpoint or at a future wp-json/wp/v2/sites endpoint? If they were available in the wp-json/wp/v2/users endpoint, every user entity would have a new sites key available if the current user had sufficient permissions to see these. If they were available in the wp-json/wp/v2/sites endpoint, that endpoint could easily support this functionality through usage of a user parameter.

    @jeremyfelt suggested to look at the “Add New User” screen in the site admin to have a good use-case for how to scaffold the multisite functionality of the API endpoint. This has helped during this week’s office-hours and can also be beneficial in the future. Eventually this screen should be revamped entirely, being powered by the REST API.

    Regarding the enhancements of the users endpoint, a general ticket for this task was opened at #39544. This ticket is meant to be used for discussion on the topic, while separate smaller tickets should be opened for actually implementing the individual pieces. For now feedback is welcome on that ticket. The discussion on multisite improvements for the REST API will continue at Tuesday 17:00 UTC.

    /cc @rmccue and @kadamwhite

     

     

     
    • James Nylen 6:40 pm on January 11, 2017 Permalink | Log in to Reply

      Excellent writeups and discussion, thanks Felix and everyone else involved.

      > It is possible to both read and edit any user from any site with a request to wp-json/wp/v2/users/, regardless of whether the user is part of that site.

      I think this should require the new `global=true` parameter as well. This is a change we would need to make sooner rather than later, in 4.7.2.

      • Felix Arntz 8:02 pm on January 11, 2017 Permalink | Log in to Reply

        I agree, however I think we should be fine by prohibiting access to users that are not part of the site as that would be the fix for the current bug. Adding the `global` parameter can happen in 4.8 IMO, as we only start supporting multisite behavior there in general.

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