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

  • Morgan Estes 2:32 am on October 1, 2016 Permalink |
    Tags: , ,   

    Docs Bug Scrub this Weekend 

    Join @morganestes in the #docs channel in Slack on Sunday, Oct. 2, 2016 3:30 p.m. CDT for a docs-focused bug scrub. We’ll plan for an hour of gardening fun. See you there!

     

  • David A. Kennedy 10:40 pm on September 30, 2016 Permalink |
    Tags: , ,   

    Twenty Seventeen Meeting Notes: Sept. 30 2016 

    Here’s the meeting summary for this week. If I missed anything, let me know in the comments.

    Housekeeping

    Summary

    The group:

    • gave an update on the theme’s progress. Lots of PRs merged this week, plus the design implementation should be done early next week. From @laurelfulford: “I’m aiming for Monday at the latest to have the design PR ready to merge. There will still be minor issues, but it’s at the point where it’ll benefit from everyone else’s eyes.”
    • labeled a handful of issues on GitHub that hadn’t been triaged yet.
    • discussed issue on fonts and non-latin fallbacks. It now has a list of alphabets the theme aims to support. Next steps include coming up with font stacks for each choice and figuring out implementation strategies.
     

  • K.Adam White 9:31 pm on September 30, 2016 Permalink |
    Tags: ,   

    REST API: Agenda for October 3, 2016 Meeting

    The weekly meeting for the API team will be on Monday at 2016-10-03 14:00 UTC in #core-restapi. On the agenda:

    • Update on Settings from @joehoyle
    • Update on Meta from @rmccue
    • 4.7 Merge Plan TODOs

      • Decision on supported authentication methods
      • Progress on outside review
      • Timeboxed open floor
    • Review open PRs
    • Find owner for open tickets, e.g. some OAuth/Cookie conflicts
     

  • David A. Kennedy 2:24 pm on September 30, 2016 Permalink |
    Tags: , ,   

    Twenty Seventeen: Agenda for Sept 30, 2016 Meeting 

    Here’s the agenda for today’s weekly meeting on Twenty Seventeen. It will last 30 minutes, and I’ll be around in the #core-themes channel for at least 30 minutes afterward to answer any questions.

    Reminder: Meetings are every Friday at 18:00 UTC. Twenty Seventeen Features meeting every Tuesday at 17:00 UTC.

     

  • Jeff Paul 8:37 pm on September 29, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: September 28 (4.7 week 6) 

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

    Reminders

    • Schedule: We are 3 weeks from the final chance to merge in major features. This includes Twenty Seventeen.
    • Tickets: There are currently 196 tickets in the 4.7 milestone. This is 14 more than last week. In just 6 short weeks, this needs to be zero. For any tickets you’ve moved into the milestone, please make sure these are active tickets, with some kind of activity in the last 10 days.
    • Bug Scrubs: We’re looking for people to help run a bug scrub, please reach out to @jorbin if you have interest (details here). Bug scrubs this week plus one on Monday and one on Wednesday next week at yet to be scheduled times.

    Components & Features

    • Twenty Seventeen (@davidakennedy, @melchoyce)
      • Latest update
      • Add multi-panel feature to pages through add_theme_support (#37974) & Enable Video Headers in Custom Headers (#38172) need eyes and help the most
      • Additional i18n eyes on Better support for non-latin font fallbacks especially designers who use non-latin alphabets natively to hear suggestions for non-latin font stacks that would look good in the theme
      • Next meeting Friday at 18:00UTC (theme-focused), Tuesday (feature-focused)
    • Media (@mikeschroder, @joemcgill)
      • Latest update
      • Unexpected change to media title behavior in WP 4.6.1 (#37989) – Looks like @sergey added a patch that fixes the remaining issues with some UTF-8 characters. Should be committed soon.
      • Media search doesn’t include file name (#22744) – The current implementation is trampling any preexisting JOINs. Should have a patch a new patch ready to test soon.
      • Also looking at pursuing additional media organization improvements through a feature plugin, details still need discussion, @karmatosed on board to help with design
      • Next meeting Friday at 17:00 UTC
    • Customize (@westonruter, @celloexpressions)
      • Latest update
      • Primary commit for Harden panel/section UI code by removing contents from being logically nested (read: goodbye margin-top hacks) (#34391) is in, and a dev note is scheduled to be published after today’s dev chat
        • Some major changes here, so we need plugin and theme authors to test
      • Received design feedback on A New Experience for Discovering, Installing, and Previewing Themes in the Customizer (#37661) and working on making those revisions by the end of this week and planning to publish a feature proposal on Friday
        • Need to discuss themes again during tomorrow’s #design meeting for final approval before the changes are made
      • Need attention on Provide a better gateway for code-based theme customizations with the Customizer (#35395)
        • Discussion of whether this direction is appropriate lead to tentative consensus that this is likely appropriate for core
        • Next steps will be to loop @folletto in to improve the design and polish up the patch
        • Big other block discussed: sanitizing and validating the CSS & most appropriate corresponding capability
          • Currently rudimentary validation in the patch for balanced braces and comments. Need improvement if relying on it heavily, but it provides instant user feedback
          • Capability solution needs to work for multisite if at all possible, since that’s a primary use case
          • Discussion to continue on the Trac ticket and/or #core-customize
    • i18n (@swissspidy)
      • Feedback/help on Introduce a locale-switching function (#26511) would be appreciated
        • The problem is that labels of custom post types and taxonomies are only evaluated once, so switching locales wouldn’t properly translate those.
        • There’s a proposed fix for built-in types and taxonomies, but we prefer a better solution that works for all of these.
    • Editor (@azaozz, @iseulde)
      • Would like to help with a survey (scratchpad/draft). Need to start gathering user usage stats, should be opt-in, start with a plugin first, and release the aggregated data
      • Weekly data tracking (back-end) meeting Wednesday at 1900 UTC
    • HTTPS (@johnbillion)
    • REST API (@krogsgard, @kadamwhite )
      • Latest update
      • Whether the API should follow core behavior and save a revision every time a post is updated
        • Right now every update to a post creates a revision and can be a bit painful for some clients, so: 1) should that always happen? 2) should we have the ability to turn it off?
        • Decided on: 1) Yes.  2) The ability to use auto-drafts like in core makes sense, but doesn’t need to block merge.
      • How to handle image permissions, specifically for the case where an image is attached (uploaded) to a private post and then featured in a public post
        • Specifically, if I upload an attachment to a private post, its visibility is governed by that post, so it too is private but, in wp-admin I can add it as featured media to another public post. When that public post is queried: what happens!?
        • @joemcgill summary: I happen to think it’s an oversight in WordPress that we allow an image attached to a private post to be set as the featured image of another post (and by an author without permission to view the private parent post). We should probably either close this loophole or detach the attachment from the private post whenever it’s set as a featured image on another post.
        • @kadamwhite to document decision, @rmccue @joemcgill @helen et al will identify core tickets that should be opened.
      • Whether (and how) to expose edit locks through the API
        • Main thing here is whether this is a blocker? Decision: edit locks are great, but doesn’t need to block merge.
      • Next bug scrub is Thursday 1400 UTC; next team meeting is 1400 UTC on Monday, October 3rd
     

  • John Blackbourn 8:30 am on September 29, 2016 Permalink |
    Tags:   

    Reminder: HTTPS meeting tomorrow 

    The weekly meetings about HTTPS improvements in core will resume tomorrow at 16:00 UTC (Friday, September 30, 2016, 16:00 UTC) in the #core-http channel on Slack. See you there!

     

  • Piotr Delawski 10:00 pm on September 28, 2016 Permalink |
    Tags: , ,   

    Changes to Customizer Sliding Panels/Sections in WordPress 4.7 

    Several updates to the customizer’s sliding panels/sections implementation are going to be introduced in WordPress 4.7. The changes are now available in trunk, so you can test them with existing themes and plugins. It is worth noting that all instances of custom sections and panels in the WordPress.org plugin and theme repositories were checked by @celloexpressions. No conflicts were found, but still testing is advised.

    tl;dr – The Solution

    The root “panel” of the customizer (the links to the panels and panel-less sections) is now logically independent in the DOM from the panels and sections it links to, and likewise the links to sections within a panel are disconnected in the DOM from the container elements for the sections they link to. By keeping these separate, no margin-top hacks are needed anymore: the panel/section to be shown simply needs to be positioned to the top of the customizer pane. This also means accessibility hacks which set the root of the customizer to visibility:hidden but a nested child element to visibility:visible are not needed anymore (see #33258). To maintain the accessibility benefit that came “for free“ with the previous nested hierarchical unordered list, aria-owns property has been implemented to relate the panel/section links with the panel/section containers they link to.

    For more context, please refer to the original ticket: #34391.

    The patch should also fix related issues: #34344, #35947.

    Flat Panels/Sections Structure

    So far panels and sections markup was nested inside one huge ul list inside the customizer pane.

    <div id="customize-theme-controls">
  <ul>
    <li id="accordion-section-foo" class="accordion-section control-section...">
      <h3 class="accordion-section-title">...</h3>
      <ul class="accordion-section-content...">
        <li class="customize-section-description-container">...</li>
        <li class="customize-control customize-control-text">...</li>
        ...
      </ul>
    </li>
    <li id="accordion-panel-bar" class="accordion-section control-section control-panel...">
      <h3 class="accordion-section-title">...</h3>
      <ul class="accordion-sub-container control-panel-content">
        <li class="panel-meta accordion-section...">...</li>
        <li id="accordion-section-baz" class="accordion-section control-section control-subsection">...</li>
      </ul>
    </li>
  </ul>
</div>

    With #34391 being merged each panel/section content element is detached from the root “panel” and appended to the parent container #customize-theme-controls right after the root list.

    <div id="customize-theme-controls">
  <ul class="customize-pane-parent">
    <li id="accordion-section-foo" class="accordion-section control-section..." aria-owns="sub-accordion-section-foo">
      <h3 class="accordion-section-title">...</h3>
    </li>
    <li id="accordion-panel-bar" class="accordion-section control-section control-panel..." aria-owns="sub-accordion-panel-bar">
      <h3 class="accordion-section-title">...</h3>
    </li>
  </ul>
  <ul id="sub-accordion-section-foo" class="customize-pane-child accordion-section-content accordion-section control-section...">
    <li class="customize-section-description-container">...</li>
    <li class="customize-control customize-control-text">...</li>
    ...
  </ul>
  <ul id="sub-accordion-panel-bar" class="customize-pane-child accordion-sub-container control-panel-content accordion-section control-section control-panel...">
    <li class="panel-meta accordion-section...">...</li>
    <li id="accordion-section-baz" class="accordion-section control-section control-subsection" aria-owns="sub-accordion-section-baz">
      ...
    </li>
  </ul>
  <ul id="sub-accordion-section-baz" ...>
    ...
  </ul>
</div>

    A few additional notes:

    • New getContent() method of the Container class has been introduced.
      • It is responsible for the actual detachment of the content element (usually ul).
      • It should be overridden in the custom sections and panels if it makes more sense to not detach the content element from the parent and keep it nested.
      • It should also be overridden if custom expanding logic is used (e.g. ‘New Menu’ section in the Core).
    • New Container class properties are now available:
      • headContainer is a jQuery object containing the parent element (usually the li). So far the same object was kept in the container property.
      • contentContainer is a jQuery object containing the child element (usually the ul).
      • container is now a jQuery object with two members: headContainer and contentContainer. This way the backwards-compatibility is improved, as any jQuery methods working on a set of elements like find() or on() should still work with the container as before.
    • CSS classes that were possessed by the parent element are copied to the child container, which also is a way to improve the backwards-compatibility.
    • In order to keep logical relationship between the parent and the child elements (which no longer can be determined naturally from the HTML structure), the parent element has new aria-owns property. It lists all children elements of the container.
    • _recalculateTopMargin() method was dropped completely, as it is no longer relevant.

    I highly encourage developers who have done any JS/CSS-heavy work with the customizer’s panels/sections to review the changes introduced by #34391 and test them with themes and plugins.

    Transitioning translateX() Instead of left

    Along the update to the inner structure of the panels/sections, the user experience of sliding panels has been improved. Now instead of transitioning left position of the container, translateX() is used. It makes the animation smoother and more performant.

    • A busy class has been introduced. It is added to the panels/sections that are going through CSS transition at a given moment.
    • The busy class is added and removed in the Container‘s new method: _animateChangeExpanded( completeCallback ). The method takes care of detecting if transitions are supported by the browser, initiating the transition and listening for normalised transitionend event. It takes one parameter, completeCallback, which is called when the transition is complete.

    I hope that working with customizer’s sections and panels will be easier and more reliable with the new structure. If you find any bug related to the update, feel free to add a comment here or directly in the Trac ticket: #34391.

     

  • Helen Hou-Sandi 7:04 pm on September 28, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for September 28 (4.7 week 6) 

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

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

     

  • David A. Kennedy 10:50 pm on September 27, 2016 Permalink |
    Tags: , ,   

    Twenty Seventeen Features Meeting Notes: Sept. 27 2016 

    Here’s the meeting summary for this week. If I missed anything, let me know in the comments.

    Housekeeping

    Summary

    The group:

    • Discussed #37974 and what the options were for possible implementation. Those include: theme options, nav menus and child pages.
    • Mostly agreed that nav menus had a lot of positive things that could be inherited for this feature. Beside a familiar UI, the internal data structure is solid and flexible for future changes and growth, and there are several ways to improve the experience to make it more discoverable, such as with menu fallbacks in the customize preview.
    • Talked about “fragments” and how this feature might work when a full page is assembled via those fragments. The fragments wouldn’t be viewable on their own.
    • Talked about how child pages are grouped together on the edit screen but don’t have good UI for page structure management.
    • Mentioned theme options and how many themes do this kind of thing now, but it lacks portability and themes can do it in many different ways.
    • Talked a bit about how themes might output the assembled content. Maybe it uses a version of the_content().
    • Noticed that drag and drop ordering came up a lot – especially in relation to concepts users get in menus and widgets.
    • Brought up the idea of adding other pages’ content inside a page. Pages in a page. But that could be getting too far into content block territory.
    • Shared ideas about where this might live: in the edit screen, the Customizer or a combination.
    • Decided to have @karmatosed sketch out some of these ideas. Others are welcome too!
    • Brought up video headers, #38172, to get more eyes on it.
    • Discussed dummy content, #38114, after the official meeting. Chat archive starts here.
    • Talked about a potential direction for dummy content that’s showing it when live previewing, using JSON as a potential format and having a set of dummy content in Core that themes could utilize.
    • Decided to research what type of content themes might need. It may be smart to divide content by theme types.
     

  • K.Adam White 5:30 pm on September 27, 2016 Permalink |
    Tags: , ,   

    API Team Update 

    API Team Update Sept. 27 2016

    The API team met yesterday on slack for our weekly update, which this week was predominately focused on follow-up from last Thursday’s comprehensive GitHub issues scrub.

    Since the previous API team update the group has been making steady progress through the gameplan outlined in that post. To give a quick update on a few key “quirky” issues that had been identified:

    Password-Protected Posts

    As noted in last week’s dev chat, password-protected posts will be included in collections with their content set to '', and the content can be viewed by passing ?password=XXXXX as a query or GET parameter when querying for a specific post. Query parameters are not an ideal solution: Authorization headers are out because you can’t have multiple authorization schemes in one request; cookies don’t afford enough control to browser clients, and custom headers aren’t respected by caches. See GH issue #2701 for more background, and check out the open pull request to review the specifics of the implementation.

    Sticky Posts

    After much debate there is now a path forward for handling sticky posts as well. Following this open pull request, sticky posts are included in the /wp/v2/posts collection, but are not given special treatment in terms of ordering—a sticky post will, by default, be displayed ordered by date or whatever orderby has been set for the request. The parameter ?sticky=true may be passed to return only sticky posts; ?sticky=false may be passed to exclude sticky posts from the response.

    There is ongoing discussion around how the API could surface posts in the “normal loop order,” with stickies on top, followed by non-sticky posts. @jorbin will propose a follow-up enhancement that could be added in to the API in a later cycle. See GH issue #2210 and associated slack discussion for more commentary.

    Meta Support

    A pull request is open on the API meta endpoints repository to add support for registering meta with the API using the main register_meta function. This PR includes a comprehensive readme explaining how meta handling works. Once merged & reviewed, this functionality will be PR’d against the primary REST API plugin repository.

    Site Settings (Options) Support

    A pull request has merged into the API site endpoints repository which adds support for accessing and manipulating site settings through the API. These endpoints will be PR’d against the core REST API plugin repository this week.

    Discussion items for 9/28 dev chat

    This project is not quite done yet, and in tomorrow’s dev chat the API team will be looking to the broader WordPress team for input on three priority issues that need a decision:

    Upcoming Meetings

    Please join us in #core-restapi on chat.wordpress.org for our next two group meetings:

     

← 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