WordPress.org

Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

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

    Week in Core, Jan. 19-26 2016 

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

    • 55 commits
    • 44 contributors with props
    • 99 tickets created
    • 10 tickets reopened
    • 86 tickets closed

    Ticket numbers based on trac timeline for the period above.

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

    Code Updates

    Accessibility

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

    Cache API

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

    Comments

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

    Customizer

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

    Documentation

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

    Editor

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

    Emoji

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

    I18n

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

    Media

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

    Multisite

    Plugins

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

    Query

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

    Quick/Bulk Edit

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

    Posts, Post Types

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

    Taxonomy

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

    Themes

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

    TinyMCE

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

    Upgrade/Install

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

    Widgets

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

    Props

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

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

    Shiny Updates v2 

    Shiny Updates v2

    What is Shiny Updates?

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

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

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

    What does it do?

    The shiny updates plugin currently enables the following features:

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

    What is still being worked on?

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

    How can I help?

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

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

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

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

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

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

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

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

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

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

  • George Stephanis 3:16 pm on January 27, 2016 Permalink |
    Tags: ,   

    The Two-Factor Plugin is currently on a brief hiatus, while we work on splitting off it’s Application Passwords feature into a smaller, solo feature plugin.

    https://github.com/georgestephanis/application-passwords/

    Application Passwords was initially a sub-feature of Two-Factor Authentication, but due to the fact that we had very little confidence in Two-Factor being ready for the 4.5 cycle, we spun off a nearly-complete sub-feature that may mesh very well with the existing REST API.

    Application Passwords lets each user choose to generate “Application Passwords” — randomly generated 16-character alphanumeric codes, that are only displayed to the user once, upon creation. These passwords can be revoked either individually or all at once, and track usage, so in the admin UI you can view the most recent IP and Date that the password in question was used.

    The passwords are only valid for non-interactive prompts. That is, for use with our XML-RPC and REST APIs. They can not be used on `wp-login.php` or to access the admin panel. The idea is that each application you connect to your WordPress account — a mobile app, if this then that, Microsoft Word, or some sort of local blogging software, they all have their own password that can be revoked if the device is lost or no longer in usage, all without dispensing full access to your account.

    For folks building a quick one-off script that needs to tie into WordPress, this is far simpler than using the obscure oAuth version that Core has to use because we can’t guarantee HTTPS, and far more secure than the existing “use your account password for api calls” standalone plugin, that many folks would likely choose to default to otherwise.

    Screen Shot

    Code reviews, issues, and pull requests are very welcome.

     
    • Mikel King 3:53 pm on January 27, 2016 Permalink | Log in to Reply

      Awesome thanks for this!

    • Laurens Offereins 4:29 pm on January 27, 2016 Permalink | Log in to Reply

      Interesting. Am I wrong to say this is like GitHub’s access tokens? Would this be useful for, let’s say, making user-specific RSS feeds, allowing private posts in the feed? I’ve for long wanted a unified interface for creating user-specific access keys.

      • George Stephanis 8:33 pm on January 27, 2016 Permalink | Log in to Reply

        Hrm, well, RSS feeds don’t ordinarily require authentication, but I guess you could use it as authentication on a JSON API endpoint that gives similar data and tailor it to a user.

    • Scott Kingsley Clark 5:56 pm on January 27, 2016 Permalink | Log in to Reply

      I love this feature, looking forward to it!

  • Adam Silverstein 8:14 am on January 27, 2016 Permalink |
    Tags:   

    Feature Plugin chat notes for Jan 26 

    Agenda

    • Review the feature plugins for status updates from leads
    • Open floor for feature plugin proposal

    Feature Plugin Updates

    • Background Image Cropper: @celloexpressions asked for feedback for the Background Image Cropper. Current thinking is this is better explored as a standard enhancement for core. See #32403.
    • Customizer: @westonruter left status on the blog post for the Customize Pane Resizer, Customize Device preview (along with @celloexpressions), Selective Refresh, and Transactions. Please comment there if you’re interested in helping out where needed (especially requested for the Pane Resizer).
    • Fields API: @sc0ttkclark updated: term add/edit is in: props @technosailor. Team has been working on simplifying the code required for each screen implementing the Fields API. Scott posted an update on make/core and reports getting lots of feedback (especially from @helen, @drew, @technosailor & @celloexpressions)
    • Shiny Updates:  @obenland updated – Lots of progress in the last week. @ipstenu helped tremendously in getting it multisite compliant. Team decided to not pursue shiny activations/deactivations for a whole set of reasons, mostly around redirects on subsequent page loads, and fatal error protection.
      Currently working on enabling theme updates without having to open the modal, and revamping update-core.php.  An update will be posted to the make/core blog soon. The team needs more feedback and testing! Testers can get the current plugin from the wordpress.org repository.
    • WP-API: @danielbachhuber updated – released beta 11 yesterday. The team is meeting in person (minus @rachelbaker) this week at A Day of REST. Summary: in the home stretch, but there’s a ton more work to do. Friday’s contributor day (at the Day of REST) will hopefully get other people diving in and contributing to the final push.

    Open Floor

    The full logs are available on Slack.

     
    • jrf 10:52 am on January 27, 2016 Permalink | Log in to Reply

      I’d love to continue the discussion on Plugin Dependency management within WP.
      We’d very much would like to invite everyone to give their opinion on the direction we’re thinking of taking though this survey: http://goo.gl/forms/Fq1gbY9vCW

      We’d really appreciate getting as many opinions as possible about this. Thanks!

      • Felix Arntz 11:50 am on January 27, 2016 Permalink | Log in to Reply

        I just took the survey, I have a few comments on the approach.

        I certainly like that multisite will be supported, this is definitely a requirement anyway. 🙂

        About the dependency management: although I personally would prefer a JSON file, I think the theme/plugin header way is more the WordPress way, and a lot easier. People new to WordPress and even to development should be encouraged to start creating plugins/themes – external libraries/library plugins make this a lot easier, but I’m afraid a JSON file is too complex. Maybe both methods should be supported: while only the JSON approach would support the full functionality of dependency management, the file header would still allow to at least require plugins listed on wordpress.org with a minimal version number (there’s not really room in there to do more complex things). If someone needs external plugins or something like that, that should only be possible using JSON.

        The other thing is, in my opinion the recommendations feature should not be part of the feature plugin. Standard dependency management does not handle recommendations either, and I think this goes into kind of an advertising direction which I wouldn’t like to have in WordPress Core.

        I’m looking forward to this project and I’m happy you make these efforts to create a feature plugin. I think the full power of this feature however could only be leveraged if the wordpress.org plugins API would be adjusted as well to contain dependency information as this would allow notifications prior to installing which I think is even more elegant than notifications before activating (also due to the problems that this would bring on multisite). Anyway, first things first! 🙂

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

      Beta testing is much easier when feature plugins are kept up-to-date in the plugin repo. This allows using the built-in WP update mechanism to follow development. Our beta testing onboarding, such as it is, relies on feature plugins being updated regularly.

      A survey of https://wordpress.org/plugins/browse/beta/ and https://make.wordpress.org/core/features-as-plugins/:

      • Background Image Cropper: Last updated one month ago in the plugin repo. The features as plugins entry is bare.
      • Customize pane resizer: This is listed in neither browse/beta nor features-as-plugins.
      • Customize Preview Responsiveness (aka Customize Device Preview): The Customizer UI Experiments plugin was last updated two months ago. This is called three different things.
      • Customize Partial/Selective refresh: The plugin hasn’t been updated for 6 months.
      • Customizer transactions: I don’t see this in browse/beta or features-as-plugins.
      • Fields API: This is not listed in browse/beta. Does it even exist in the plugin directory?
      • Shiny Updates: This is in browse/beta and kept up-to-date. As such, I’ve been testing it.
      • WP API: This is in browse/beta and kept up-to-date. It is pretty much the only feature plugin to post on make/core regularly and do calls for testing.

      Court beta audiences. Update plugins in the plugin dir, preferably nightly. Keep features-as-plugins up-to-date. Publish calls for testing to make/core. Here’s a call for testing template and checklist. http://simp.ly/publish/XrHJDL

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

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

  • John Blackbourn 12:38 am on January 26, 2016 Permalink |
    Tags: ,   

    HTTPS discussion meeting this Wednesday 

    In recent releases of WordPress there have been various improvements made to support for sites running on HTTPS. While support is currently very good, it’s still too easy to end up with mixed content on a site (HTTP content embedded within an HTTPS page), and especially so when migrating an existing site from HTTP to HTTPS.

    There will be a discussion meeting in the #core-http Slack channel on Wednesday, January 27, 2016 at 2000 UTC. This is one hour before the regular weekly meeting in #core. I’d like to discuss three topics:

    1. Implementing an (opt-in) method of forcing a site to use HTTPS.
      • What should this cover? (Embedded content, enqueued scripts/styles, links, redirects)
      • How should it be implemented? (eg. filter/constant/automatic)
    2. Defaulting to HTTPS for new installs when it’s available.
      • Only applies when setting up a site over HTTP and it’s available over HTTPS.
      • Need to communicate clearly to the user what this implies, with option to toggle.
    3. Aiding in switching an existing site from HTTP to HTTPS.
      • Migrating existing embedded content.
      • Should this be a feature plugin?

    If you’re interested in helping out with any of the above, or with HTTPS improvements in general, join us on Wednesday.

    Further reading: the https tag on Core Trac.

     
  • Daniel Bachhuber 12:00 am on January 26, 2016 Permalink |
    Tags: , ,   

    WP REST API: Version 2.0 Beta 11 

    Just days before the first conference dedicated to the REST API, we bring you: 2.0 Beta 11 “Give me a white wine spritzer!”. Download it from the plugin repository or from GitHub.

    Here are some highlightsbreaking changes from the changelog:

    • Moves Post->Term relations to the Post Resource. Previously, a client would fetch a Post’s Tags with GET /wp/v2/posts/<id>/tags. In Beta 11, an array of term ids is included on the Post resource. The collection of terms for a Post can be fetched with GET /wp/v2/tags?post=<id>. The WP_REST_Posts_Terms_Controller class no longer exists.
    • Changes featured_image attribute on Posts to featured_media. While featuring other attachment types isn’t yet officially supported, this makes it easier for us to introduce the possibility in the future.
    • Uses discrete schema title for categories and tags. If you’ve used register_rest_field( 'term' ), you’ll need to change 'term' to 'tag' and/or 'category'.
    • Makes many filters dynamic based on the controller type. If you were using the rest_prepare_term filter, you’ll need to change it to rest_prepare_post_tag or rest_prepare_category. If you were using rest_post_query or rest_terms_query, you’ll need update your use to rest_page_query, etc. If you were using rest_post_trashable, rest_insert_post or rest_delete_post, they are now dynamic based on the post type slug.

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

     
  • Aaron Jorbin 9:13 pm on January 24, 2016 Permalink |  

    Accessibility Coding Standards now in draft and seeking comments. 

    The WordPress Accessibility Team has created draft Accessibility Coding Standards for the core handbook.  These standards will remain in draft format for at least the next two weeks while everyone has an opportunity to review and comment.  If there are significant changes made based on the comments, additional posts here will be made announcing them and seeking further comments.

    Please review the draft standards and leave your comments on this post.

     
  • Mike Schroder 8:32 am on January 23, 2016 Permalink |
    Tags:   

    Feature Plugin Meeting on Tuesday, Jan 26 

    As mentioned in this week’s dev chat, we’ll be holding a Feature Plugin meeting on Tuesday, January 26, 2016 at 2100 UTC (the usual dev chat time).

    If you are a lead for an officially recognized feature plugin, please either plan to attend if you’d like feedback, or if you can’t attend, leave a status in a comment on this post — we’ll be going through each of them during the meeting.

    These meetings are a great time to request feedback, show interest in a merge in 4.5, or propose a new feature plugin idea.

    For background, you can see more details on the feature plugin process in the core handbook, and a list of current feature plugins.

     
    • Weston Ruter 5:47 pm on January 26, 2016 Permalink | Log in to Reply

      I’ll provide an update here since I’m traveling today.

      The Customize Pane Resizer plugin (#32296) needs support, both finalizing the behavior of the resizer and preparing the core patch from the feature plugin.

      The Customize Device Preview plugin (#31195) has an updated patch from @celloexpressions. It got a +1 from @melchoyce and I’ll try to review the code later this week. I believe Nick is also going to put up a Make Core post on the feature for merge proposal feedback.

      My focus continues to be selective/partial refresh (#27355). This is something which I have identified as being a dependency for transactions (#30937). I am considering pushing out transactions to 4.6 so that themes can implement selective refresh first and not experience the flash-of-reloading-content issue for settings they don’t implement selective refresh. Also, transactions will ideally utilize the REST API, and since the REST API is under active development now, I’m wary to push too hard on transactions.

      Another ideal dependency for transactions is Customize Setting Validation (#34893). I think this feature plugin is in good shape and there is a core patch. The biggest need here is for the notification area (#35210) to be implemented according to the design worked up. A patch with the markup and styling is needed.

      As for adding page stubs within the Customizer (#34923), there is a mock for how this can work. There is a dependency here on having that notification area to prompt the user to edit the page stubs created. There will be some complexities to get the pre-saved page to appear in the nav menu and also to be able to navigate to this page. I will have a good chunk of time to work on this since it is a dependency for a client project, but I am concerned that it will miss the merge window.

      That’s all for now.

  • Chris Christoff (chriscct7) 8:36 am on January 22, 2016 Permalink |
    Tags: ,   

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

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

    Unfortunately, as I am unable to make today’s meeting, and was unable over the last few days to find a replacement, today’s meeting is cancelled. I hope to see you all at the next meeting, which will be next Friday at 17:00 UTC. Regardless, please feel free to use the time to triage tickets!

    The Slack archive for last week’s meeting begins here: https://wordpress.slack.com/archives/core/p1452877403010570
    During the bug scrub, the following tickets were covered:

    #32318 , #32920 , #12955 , #25669 , #27056 , #28441 , #29660 , #34839 , #35100 , #13910 , #30352 , #2702 , #33045 , #33283 , #13459 , and #18877

    Next week, the bug scrub will run approximately 1 hour. Participants need not be present for the full duration, and everyone is welcome to attend.

    We’ll start with a list of pre-submitted tickets, before going to an open floor. As time permits, the remainder will be filled with a mix of tickets in the 4.5 milestone, and abandoned tickets, taken from report 43 (Ancient Tickets) on Trac.

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

    During the WordPress 4.4 cycle, Trac experienced a net loss of approximately 600 tickets. The goal for the 4.5 release is to get to 2,500 tickets open on Trac. The current count is 3,347, which is 847 tickets from this goal.

     
  • Adam Silverstein 9:48 pm on January 20, 2016 Permalink |
    Tags: , ,   

    Core Dev Chat Notes for Jan 20 

    Announcements

    Focus Status Updates

    • Customizer: @westonruter, @celloexpressions
      • Good progress has happened for selective refresh, with good feedback and an architectural direction #27355.
      • A responsive preview feature has been getting good feedback and is nearing a committable patch #31195.
      • Update make/core post coming soon.
    • HTTPS Improvements: @johnbillion
      • Nothing specific to report about the HTTPS work, there will be a meeting next week about ‘force ssl’ which he will post about in make/core tomorrow morning for those who want to get involved.
    • Image Improvements: @joemcgill
      • Improving Imagick compression settings #33642 is still a priority.
      • Looking into options for #28474 (better animated GIF handling).
      • Longer term effort: what can be done to improve some of the core API for working with images
    • Multisite/WP_Site: @jeremyfelt
      • Several things assigned to the 4.5 milestone
      • A reorg of filters for network allowed themes went in today.
      • Working at the latest <code>WP_Site</code> patch now with the intent of putting it in today or tomorrow.
      • Office hours on Tuesdays at 21:00 UTC in #core-multisite; bring your bugs.
    • Post New: @michaelarestad
      • @karmatosed is going to be leading a team focused on improving the Revisions UI
      • @hugobaeta is going to be leading the Toolbar Remix team
      • @michaelarestad working on improving the Publishing UX and Metaboxes
      • @michaelarestad made a Sketch template for wp-admin that’s accurate and will be published later this week.
      • Update posts coming soon
      • Join the effort: comment on the original post and join the Slack #design channel.
    • Editor: @azaozz, @iseulde

    Open Floor

    • @ipstenu brought up #35429; @michaelarestad going to review from UX perspective, discussion
    • @azaozz brought up inline link dialog autocomplete, extend suggest.js or use another library (typeahead, select2)? what is the use case? discussion in #core-editor. @sheri offered to help with user testing to determine the best UX.
    • Meeting ended, ticket conversation continued…

    View the full logs on Slack.

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