WordPress.org

Make WordPress Core

Tagged: summary Toggle Comment Threads | Keyboard Shortcuts

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

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

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

    4.7.1 Update

    2017 Release Schedule

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

    Trac Tickets

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

    Dev Chat Summary: January 4th (4.7.1 week 4) 

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

    Schedule

    2017 Release Schedule

    • no update on the “new release schedule”, so for now it will be process as usual
     
  • Jeffrey Paul 5:30 am on January 4, 2017 Permalink |
    Tags: , , , summary   

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

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

    4.7 Retrospective

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

    General Announcements

    • Uncertain if anyone is planning on running a core dev chat next week (or any weeks going forward), so watch for agendas on Make/Core or other notifications in #core
     
  • Jeffrey Paul 3:23 am on January 4, 2017 Permalink |
    Tags: , , , summary   

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

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

    4.7 Retrospective

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

    General Announcements

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

    4.7.1 Bug Scrub

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

    Dev Chat Summary: December 7th (4.7 launch week) 

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

    Reminders

    4.7 Issues Reported

    • Caches not always clearing, not something we can fix, but seems to be the most common problem
    • Couple of reports around fatals related to WP_Hook, one traced to APC the cause of the other is still unknown
      • #39132: WP 4.7, object-cache.php breaks the site if APC is not enabled in php
    • We’re unable to pinpoint why lots of folks who meet the requirements still don’t have PDF thumbnails
      • Are there more specific requirements beyond “you need Imagik, ImageMagick and Ghostscript” perhaps specific versions?
      • Many problems so far there have been outright lack of Ghostscript installed, so having the gs info when reporting bugs would be great
      • Discussion continued on capturing ghostscript, Imagick and ImageMagick versions details via a plugin (e.g., a hidden wp-admin/debug.php, https://wordpress.org/plugins/health-check/)
    • Several reports of rest_cannot_edit and similar things from the users endpoints
    • Reports of people getting denied access to the admin area, issue appears to all be caching plugins not being cleared properly
    • #39104: Customize: starter content home menu item needs to be a link, not a page
      • This is concerning for back-compatability and needs to have a coordinated Twenty Seventeen update. The usability implications are somewhat concerning for new sites being created with 4.7.0.
    • #39146: plugin.php gives error on do_all_hook() function
    • #39150: Empty JSON Payload Causes rest_invalid_json
    • Thanks to @macmanx and @clorith and all of the people volunteering in the forums! Would be great for everyone to help answer questions in the forums, its a great way to understand the problems that users are having.

    4.7.1 Planning

    • Discussion on targeting 4.7.1 before the holidays in December 2016 or aiming for January 2017
      • Timing depends heavily on the severity and type of issue(s), and not the amount of issues
      • Target is to get close to a 4.7.1 RC by the end of the year
      • Two bug scrubs happening this week (see the Bug Scrubs reference in Reminders section above) that will give us an idea of what’s realistically close to being ready for a December release.
    • No immediate Release Lead for 4.7.1
    • Handbook reference for releasing minor versions

    4.7 Retrospective

    • We failed at getting the field guide and email to plugin dev out early though. We have aimed to have that out around beta 2 and usually end up getting it out around RC the last few releases.
    • We will post a general request for feedback on Make/Core to capture Retrospective input
    • We will review the feedback and then present it for discussion during the dev chat on December 21st and agree on action items on how we can improve in the future
     
  • Jeffrey Paul 9:46 pm on November 17, 2016 Permalink |
    Tags: , , summary   

    Dev Chat Summary: November 16 (4.7 week 13) 

    This post summarizes the dev chat meeting from November 16th (agendaSlack archive).

    Reminders

    • Dev Chat timing: Weekly chat has been moved to 21:00 UTC.
    • Schedule: Thursday, November 17th is the target for RC! RC means the list of tickets should be at zero (with the exception of the about page), as a release candidate is supposed to represent software you believe you can release. It is currently at 24.
    • Tickets:For any tickets you’ve moved into the milestone, please get these resolved in the next day.
    • Dev Notes: These should all be published this week, with a collective Field Guide forthcoming from @jorbin.

    Dev Notes / Field Guide for 4.7

    • There are a few outstanding Dev Notes, but it’s getting close. We’re waiting on the Customize summary from @celloexpressions, Media summary from @joemcgill, Starter Content from @helen, and @davidakennedy is finishing up one on Twenty Seventeen.
      • Media summary is ready to publish, was just waiting on the PDF post from Tuesday, November 15th.
      • Video Headers post could be done by @bradyvercher, but @joemcgill own making sure it happens
    • @jorbin started drafting the Field Guide, but he’s going to need to hand off finishing it off since he will be offline starting Thursday, November 17th for a week.
      • @adamsilverstein and @jbpaul17 will work to finish things up
      • @jorbin to coordinate with Adam and Jeff to sure the remaining tasks are sorted out
      • @ipstenu happy to proofread for typos and grammar.
    • @jorbin also started the discussion to ensure the email to plugin devs goes out after the Field Guide is published.  That’s a collaboration with the meta team and the pluginsrepo team.

    Release Candidate

    • @helen (thankfully) was able to move RC back from Tuesday, November 15th to Thursday, November 17th.
    • However, we’ve got 23 tickets hanging out in the report, 22 of which need to be resolved or punted in order to reach RC.
    • [Bug Scrub of remaining 4.7 tickets proceeded]
     
  • Jeffrey Paul 2:30 am on November 11, 2016 Permalink |
    Tags: , , summary   

    Dev Chat Summary: November 9 (4.7 week 12) 

    This post summarizes the dev chat meeting from November 9th (Slack archive).

    Reminders

    • Dev Chat timing: The Chat remains at 20:00 UTC.  Daylight Savings Time means that 20:00 UTC may be a different time for you already, or it may be a different time soon. However, next week we will be at 21:00 UTC.
    • Schedule: Today is the target for Beta 3! That leaves us one week until the Release Candidate, where the list of tickets must be at zero. It is currently at 32, down from 74 last week.
    • Tickets: For any tickets you’ve moved into the milestone, please make sure these are active tickets, with some kind of activity every day.
    • Bug Scrubs: @helen is running regular scrubs this week.
    • Dev Notes:  These will be compiled into the field guide this weekend.

    Bug Scrubs

    • Would like to see near daily scrubs for now until RC of report 6 and of the “Defects Awaiting Review, reported against trunk” section of report 40
    • @helen, @jorbin, and @jbpaul17 are all trying to run scrubs just about everyday, but everyone should also be scrubbing
    • Media, REST API, and Customizer component teams are all actively running scrubs as well

    Dev Notes / Field Guide for 4.7

    Beta 3

    • Likely to go out on Thursday morning instead of today, although given time zones and such we should operate on “it’s happening today” anyway
    • We are at 32 open tickets. Would love to see us get down to 20.
    • Work/tickets that folks would ideally like to resolve for Beta 3:
      • #38522: HTTP Errors on Upload with Certain PDFs
      • #38726: REST API: `unfiltered_html` and slashing: terms
      • #38672: Custom CSS should work with existing Jetpack custom CSS
      • #38541: Allow starter content to apply in a new theme when switching from another theme containing changes
      • #38660: Customizer: Edit shortcuts buttons: consider to don’t use flexbox
      • #38700: REST API: Cannot send an empty or no-op comment update
      • #38720: REST API: Updating a comment without sending content is valid, but unsupported
      • Starter content
      • Video headers

    Release Candidate

    • Please remember that with RC comes string freeze, so if you have any strings you think need to freeze, now is the time to get them in
    • We should be closing 4-5 tickets a day in order to hit RC on Tuesday.
    • Please keep testing, and working on patches.
     
  • Jeffrey Paul 7:53 pm on November 7, 2016 Permalink |
    Tags: , , summary   

    Dev Chat Summary: November 2 (4.7 week 11) 

    This post summarizes the dev chat meeting from November 2nd (agendaSlack archive).

    Reminders

    • Dev Chat timing: The Chat remains at 20:00 UTC.  Daylight Savings Time means that 20:00 UTC may be a different time for you already, or it may be a different time soon.
    • Schedule: Today is the target for Beta 2! That leaves us one week until the final scheduled beta, where the list of tickets should be at zero. It is currently at 74.
    • Tickets: For any tickets you’ve moved into the milestone, please make sure these are active tickets, with some kind of activity in the last 7 days.
    • Bug Scrubs: Can you run a scrub to help ensure tickets move forward? If you have interest in helping run a scrub and ensure tickets land in 4.7, then please reach out to @jbpaul17 or @jorbin and we’ll find a time that works best for you.

    Beta 1 Testing Updates

    • Forums-wise, an unresolved Twenty Seventeen issue that may be user error, the rest were either confirmed user error or filed in Trac
    • A couple customizer defects reported, one regarding infinite refresh and another one that relates to content security policy and Firefox which needs more reporter feedback since it is not reproducible by me. Also the edit shortcuts still have unresolved issues and maybe even need some UI changes to improve discoverability.

    Remaining 4.7 Schedule

    • Beta 2 later today. Beta 3 in a week.
    • RC comes 6 days after that – the reason for RC being on a Tuesday instead of Wednesday is because of php[world] for @helen (will be keynoting).
    • The goal is for RC to be much closer to a traditional RC (i.e. something finished and polished).  This means the final Beta should be where we are at zero open tickets besides possibly the About page.
    • An RC really should represent the state in which we believe the software could be shipped
    • The week after that is US Thanksgiving – we have the option of another RC if needed, but there may be lower activity volume as people travel and have obligations, etc.
    • Note that to ship an RC we have to be at zero tickets, though, which is less than 2 weeks away.
    • Would very much like to be able to have a video ready before WCUS (@helen has vague outline, looking for help outside of the usual WP suspects)
    • Then the week after that is WCUS – again, have the option of another RC if needed, and we should hit string freeze at that time at the latest, as many people will be traveling for WCUS.
    • Then, release on December 6.

    Dev Posts / Field Guide for 4.7

    Bug Scrubs

    • Would like to see near daily scrubs for now until RC of report 6 and of the “Defects Awaiting Review, reported against trunk” section of report 40
    • It looks like 11AM and 2PM Eastern should work each day
    • Would love to see a European and/or Australian also do some during non-USA centric times
    • We should have some scheduled stuff for people to show up if they need to schedule their time, but if you’re around and going through the report, throw up a here or another bat signal and just do one ad hoc.

    Beta 2

    • What needs to be done to get this out the door?
    • Likely to go out on Thursday instead of today
    • We are at 71 open tickets. Would love to see us get down to at least 40.
    • generally there are still enhancements (polish) going in for new features.
    • Since a lot about the REST API is about developer experiences, polishing the developer experience seems like a perfectly good thing to be doing during beta.
    • Whether it’s a bug or an enhancement in your eyes is not the important criterion – it’s about whether it’s a part of what you believe a polished set of REST API endpoints should be when you ship them.
    • Tickets to folks would ideally like to resolve for Beta 2:
      • #37032: Guard against infinite reload when setting change causes premature selective refresh
      • #38543: Twenty Seventeen: Firefox 49 renders site name & description off screen.
      • #38532: Customizer: Edit shortcuts buttons: clicking does not work in Firefox
      • #29158: Customizer UI Design lacks contrast for visual hierarchy and does not match wp-admin
      • #38420: API Post status parameter does not accept multiple values
      • #38609: REST API should honor the `unfiltered_html` capability
      • GitHub Issue #2848: Avoid use of wp_filter_post_kses to prevent lossy slash handling
    • Additional items needed for Beta 2 are a news post for .org and a haiku
     
  • Jeffrey Paul 6:47 pm on November 2, 2016 Permalink |
    Tags: , , summary   

    Dev Chat Summary: October 26 (4.7 week 10) 

    This post summarizes the dev chat meeting from October 26th (Slack archive).

    Reminders

    • Schedule: Today is/tomorrow will be beta 1 day. This means: no more enhancements and feature requests open for 4.7 (this sometimes means things with initial commits become “tasks”), and then from here on out we only work on bug fixes. It should be noted that bug fixes in this context are a little broader than what you’d call a bug fix in a bug tracker – it includes polish for new features. Typically that means UI and UX polish, but of course UX includes dev UX.
    • Tickets: There are currently 83 tickets in the 4.7 milestone. This is 27 fewer than last week. 🎉However, in just 3 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 7 days.
    • Bug Scrubs: Several scrubs have been / are planned for this week. Scrubs remaining this week are planned for Thursday, October 27th 9:30am CDT for 2.5 hours and Friday, October 28th 9:30am CDT for 2.5 hours. If you have interest in helping run a scrub and ensure tickets land in 4.7, then please reach out to @jbpaul17 or @jorbin and we’ll find a time & scrub focus that works best for you.

    Remaining Feature Requests and Enhancements

    • #27159: Removing TinyMCE buttons to improve user experience
      • Closing this as fixed. Bugs can go in new tickets.
    • #36211: TinyMCE: allow pasting in image captions
      • This is something that needs testing attention but doesn’t actually need to be open. Closing that too.
    • #38488: Twenty Seventeen: Replace remaining Genericons with Font Awesome icons
    • #38502: TwentySeventeen: unnecessary l10n variables
      • Both of these Twenty Seventeen are likely bugs, will re-classify them.
    • #38490: Add settings to the /wp/v2/settings endpoint that are in the WordPress.com api
    • #38504: Term query endpoints should use WP_Term_Query
    • #38342: Quick Draft: Leverage REST API endpoints
      • Another lingering thing around beta 1 is the request that something in core leverage the REST API – there’s some discussion around this going on in #core-restapi.
      • REST API team will put feedback on the Quick Draft ticket with our thoughts on these questions.

    Defects and Tasks

    • #26601: Inappropriate content in headings on admin screens
      • The main H1 headings in the admin screens contain stuff that shouldn’t be there (“Add New” button, search string text, in some cases even the search input field). Headings should be just headings and all that stuff should be moved out from them.
      • The latest patch a proof of concept on just 2 screens, trying to find a way to proceed step by step and (hopefully) avoid any breakage.
      • “Being able to do it one instance at a time will make it much more manageable, so that we could hopefully get it started in 4.7 and completed in 4.8.” — @joedolson
      • We need some eyes on the patch, to see if the new approach is good enough and check for any potential layout breakage.
      • We’d like to hear if there’s consensus to merge it in core now, thinking that beta is maybe the best way to test it (it can be reverted at any time). If/when merged, some testing and comments on the ticket would be very appreciated too.
    • #38378: Remove the `filter` parameter in the Post Controller
      • Exposing filter as a shim for WP_Query provided useful functionality that’s still unsupported by the “first-party” API query parameters (complex date queries for example), at the expense of a very broad back-compat surface we then need to maintain.
      • We long ago decided not to extend filter-like shims on other endpoints; for consistency we had proposed removing it everywhere. But it’s been around since < v1, and removing it will be a more breaking change for integrating developers than anything else in the 4.7 REST API.
      • So the question is: remove, or keep in and live with it?
      • This is really about supporting people who have built stuff on v2. If people were not already using it, we’d remove it and just recommend the use of the top level args like `?per_page=x`, so for me, it’s a question of supporting those existing users.
      • Agreed approach will be 1: remove filter from core; 2: make sure it’s in the plugin, and make sure the versions play well together; and 3: throw doing_it_wrong.
    • #38494: WP REST API: Stale Post Status on DELETE of Post
      • What happens when you DELETE something is pretty inconsistent. When you delete a revision, you just get true. When you delete a category or tag, you have to specify force=true or you get an error.
      • Agreement: this something we’re comfortable discussing & addressing later.
    • #38114: Make it easier to visualize where to put your content in a given theme (aka “dummy content”)
      • This is marked as a task, but really needs a first commit before beta 1.
      • No existing code yet and getting a commit before beta 1 seems like a stretch.
    • #38172: Enable Video Headers in Custom Headers
      • This is marked as a task, but really needs a first commit before beta 1.
      • Video headers is close to being ready for an initial commit, with adjustments to come in beta.
      • There are a couple of quick tweaks we can make like making them only show on the front page in the core output functions, for example.
      • The late push on video headers has been fantastic, but it needs more eyes and testing.
      • The biggest concern is file size, and increasing page file size for a large amount of users.
      • Not loading video on screens narrower than X, only showing video on the frontpage, adding classes to the output markup for themes would be quick fixes we can make right away.
      • By having it in Core, it encourages themes to do it in a preferred way. And more importantly, provides consistent UX in the Customizer for users from theme to theme.
      • @celloexpressions to work on revised patch, @joemcgill to review for commit
    • #38387: Twenty Seventeen: Keyboard navigation on Safari 10
      • We would appreciate some other testing this patch; its been tested, but could use some more eyes on it.
     
  • Jeffrey Paul 4:00 am on October 20, 2016 Permalink |
    Tags: , , summary   

    Dev Chat Summary: October 19 (4.7 week 9) 

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

    Reminders

    Dev Notes / Field Guides

    • In general, if you worked on something that needs to be called out for testing or building upon, there should be a post about it.  These are all tagged as `dev-notes` on the Make/Core site.  The target is everything written before beta 2 so we can get a field guide summarizing them and an email sent to all plugin developers while we are still in beta. In general all active components should have at least one post about what has changed.

    Final Merge Decisions

    • Twenty Seventeen (@davidakennedy)
      • Merge Proposal & Trac ticket
      • 59 contributors. Merging later today.
      • There are 34 issues left, some of which will be moved to Trac. There are 0 pull requests left.
      • A code review was performed by @aaroncampbell, and he didn’t find anything that should hold up merge.
      • Theme does not depend on any core features being merged before/at the same time, but will greatly benefit from any completed.
      • Video headers (#38172) needs consensus on the best approach and testing of functional patches
      • Merge proposal accepted. 🎉
    • REST API: Content API (@kadamwhite)
      • Merge ProposalSuccess metrics
      • 99 contributors. 25 merged PRs in the past 3 days. 27 issues left in the current milestone and a few stray PRs, which will be closed out shortly or moved to Trac.
      • Monday meeting in #core resulting in conditional merge approval
      • Conditions:
        • 1) 4.7: Press This / Quick Draft Core feature (#38343 and #38342)
        • 2) 4.7: Object / non-single level meta. @joehoyle, @jnylen and others have been working on this, tracking via GitHub.
        • 3) 4.7: Define success metrics (see link above)
        • 4) 4.7: Continuing to ensure the API forward compatibility (EVERYONE should be building things with it).
        • 5) 4.7: Review .com API settings discrepancies, determine how to resolve or where to document. @joehoyle, @jnylen and others have been working on this; Progress/documentation.
      • WP-API is code-frozen at this time; open enhancements will be ported over by @rachelbaker as appropriate.
      • Merge proposal accepted (“Let’s do it.”). 🎉

    Components and Other Enhancements

    • i18n (@swissspidy)
      • Nothing newsworthy from the i18n side which isn’t already on Make/Core.
    • Make it easier to visualize where to put your content in a given theme (aka “dummy content”)
      • If there are people out there interested in content writing and stuff like customizer integration, hit up @helen.
    • Media (@mikeschroder, @joemcgill)
      • We’re working on trying to get #31050 (Better PDF Upload Management) into shape for commit this week. Still some issues to iron out, but it’s getting close.
      • I want to call out that we’ve removed the automatic fallbacks for generating `alt` attributes from images with consultation from the a11y team to improve the user experience for screen readers. See: #34635 for details.
      • We have a few other things we’re looking at this week, but if there is anything pressing that needs eyes specifically from someone on the Media team, please reach out in #core-media.
    • Customize (@westonruter, @celloexpressions)
      • Remaining three major 4.7 feature projects merged in the last 24 hours.
      • #27403 and #38164 are our larger remaining tickets needing attention currently, with #29158 and #22058 pending final patches for review and discussion.
    • Editor (@azaozz, @iseulde)
      • TinyMCE: allow pasting in image captions (#36211) needs some more testing
        • Add an image in the editor, add a caption, then try pasting different things copied from another web page in it. This makes some assumptions of what the user expects, and what should happen, i.e. when pasting an image into a caption it should remove the image but let the text in, or keep all that is pasted but move it under the caption?
     
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