Make WordPress Core

Updates from September, 2016 Toggle Comment Threads | Keyboard Shortcuts

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


    • 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
  • Joe McGill 1:40 am on September 23, 2016 Permalink |
    Tags: ,   

    Media Weekly Update (Sept 22) 

    This post serves to jump-start discussion before our weekly check in, which takes place in #core-images on Slack. Our next meeting is Friday, September 23 at 17:00 UTC and the agenda for these meetings include moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    Summary from last week

    Our last meeting was Friday, September 16 at 19:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

    Attendees: @joemcgill, @paaljoachim, @markoheijnen, @helen, @flixos90, @afercia

    • Unexpected change to media title behavior in WP 4.6.1 (#37989) – This is a regression, which has been partially fixed.
    • Sanitize accents in attachment filenames (#22363)@mike and @markoheijnen were planning to work on #22363 in person this past week and will decide on next steps.
    • Better PDF thumbnails (#31050)@markoheijnen tested out plugins that claim to handle this and found that all suffer from the same “corrupted image” issues that have blocked this ticket. The strategy is to see if we can detect which PDFs will fail and fall back to a default PDF icon when that is the case.
    • Media organization improvements:
      • Make media library searchable by filename (#22744) – This was fixed in [38625].
      • We had a lengthy discussion about the potential for adding a default taxonomy to attachments, including identifying some related tickets that would need to be addressed (e.g., #22938)
      • @paaljoachim shared the results of some research into how non-WP image applications handle media organization in the form of this Google doc.

    Agenda for our next meeting

    This week, we will continue discussion on our priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

    Priority Tickets:

    HTTPS Update: @johnbillion recently posted a call for an HTTPS Working Group on the make/core blog. Meetings will be on Fridays (time TBA).

    • djsteveb 6:33 am on September 23, 2016 Permalink | Log in to Reply

      Glad to see people improving WP’s image things.

      Hope we can get an easy option to set a default limit of how many media appear on the main /media uploads/ or whatever pages. Hope we can also choose to set a default ‘only user XXXX” at first, and perhaps view by user role in the future.

      Currently the browser window will freeze up with some WP installs I run with buddypress – as the default admin screen loads up with all the user’s images and thumbnails, taking a ton of time and memory.

      I mentioned this here:https://make.wordpress.org/core/2016/09/08/media-weekly-update/#comment-31163 but think I got the comment out there too late for anyone to see it.
      Maybe there is a better place to mention these things for future consideration in improvements with wp images ?


      • Joe McGill 2:05 pm on September 23, 2016 Permalink | Log in to Reply

        Hi djsteveb,

        Thanks for the feedback. The best way to bring up enhancement requests or bugs is by filing an ticket on Trac (if one doesn’t already exist addressing the issue you’re experiencing). In this case, it sounds like you may be experiencing the same issue described in ticket #30401. If you could provide feedback on that ticket, that would be helpful.


  • Andrew Rockwell 11:14 am on September 22, 2016 Permalink |  

    Week in Core, September 7 – 20, 2016 

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

    • 66 commits
    • 61 contributors
    • 171 tickets created
    • 15 tickets reopened
    • 106 tickets closed

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

    Code Changes



    • Docs: Use a third-person singular verb for wp_doing_ajax filter added in [38334]. [38607] #25669
    • Bootstrap: Use dirname() when loading class-wp-hook.php from plugin.php. [38589] #37707


    • Database: Fall back to utf8 when utf8mb4 isn’t supported. [38580] #37982


    • Add wp-util as a dependency for customize-controls. [38628] #38107
    • Remove IE8 access to customizer to discontinue support. [38627] #38021
    • Let static_front_page section be contextually active based on whether there are any published pages. [38624] #34923, #38013
    • Ensure nav menu items lacking a label use the title from the original object. [38618] #38015
    • CBetter hover/focus state for section titles and available widgets. [38602] #29158
    • Implement previewing of form submissions which use the GET method. [38587] #20714
    • Prevent widget previewing logic from building invalid jQuery selectors when sidebars are registered without a class name in before_widget. [38577] #37993


    • Normalise index names in dbDelta(). [38591] #34874
    • Increase the size of wp_posts.post_password to 255 characters. [38590] #881


    • Docs: Use a third-person singular verb for smilies filter added in [38504]. [38608] #35905
    • Update autop() to match wpautop(). [38594] #4857, #4857
    • Docs: Fix an outdated comment. [38593] #4857
    • Add an extra line break before block elements in wpautop(). [38592] #4857
    • Don’t send an HTTP status code in wp_send_json() by default. This avoids clobbering an HTTP status code that may have been set prior to calling this function. [38576] #35666



    • Correct context for Next/Previous strings in get_the_posts_pagination(). [38611] #37952



    Networks and Sites

    • Multisite: Show always domain and path when deleting a site. [38633] #37309
    • Multisite: Use get_networks() in get_main_network_id(). [38632] #37218
    • Multisite: Provide $join as a possible SQL clause to the sites_clauses filter. [38631] #37922
    • Multisite: Add annotations for extended WP_Site properties. [38630] #37932
    • Docs: Synchronize docblocks for WP_Site_Query::__construct() and get_sites() after the changes in [37735], [38008], [38103], and [38336]. [38596] #38039
    • Docs: Correct description for domain and path arguments in WP_Network_Query::__construct(). [38595] #32504

    Options, Meta APIs

    • Options: Build out register_setting like register_meta. [38635] #37885


    • Ensure Pending Review Posts permalink posts link to the draft [38572] #37423


    • Style the primary action link in the non-js “Installing Plugin” page. [38617] #36430
    • Tests: Use add_filter() when it’s available. [38582] #17817
    • Docs: Fix minor formatting for inline docs in WP_Hook following its introduction in [38571]. [38573] #17817
    • Hooks: Add the new class WP_Hook, and modify hook handling to make use of it. [38571] #17817

    Posts, Post Types




    • Docs: Correct the description of {$taxonomy}_term_new_form_tag hook, making it more consistent with other *_form_tag hooks. [38629] #38104
    • Pass taxonomy name to actions in term-relationship CRUD functions. [38621] #38006
    • Query: Eliminate unnecessary wp_list_filter() call in get_queried_object(). [38586] #37962
    • Query: Avoid PHP notice in get_queried_object() when query contains NOT EXISTS tax query. [38585] #37962


    • Docs: Correct two references to plugins in the $args parameter description for themes_api(). [38623] #37939
    • Docs: Use a third-person singular verb for {$type}_template_hierarchy filter added in [38385]. [38609] #14310
    • Docs: Use a third-person singular verb in the DocBlock summary for get_theme_file_uri(), get_parent_theme_file_uri(), get_theme_file_path(), and get_parent_theme_file_path(), introduced in [38578]. [38606] #18302
    • Docs: Use a third-person singular verb for theme_file_uri, parent_theme_file_uri, theme_file_path, and parent_theme_file_path filters added in [38578]. [38605] #18302
    • Add the non-encoded form of the queried item slug to the template hierarchy when the slug contains non-ASCII characters. [38583] #37655
    • Taxonomy: Revert accidental changes introduced in [38578]. [38579] #18302
    • Improve child theme file inheritance by introducing functions for locating and fetching the URL or path to files within child and parent themes. [38578] #18302


    • Add a ‘View Posts’ link to the toolbar when on the post listing screen. [38634] #34113


    • Docs: Correct a comment and @return entry in WP_Upgrader::create_lock(). [38622] #38089
    • Automatically log users in after installation. [38619] #34084


    • Avoid a PHP notice in ::pingback_ping() if page title was not found. [38620] #36727
    • Check the minimum number of arguments in ::wp_getUsersBlogs() and ::blogger_getUsersBlogs(). [38600] #29750

    Thanks to @aaroncampbell, @adamsilverstein, @afercia, @akibjorklund, @DMing, @BjornW, @boonebgorges, @celloexpressions, @curdin, @danielpietrasik, @dd32, @DrewAPicture, @eliorivero, @enshrined, @ericlewis, @FlorianBrinkmann, @folletto, @georgestephanis, @gma992, @helen, @hideokamoto, @hugobaeta, @ian.edington, @iandunn, @jbrinley, @jeremyfelt, @joehoyle, @joemcgill, @johnbillion, @johnjamesjacoby, @jorbin, @karmatosed, @kitchin, @knutsp, @markshep, @MaximeCulea, @melchoyce, @monikarao, @nacin, @nazgul, @obenland, @ocean90, @paulwilde, @pento, @peterwilsoncc, @RedSand, @rmccue, @rnoakes3rd, @rommelxcastro, @ryankienstra, @ryanplas, @SergeyBiryukov, @skippy, @spacedmonkey, @swissspidy, @Takahashi_Fumiki, @websupporter, @welcher, @westonrute, @westonruter, and @wonderboymusic for their contributions!

  • Nick Halsey 1:53 pm on September 16, 2016 Permalink |
    Tags: ,   

    Customize Update – 2016-09-15 

    This is the weekly update post for the customize component. It includes a summary of this week’s meeting, recent commits, and next week’s meeting agenda.

    Weekly Customize Meeting Summary

    On Monday we held our weekly 4.7 customize component meeting in #core-customize on Slack [logs]. Participants: @celloexpressions, @aaroncampbell, @westonruter, @boone, @adamsilverstein, @afercia, @johnregan3, @ipstenu. This summary also contains a few notes on action since the meeting.

    4.7 Projects

    • Create pages within live preview during site setup – #37914#37915, #37916, #38002, #38013 – @celloexpressions
      • @boone joined us for an extensive discussion on how to preview terms in the customizer.
        • When this changes, there is potential for issues based on things that plugins might do, so it would be better to make this sort of change once, as opposed to using a temporary solution, because there could be wasted effort in educating plugin developers twice.
        • We decided that it’s worth exploring a term status API, and if that ends up being something more involved than is feasible for 4.7, potentially going with shadow-draft taxonomies for drafted terms. @boone will post findings on #37915. @aaroncampbell volunteered to help research required API changes here.
      • We’re now tracking the ability to assign auto-drafted pages as a static front page, or to create pages from there, under this project. @westonruter has prototyped how this could work in #38013.
      • We need UX feedback on providing a path to edit newly-created pages, #38002. This was discussed in the design meeting as well but there isn’t an agreed solution yet.
    • A new experience for themes in the customizer – #37661 –@celloexpressions
      • @afercia tested the patch and provided detailed design and accessibility feedback. I evaluated how to approach each item and a few things could use design feedback.
      • I ran an informal user test last week and posted the (generally positive) results on the ticket. @karmatosed is hopefully still interested in coordinating some more formal tests and we need to start that process in the next week.
      • This was also discussed during the design meeting, and could use more eyes and feedback in general. If anyone has thoughts on any of the proposed UI, please share them on the ticket.
    • Code-editing gateways, via CSS – #35395 – @johnregan3
      • We need information from anyone familiar with the CSSTidy library. It seems that the version included in Jetpack is an up-to-date fork, as the original project was last updated in 2007. If anyone from Automattic can provide input here that would be appreciated.
      • We also need to ensure that the license, GPL 2.1 or later is compatible with core.
      • The CodeMirror library is also proposed to be bundled with core for this project; we would like core commiter/lead developer approval for bundling both of these soon so that we can proceed. CSSTidy is a requirement, CodeMirror is a usability enhancement (syntax highlighting).
      • Once we have approval for bundling libraries and a finalized patch, we’ll post a feature proposal here on make/core.
    • Customizer browser history#28536 – @westonruter
      • No updates
    • Customize transactions#30937 – @westonruter
      • No updates
    • Improving sliding panels UI – #34391, #34343, #29158 – @delawski
      • We’re now tracking three tickets with this project, as they combine to provide a single user-facing group of changes for 4.7.
      • I have been testing the patch on #34391 and evaluating potential compatibility concerns. @ipstenu scanned the plugins repo and @djrmom scanned the themes repo for extends WP_Customize_Seection|Panel. Most instances were in themes and plugins bundling copies of the Redux and Kirki frameworks. Both libraries are most likely compatible with the changes, and the authors will test them with the patch to verify. The remaining instances were all in feature plugins for plugins and I checked each of the 16 themes with custom sections manually. All of these themes should be compatiible with the changes, so we should be okay to proceed with the potentially-breaking changes required.
      • @delawski will evaluate how extensively the patch on #37661 will need to be refactored to be compatible with the changes. Unless that’s a significant issue, we should be ready to commit #34391 in the next week.
      • @helen committed a first pass for #29158. We now need UI feedback to come up with better focus states for customizer back buttons.
      • The design team approved the UX proposed in #34343 in this week’s design meeting.
    • Twenty Seventeen
      • There are a few potential customize-related projects. It’s all tentative, but the customize team should be prepared to spend some time at a minimum reviewing and finalizing patches/commits, and where there’s interest, helping to scope, design, and develop these features.
      • Video headers will start as a theme feature, with the possibility of becoming a core add_theme_support (under the customize component) or (maybe) moving to a media ticket for per-post featured media. If it’s in core we may need to refactor header images, but ideally we’d keep it separate, due to the complexity of that feature.
      • A multi-content page feature of some sort will exist in the theme, and may require a core API, which may be in the customizer. This is being discussed in #37974. See also this pull request.
      • Visible edit links (#27403) are desired, but this will take some major UX work. @westonruter suggested that it could be a theme-specific feature, where the theme has to provide styling for them. Ideally, though, it should work for all themes with selective refresh partials providing support for specific features.

    Additional Tickets Needing Attention

    • Improve custom background properties UI – #22058 – needs additional feedback and clarification on the latest proposal and patch.
      • Discussed in the design meeting, and we’re generally on the same page on the preferred direction here.
    • Customizer notifications – #35210 – needs UX feedback and a patch
      • Discussed during the design meeting. Next step is for @westonruter to make a patch to facilitate the next round of feedback.
      • This ticket is holding up some of the other tickets on the 4.7 milestone, such as #22037 and #29932, as well as transactions.
    • Remove customizer support for IE8 – #38021
      • If anyone has objections, bring them up ASAP. All links to the customizer will be hidden in IE8 with this change.

    Ticket Scrub

    We reviewed the bugs in the Future Release milestone that have a patch.

    • #36908: Customizer menus and widgets “search” usability and visual improvements
      • Has a recent patch, assigned to @afercia for review and commit.
    • #21492: Theme customizer > Static front page: missing error message when front page and posts pages are similar
      • Patch needs to be reworked to leverage the notifications API added in 4.6. It would also be better to disable the option for the selected page in the other dropdown.
    • #23225: Customizer is Incompatible with jQuery UI Tabs
      • This is pending customizer transactions and #30028 (loading the customizer preview with natural URL), and the patch on the ticket doesn’t fix the issue.
    • #37032: Guard against infinite reload when setting change causes premature selective refresh
      • Needs testing. If anyone’s interested, please try out the patch and leave feedback on the ticket!
    • #34344: Expanded section margin-top glitches when other section is deactivated
      • This is fixed by the 4.7 project that includes #34391, along with another bug. We’ll revisit the ticket after the commit to verify that it’s fixed as intended.
    • #32577: Customizer QUnit tests not cleaning up
    • #36191: Support responsive images in WP_Customize_Media_Control
      • Work here is being led by the media component. We’ll leave it in future release until they’re ready to revisit it.
      • Note that this ticket is for images in the customizer controls pane. Responsive images on the frontend for images selected in the customizer are a separate topic.
    • #33267: Customizer Theme details: too many events
      • We’ll revisit after work on #37661 is complete, as there are major changes there.
    • #33085: Customizer: controls description inside labels are not real labels nor descriptions
      • The patch here is quite large; @westonruter noted an adjustment that needs to be made and moved the ticket to 4.7. We should get this fixed.
    • #25156: get_custom_header() should return false when there is no header
      • Decided to close the ticket as maybelater due to lack of movement/interest in fixing.

    Recent Customize Commits

    Here are the customize-related commits for the past week:

    • [38602]: Customizer: Better hover/focus state for section titles and available widgets.
    • [38587]: Customize: Implement previewing of form submissions which use the GET method.
    • [38584]: Menus: Prevent non-published posts/pages from being returned in search results for available items, to match behavior in the customizer.

    Big thanks to those who contributed to patches committed this week: @welcher, @westonruter, @celloexpressions, @folletto, @hugobaeta.

    We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved. Fun fact: we’re 15 commits away from the 1000th commit that references customize.

    Agenda for 2016-09-19 Meeting

    Our next regularly-scheduled meeting is next Monday, September 19, 2016, 17:00 UTC. Agenda:

    4.7 Projects

    Additional Tickets Needing Attention

    • Customizer notifications – #35210 – needs UX feedback and a patch
    • Customizer UI Contrast/Focus Styles – #29158 – needs UI ideas for focus styles on back buttons.

    Ticket Scrub

    • Customize tickets without replies. Reply to tickets before the meeting to make the list shorter 🙂
    • We’ll pick a different query to triage each week. For example, bugs awaiting review (need verification).

    We’ll see you next week!

  • David A. Kennedy 10:57 pm on September 9, 2016 Permalink |
    Tags: , ,   

    Twenty Seventeen Kickoff Meeting Notes 

    Today, we had a kickoff meeting for Twenty Seventeen! See the introductory post for some details.

    A few housekeeping notes:

    • Slack archive of meeting.
    • This meeting was short notice, but I plan on posting an agenda each week prior to the meeting.
    • No meeting next week, but watch out for posts here about tasks related to Twenty Seventeen.
    • Next meeting is Sept. 23rd.
    • Meetings are every Friday at 18:00 UTC in #core-themes in Slack.

    Our agenda was:

    Introduction to Twenty Seventeen

    • This meeting really has two main focuses: Gather help, and a design review.
    • Twenty Seventeen aims to show that the one-page look and feel is possible in a WordPress theme.
    • And the bullet points in the announcement post get directly to that:

    A better flow for using a static page as your front page.
    Visible edit icons in the Customizer, replacing the current hidden shift+click method.
    Expanding custom header images to include video (think: atmospheric video headers!).
    Dummy content for live previews.

    Ways to help

    We discussed a few of the above bullet points in more details but tried to stay out of talk of implementation. We focused on how to best break the work up and what the first steps would be. There’s many ways to help with Twenty Seventeen this year that don’t involve the theme itself or code.


    • #19627 Themes should be able to opt-in to a static front page: Document what other services, platforms and themes do to help inform a bunch of things, including page-on-front changes. @melchoyce will take a look at the WordPress.com flow for front page setup and related things to get this started.
    • Dummy content for live previews: @helen described this as: “So, dummy content would be something like a text widget with business hours appearing in live preview (currently known in the form of the customizer) if there are no widgets in that area yet. That shows users a) there’s a widget area there (otherwise it’s just empty right now, or maybe has like, a search box and a login link at best), and b) what content might work really well there and what it’s going to look like.”
    • #37974 Add multi-panel feature to pages through add_theme_support: @karmatosed created this ticket and has ideas on how to move forward with it.

    Who wants to help?

    • Front page flow: @mor10, @aaroncampbell offered to help here.
    • Video headers: Myself, and @celloexpressions have interest here.
    • Dummy content: @helen will help get this moving.
    • Visible edit icons in the Customizer: We need help here, but should have details soon on this. See: #27403.

    If you want to help on any of these, and missed the meeting, no problem! Comment here and I’ll do my best to get you pointed in the right direction.

    Design review/feedback

    @melchoyce lead the design review:

    Here are the current mockups, for reference: https://cloudup.com/cR_df4xfeeG

    Mel’s to-dos she’ll be working on in the next week: https://cloudup.com/cRPc_k7MnIb

    Points discussed:

    • Extremely wide screens + what happens to images that are not wide enough to be full-bleed.
    • Make sure color contrast requirements are met.
    • Mel wants to explore pull-quote styles and color schemes.
    • Really rock-solid support for non-latin alphabets should be explored.

    Questions, Next Steps, Etc.

    • The schedule is listed above.
    • What about browser support? See this issue from Twenty Sixteen, which Twenty Seventeen will follow.

    The theme is now on GitHub. A few things to keep in mind:

    • The theme is a fork of Lodestar, a theme designed by Mel and built by @laurelfulford. It’s an excellent base to start with and what you’ll see on GitHub.
    • The design isn’t implemented.
    • A lot of other work remains too, and issues will be created in the coming week to help guide the process.

    Again, if you want to help, comment here. If you have questions, just ask. It’s time to get to work! 🙂

    • Torsten Landsiedel 11:42 pm on September 9, 2016 Permalink | Log in to Reply

      Just a quick reminder: Please consider using version numbers for all PHP files:
      This would be great for all child theme users. Thank you! 🤗

    • Samuel Wood (Otto) 12:48 am on September 10, 2016 Permalink | Log in to Reply

      Go ahead and change the readme.txt to a readme.md for github. Make it friendly. The themes directory doesn’t care about readme files at the moment anyway.

    • hazephase 2:14 am on September 10, 2016 Permalink | Log in to Reply

      I want to help, but I am not the best coder. Is there I can do?

    • mburridge 2:20 pm on September 10, 2016 Permalink | Log in to Reply

      Hi, I’d love to get involved and help too – though I missed the meeting yesterday. I’m mainly interested in the Front Page flow area, but willing to help elsewhere if that is oversubscribed.

    • Christi 6:57 pm on September 10, 2016 Permalink | Log in to Reply

      Howdy! I’m interested in helping out, any way I can. My strengths are in HTML, CSS, troubleshooting, design, and documentation. I’m working on my PHP skills. I also have a 27″ screen I can test on, if that helps 🙂

    • WPDevHQ 5:51 am on September 11, 2016 Permalink | Log in to Reply

      I’m in too. Let me know where I can help.

      Had a look at the design screenshots and the code on GitHub and I think I can chip in the overall workflow but can also concentrate on a specific workflow if need be.

      A rough working copy is here: http://www.wpdevhq.com/seventeen/ – need some polishing but can get to that as soon the final design is released and we are ready to go at it 🙂

    • smartpixels 11:32 am on September 11, 2016 Permalink | Log in to Reply

      I wish to help with Customizer side of things… I have also implemented sweet alert system through Customizer API into this theme https://themes.trac.wordpress.org/ticket/35788 which I thought improved overall user experience in customizer with feedback for every wrong action.

    • Nick Halsey 6:58 pm on September 11, 2016 Permalink | Log in to Reply

      @davidakennedy please reference the existing core ticket for visible edit icons (or whatever the UI ends up being) in the Customizer: #27403 when discussing it.

      For the static front page discussion, #16379 is probably more relevant than #19627, and #16379 may be superseded by #38013 for the customizer. It’s somewhat unclear what the objective here is. The multi-part homepage discussion should probably be treated as a separate issue and we have #37974 for that now (although it may not require core changes depending on the decisions made).

      We could probably broaden the video headers project to include explorations for other types of media in headers throughout the theme, as @melchoyce had mentioned, with video header being the first priority and additional wish list items following the work on that.

  • Brian Krogsgard 9:25 pm on September 8, 2016 Permalink |
    Tags: ,   

    WordPress REST API update 


    There’s a renewed push going on right now to try and get what is being termed “content endpoints” into WordPress core with the 4.7 release.

    In the first core development meeting of the 4.7 cycle, @helen identified a series of tasks that would need to be analyzed and acted upon to be able to make a new proposal for core inclusion, including identifying existing blockers. There is a team of people actively working on these items, and your participation is wanted!

    New meeting times

    Regular meetings have been changed to take place at 14:00 UTC Mondays, with bug scrubs at 14:00 UTC Thursdays — all in #core-restapi. So the next meeting is Monday, September 12th, 14:00 UTC.

    Fuller story and action items

    If you are not caught up on the state of the WordPress REST API, the infrastructure for the API went into WordPress 4.4. Since that time, several prominent plugins are using the infrastructure to create their own REST APIs.And now the feature project (not in core) consists of core endpoints and authentication mechanisms. The four primary types of resources that have been developed are for: posts (and other post types), users, comments, and terms. There is also a Google spreadsheet where you can list sites you know of running V2 of the REST API plugin in production.

    The proposal, if the various criteria are met, would request core inclusion for what we’re calling “content endpoints”, and “management endpoints” would be part of a subsequent release cycle. With the content endpoints, website developers would have tools at their disposal to build websites in whatever programming language they choose, using data from WordPress. Additionally, certain types of applications would also be able to create experiences for managing WordPress content — though not complete WordPress site management the way you can from the WordPress admin.

    The primary focus areas for core inclusion of the WordPress REST API — as initially defined by Helen, and then expanded on in the core dev chat meeting — are as follows:

    1. Rigorously test 4.6 and trunk compatibility and resolve any issues that may be found.
      1. Includes reviews by current component maintainers for existing endpoints.
      2. For example: WP_Post_Types and other new objects, need compatibility.
    2. Identify and resolve some of the final “quirky” issues (e.g. password-protected posts).
    3. Create support for meta.
      1. By “meta support” in the API, we refer to meta values that have been registered by a developer. Ideally via register_meta( ...., array( 'show_in_rest' ) ). For clarity, this excludes arbitrary meta storing (i.e. a client arbitrarily using the WordPress database)
    4. Create support for options – this is not “content” per say, but imagine an app where you can’t change your site title and tagline.
      1. Needs significant clarification, definition of what should be achieved
      2. Repo for site endpoints: https://github.com/WP-API/wp-api-site-endpoints
        1. Discuss architecture for how this would work (like, site endpoints w/ object of settings) https://github.com/WP-API/WP-API/issues/816
    5. Establish a forward compatibility plan, particularly around how to avoid/minimize plugin and theme conflicts. IE: namespacing and documentation / protected stuff. Relate to current general WP best practices (IE: custom field named “likes” – possible vs good idea). Need document to outline our views.
    6. Dedicated reviews from developers with deep experience in security and REST APIs, ideally including some of the non-WP PHP community.
      1. Identify and request reviews by specific developers & subjects.
        1. Security
        2. Core compatibility
        3. Integration
        4. Consumption
        5. Non-WP developers / fresh eyes
    7. Identify current authentication options, and their viability for inclusion in 4.7. Document flows of implementing and using each.
      1. Cookie auth
      2. Basic auth
      3. oAuth 1
      4. oAuth 2
    8. Establish and document data with performance comparisons – speed, bandwidth, etc – against admin-ajax, XML-RPC, etc. (Might just require education, as really all these are pretty similar). Identify and address performance related issues on project GitHub repo.
    9. Recruit and assign new / excited contributors
    10. Align existing docs with primary project. Outline documentation needs, and create them.
      1. Get volunteers to take on specific tasks
      2. Decide where these docs go, both now and in the future

    Specific initiatives

    There are several more specific initiatives to work on, many of which we’ve tasked out and assigned, but plenty that could use more input.

    Docs Initiatives

    • Inline docs will eventually be merged into core inline docs, so any prep there should be roadmapped along with the rest of the 4.7 planning
    • User docs on consuming the API (e.g. doing things with the routes it provides from external systems, like uploading media) are needed and should live in the docs-v2 repo for now. See issues list for current user-facing documentation needs.
    • User docs on extending within the context of the API plugin (how to add routes, how to lock down access to auth’d users) are needed and should live in the docs-v2 repo for now
    • Docs on making endpoints with the infrastructure currently in core should live within the developer handbook

    Task Assignments

    • Ping component maintainers to see what testing they’ve done w/ API (@krogsgard)
    • Password game plan: relies on #16483: Blank content, rendered string, title however it is done in core now, 401 for individual posts, content to include protected:truein return object, and (maybe) give users that can edit posts access to content in response, consider Authorization header options. (@rmccue)
    • A pass at registered settings. @joehoyle has tackled this with a first draft, along with #37885.
    • Document feature detection as it works today (http://v2.wp-api.org/guide/discovery/). Establish best practice for extending with new endpoints. Establish best practice for modifying existing objects.
    • Documentation needed: compare register_rest_field() vs register_meta() and document best practice for when register_rest_field() may still be preferable. But generally encourage usage of register_meta()
    • Consideration: With register_rest_field, maybe force a namespace a la register_rest_route
    • Contact implementors from @joehoyle‘s API-in-use list to get feedback on their experience with the API (@krogsgard)
    • Document that name, description, url and home are the options already available in index as read-only. Consider change of this with global options endpoint.
    • Develop personas for user groups that interact with the API (@jorbin)
    • Interface testing for cookie and oauth1 implementations. Recruit UI/Design help. (@krogsgard and @kadamwhite)
    • Determine auth_callback (needs different name, has a conflict right now) necessity within register_meta(), as someone may want meta exposed, but only for authenticated users, and there is no cap system for read_meta.>
    • Review https://github.com/WP-API/WP-API/issues/2558 for performance gain.
    • Review https://github.com/WP-API/WP-API/issues/1625 for awkward data handling w/ client-js

    Bug scrubs

    The first bug scrub of this cycle took place today, and we were able to go through all open issues on GitHub that do not have a label, and label them, plus add at least some level of context. Our priority for future meetings will be to ensure that we have assigned bugs to appropriate people, and go back through and ensure we have milestones assigned to various tickets. We’ll have an open floor period during each regular meeting to discuss particular issues.

    Get involved

    If you have any interest in the API, your help and insights are wanted! You can join Chat.WordPress.org in the #core-restapi room to sit in and watch, or jump in to various discussions. Also, if you just want to play with the plugin and report back your experience, that’d also be super helpful.

    One group of core contributors we really need feedback from are component maintainers. The team working on the REST API would like your input on how well the API currently interacts with your component, how it can improve, and to identify trouble areas that would need to be addressed both for initial core inclusion of the API, and down the road.

    Thanks for listening!

  • Nick Halsey 4:40 am on September 2, 2016 Permalink |
    Tags: ,   

    Customize Update – 2016-09-01 

    This is the weekly update post for the customize component. It includes a summary of this week’s meeting, recent commits, and next week’s meeting agenda.

    Customize 4.7 Kickoff Meeting Summary

    On Monday we held the customize component kickoff meeting in #core-customize on Slack [logs].

    Potential 4.7 Projects

    We started by identifying potential projects for 4.7, and people to lead them. The following projects are currently targeting merge for WordPress 4.7:

    • Create page-based nav menus without leaving live preview#34923 – @celloexpressions
      • @westonruter committed a first pass here, closing the primary ticket as fixed.
      • #37914, #37915, and #37916 have been created for follow up, and are currently in the 4.7 milestone. We need input from the taxonomy component to enable terms to be previewed before adding support for terms.
    • A new experience for themes in the customizer#37661 – @celloexpressions
      • There are a few more dev-heavy tasks but we’re ready for design feedback (@folletto will take a look when he has time) and user testing.
      • In the core dev chat, @karmatosed volunteered to coordinate user testing here.
    • Code-editing gateways, via CSS#35395 – @johnregan3
      • We decided that bundling CSSTidy (used by Jetpack) in core is the best solution for sanitizing CSS.
      • Syntax highlighting for a more proper code-editing experience is a nice-to-have but not required for a first pass.
      • CSS should be stored in a new custom post type (with revisions), with a distinct post for each theme (i.e., all CSS will be theme-specific here).
      • @johnregan3 volunteered to spearhead this project and expects to have it ready for 4.7.
    • Customizer browser history #28536 – @westonruter
      • Development is happening on github, and there is only one issue currently, with customize-loader.js. We discussed potentially eliminating the iframe aspect of the customize loader script eventually, as it has caused a lot of issues and doesn’t offer significant usability benefits.
      • We also need to investigate possible performance issues in conjunction with #37661.
    • Customize snapshots/transactions #30937 – @westonruter
      • We decided that the snapshots UI will remain in a plugin for now, but transactions themselves could potentially be ready for 4.7. Transactions allow for the customizer to be used to preview changes to REST API in headless sites.
      • @westonruter brought up a few concerns with the sequencing of transaction updates and selective refresh, which could result in two HTTP requests for the preview where there was previously one. Ensuring no degradation in performance is key here.
      • Transactions would complement #37661 nicely in 4.7 even without the snapshots UI, as theme customizations during the theme selection workflow could be saved without being published to the live site.
    • Customizer notifications #35210 – @westonruter
      • This needs more design feedback and a patch based on the latest proposal.
      • This is less of a project, so we’ll track it as a ticket moving forward.
    • Refactoring sliding panels UI#34391 – @delawski
      • @delawski will work to finish this up soon so that it can get into 4.7 relatively early.
      • We’ll need to coordinate this with the theme experience refresh in #37661, which bypasses the margin-top hacks.

    Additional projects discussed:

    • Improve UI for linking preview elements to controls#27403
      • We might try to make some improvements here, but we aren’t currently targeting major changes for 4.7. This might change if more contributors contribute here, particularly on the design side.
    • Twenty Seventeen
      • @helen mentioned in the dev chat that information on Twenty Seventeen will be announced next week. Depending on the customize scope, we might want to have a dedicated person to help there and report back to the customize component meetings.
    • Customize Posts
      • Not targeting 4.7, but it would greatly benefit from a thorough UX review now that the majority of the functionality is in place.
      • We’d like to fix #30378 in 4.7, using JS templates for the base WP_Customize_Control UI, to support the plugin.
      • A new project to bring similar functionality to taxonomy terms is breaking ground.
    • Live Preview Feature Project
      • After 4.7, we’ll revisit this project to take a holistic look at how live preview works in core. The end result will likely be a UX strategy for introducing contextual live preview for posts and terms, likely leveraging the existing customizer API and technology developed in the Customize Posts plugin, but potentially with an entirely different user interface than what’s currently known as the customizer: namely, looking at ways the customizer framework can be bootstrapped onto the frontend along with inline editing.

    Additional Tickets Needing Attention

    We briefly drew attention to the following tickets needing feedback from other teams:

    • Improving contrast and UI consistency in the customizer – #29158needs-testing
    • Improve custom background properties UI – #22058 – needs additional feedback on the latest proposals, and a patch
    • Appropriate means for themes to add top-level promotional links – #37335 – needs input from theme review team
      • The theme review team agreed that this was probably a good solution, but wants to investigate other options for developers before moving in this direction. On the core side, we’ll wait for direction from them

    Open Floor

    We closed with an open floor in lieu of a ticket scrub, due to time.

    • @clorith brought up sticky panel headers/back buttons (#34343 and #35186)
      • @delawski would like to work on these tickets after finishing #34391. We’ll need additional design feedback here as well to decide the direction (probably one or the other of the tickets).

    Recent Customize Commits

    Here are the customize-related commits for the past week:

    • [38396]: Customize: Circumvent the customizer attempting to preview links to static assets (such as uploaded images).
    • [38436]: Customize: Allow users to more seamlessly create page-based nav menus during customization.
    • [38464]: Customize: Improve handling of active state for dynamically-created controls/sections/panels.
    • [38478]: Customize: Use new `$status_code` parameter for `wp_send_json_error()` instead of calling `status_header()` separately.
    • [38479]: Customize: Fix i18n by re-using the `add_new_item` post type label instead of using a post type name in a generic string, in [38436].
    • [38492]: Customize: Introduce `paneVisible` state and ensure pane is visible when a construct is expanded (or focused).
    • [38503]: Accessibility: Make links in the Customizer underlined by default.

    Big thanks to everyone who contributed to patches committed this week: @Presskopp, @afercia, @westonruter, @celloexpressions, @valendesigns, @melchoyce, @mapk, @iseulde, @mrahmadawais, @sayedwp, @johnbillion, and @curdin.

    We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved.

    Agenda for 2016-09-05 Meeting

    We will have a meeting next week despite the holiday in the US; Monday, September 5 at 17:00 UTC. Agenda:

    4.7 Projects

    Additional Tickets Needing Attention

    • Improving contrast and UI consistency in the customizer – #29158needs-testing
    • Improve custom background properties UI – #22058 – needs additional feedback on the latest proposal, and a patch
    • Appropriate means for themes to add top-level promotional links – #37335 – needs input from theme review team
    • Customizer notfications – #35210 – needs UX feedback and a patch (and perhaps a clearer demonstration of the iteraction)

    Ticket Scrub

    • Identify tickets ready for commit consideration, and 4.7 milestoning from future release tickets with a patch.
    • We’ll pick a different query to triage each week. For example, bugs awaiting review (need verification).

    We’ll see you next week!

  • Jeff Paul 1:02 am on September 2, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: August 31 (4.7 week 2) 

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

    Holidays & Scheduling

    • Reminder to announce meeting moves or cancellations (e.g., Monday is US Labor Day holiday, Monday after is Eid al Adha)

    Update on 4.6.1

    #36335: Autoloader and #37699: Globals

    • Discussion framing: see these as being feature projects in their own right, examples of when features can’t be actual plugins and why it’s better to think of them as projects. How can these be worked on effectively?
    • Discussion:
      • New project on GitHub that’s a clone of the WP Git repo
      • grunt patch allows you to use GitHub PR URLs, which can help facilitate testing for people that prefer using SVN or are using SVN for their trunk installs.
      • Trac + SVN workflow seems to work best when we’re dealing with patches and discussion leading to an individual commit; is probably a pretty poor option without some additional tools.
      • Creating feature branches for wide-ranging work seems to be a better fit and allows for less churn of the code in trunk at the same time as other major work.
      • Nice to review & collaborate on a big feature on a GitHub feature branch as opposed to wrangling conflicting and amending patches on Trac
    • Suggestion to @wonderboymusic: fork @jorbin‘s GitHub mirror, use GH issues and develop in various branches as makes sense (or even separate forks entirely if issues become unwieldy across very different projects), and use PRs to run existing CI setup. PRs can then be used as patches in grunt patch
      • If treated as a feature project, all of that project’s management happens wherever the lead feels best serves that project. There should also be weekly meetings with updates posted on Make/Core. @wonderboymusic to determine a meeting time and post about it next week.
      • @wonderboymusic@helen in agreement on approach; GitHub repo created
    • Related question: How do we determine what sort of tasks should be feature projects? Who decides that? And when?
      • Some things to think about – is it a lot of churn? Does it need to span multiple releases and/or is it a “done when it’s done” process? Is there a lot of design and user testing involved? They exist whenever somebody has a thing they believe belongs in core and wants to run with it in that way. Getting feedback is an evolving process.

    4.7 Project/Feature Proposals

    • Goal: come out of this with the start of a list of projects and a point person for that project, to be fleshed out with more participants and meeting times over the next week.
    • @johnbillion – HTTPS
    • @celloexpressions – Customize component project & owner
      • Create page-based nav menus without leaving live preview – #34923@celloexpressions (follow up tickets forthcoming)
      • A new experience for themes in the customizer – #37661@celloexpressions
      • Code-editing gateways, via CSS – #35395@johnregan3
      • Customizer browser history – #28536@westonruter
      • Refactoring sliding panels UI – #34391@delawski
      • (maybe) Customize transactions (with no UI) – #30937@westonruter
      • will track all of the Customize projects with the weekly Customize component meetings and Make/Core posts usually posted on Thursdays starting this week
    • @krogsgard – REST API
      • had a productive start on Monday and will have a summary up shortly
    • @boonebgorges – #20875
      • work with cache drop-in authors so that we can start leveraging across WP
    • @davidakennedy – #19627
    • @helen – there needs to be a dedicated theming API/support team because there will be a Twenty Seventeen; actual details on that next week. There will need to be really robust teams on both the theme and theme support pieces, likely with subteams even.
      • @karmatosed: splitting core themes as a bucket for all theme into, core themes and theme functionality
      • @helen: noting that theme functionality will spill over into other components (media seems incredibly likely)
      • @themiked: interested in theming work, on the API/support side if that’s whats needed
    • @joemcgill – Media focus candidate & owner; will shepherd these through regular #core-images meetings
    • @azaozz – will publish “4.7 editor wishlist” by the end of the week
      • to include Nonce refresh/saving without page reload, and few others
    • @sc0ttkclark – Fields API

    Ways YOU Can Help!

    • Please comment below if there are things that didn’t get mentioned that you’d like to lead.
    • Design help and user test coordination (alongside @karmatosed) desired on #37661 by @celloexpressions, please respond if you’re open to help on this.
  • Aaron Jorbin 12:16 pm on August 30, 2016 Permalink |
    Tags: ,   

    The Upcoming Week in 4.7: August 30 – September 4 

    This is the jump-start post for the first week of the WordPress 4.7 release cycle. Many projects are still putting together pinkprints for success, so this week is all about getting 4.7 off to a flying start. 🛫

    Priority tickets this week:

    There are currently 3 tickets that require very early consideration.  Please follow them, give feedback, and help test where applicable.

    • #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
    • #37699: Death to Globals Episode #1: A Registry, A Pattern
    • #36335: Next generation: core autoloader proposal

    Core meetings this week:

    All meetings in the WordPress Slack #core channel unless specified otherwise.

    Things to do this week:

    • Meander through the wishlist comments and give feedback where you feel comfortable
    • Working on a project that you would like to target for 4.7?  Make sure to talk to @helen.
    • Schedule a bug scrub.
  • Jeff Paul 4:39 pm on August 25, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: August 24, 2016 

    This post summarizes the dev chat meeting from August 24th (agenda, Slack archive).

    4.6.1 Schedule

    4.7 Personnel and Schedule

    • @jorbin (engineering/development focus) & @jbpaul17 (PM focus) will be release deputies for 4.7
    • Full release schedule can be found at https://make.wordpress.org/core/version-4-6-project-schedule/
    • The scheduled release date is December 6.
    • Due to WCUS & US Thanksgiving holiday, we will have to treat RC as a true Release Candidate
    • There is no “merge window”, testing & feedback should be continuous before merge consideration

    Potential Focus Areas

    • Many wishlist comments are specific developer-facing features as well as better media findability/organization, easier plugin management, and the initial theme setup experience
    • New default theme (aka Twenty Seventeen) likely, but to be confirmed within the next week or two
    • REST API content endpoints (posts, terms, comment, users, and their associated meta) to get defined roadmap for 4.7 delivery plus future roadmap to full management and admin API coverage (potential approach)
      • the next meeting will be August 29 at 23:00 UTC, where this will be further discussed
      • @krogsgard aiming to write spec for each item in the list by next meeting, open to acting as PM for this focus area
      • looking for a few committers with knowledge around the API to guide the process with a permanent or lead as their buddy
      • looking for review from outside WP community
      • will require documentation coverage for builders and consumers
      • Core endpoints will need to be reviewed by their respective component maintainers

    Open Forum on Focus Areas

    • “find your media more effectively” (#22744)
    • taxonomy (aka media tagging) UX+UI work for assignment and filtering mechanisms
    • “find an accessible multi-select/autocomplete/tagging helper”
    • “smarter defaults”
    • Eliminating usability dead-ends in the customizer (#34923, #35395, #37661)
    • further refinements to the updates flow continuing from 4.6
    • low-fi mockup and testing of metabox for different publishing possibilities (including existing examples)
    • resolve some ancient annoying issues (e.g., #17817)
    • Content Authorship in Menus, with Live Preview
    • dashicons as svg sprite (Make/Core Post)
    • document dynamic hook aliases in core (finally) + adding DevHub support
    • initial theme setup experience

    Teams and Weekly Updates

    • Teams are the contributor groups that form around components and major work items (e.g. features and big API changes)
    • Will continue to identify those Teams and a “spokesperson” for each
    • Teams should have a weekly scheduled meeting and a weekly update posted to Make/Core
    • @helen to continue the tradition of weekly jump start posts, so there will be a reminder of Team meetings each week

    Wishlist Items

    Bug Scrubs

    • Everyone is empowered to run a bug scrub (can be component based, or based on any other ticket report)
    • A post with information on how to run a bug scrub and who is empowered to do it (hint: it’s you) will be published on make/core soon
    • Bug Scrubs are a great experience in running a meeting, writing good responses, and building confidence in making those do-or-punt decisions
    • You do not need to be a dev to run a bug scrub, @hugobaeta and the design team has done some great scrubs
    • You don’t need to be a committer to run them, @chriscct7 has done some incredible scrubs on ancient tickets
    • “If 5 new people that have never run a bug scrub or other core meeting before, run one this release: I will write and record a parody of “No Scrubs” by TLC, but about Bug Scrubs.” — @jorbin Π
compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar