Dev Chat Summary: April 12th (4.7.4 week 6)

This post summarizes the dev chat meeting from April 12th (agendaSlack archive).

4.7.4 Planning

  • There are currently 23 open tickets in the milestone
  • We had been aiming for an early May release, but an annoying bug (#40305, noted by @azaozz) related to TinyMCE and the upcoming Chrome release has forced us to reevaluate this strategy
  • After talking to Andrew and the security team, we decided on a new release date for WordPress 4.7.4: Tuesday, April 18, with April 20 as a fallback.
  • There will likely be an additional 4.7.5 release soon after this one

Customize Team

Editor Team

  • We’re in the long stretch of building and building, so we’re also holding “office hours” instead of weekly meetings.

REST API Team

General Announcements

  • @helen is going on leave after Friday, April 14th until August (probably 2017) (hopefully she meant 2017) (is it August yet?)

#4-7, #4-7-4, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Editor Experience Survey Results

The Editor Experience Survey results are in! There were a total of 2,563 responses which were gathered anonymously through PollDaddy. There was a big focus on asking multiple choice questions to keep the survey manageable. I tried to provide images where relevant and ask actionable questions as I could.

Thanks to: @iseulde, @karmatosed, @melchoyce, @joen, @designsimply, @azaozz, @chanthaboune, @samuelsidler, @codebykat and many more for helping me organize this survey.

Let’s jump in.

How do you use WordPress?

This question was pulled from the annual WordPress survey which helped reveal the backgrounds of the respondents. I was hoping for a more diverse group from a variety of backgrounds using WordPress, but this sampling should provide decent insight. Keep in mind that respondents were allowed to answer more than one.

Developers clearly dominated the survey. Because of this, I wanted to break this stat down a bit more. This chart displays each category outside of “Developer”. The blue represents the amount of respondents that selected that category, but did not select “Developer”. The red represents the amount of respondents that chose “Developer” plus that category.

The total respondents that selected “As a Developer” in this survey was 1,703 out of 2,563 total responses.

How often do you use the Editor?

This questions was written in an effort to make sure the results were from respondents that used the Editor. As can be seen, 89% use the Editor weekly or more.

Do you use the markup text Editor?

Is the Text Editor an important part of people’s workflow while using WordPress? It was interesting to see that over 85% of respondents use the Text Editor sometimes or more.

“Only one wish: please don’t remove the plain text/mark-up editor.”

 

“I’m a huge fan of the text editor. I like the ability to use raw html when necessary.”

 

“Would really appreciate syntax highlighting in text view.”

 

Do you use the markup buttons?

While a vast majority of respondents use the Text Editor, almost half never use the markup buttons.

Do you use the distraction free writing mode?

The distraction-free writing mode seems to be often overlooked or just ignored in the respondent’s flow when using the Editor. Could it be that the button to initiate the distraction-free writing mode is a distraction itself?

“I love the distraction-free writing option but wish it offered a wider column for editing purposes and easy size-adjusting for easier reading/editing.”

 

“I like distraction free mode when I remember it’s there. Would be cool if choosing to edit a post/page from the front end invoked something like distraction free mode as a modal overlaying the page, allowing for quick editing and committing.”

 

“[Would like] better Distraction Free (not just hiding surrounding menus, but expanding the actual text area)”

 

“I like the distraction free mode a lot. It makes it easier to write directly in the editor in a clutter-free way.”

 

“‘Distraction free’ is depressing due to the large gray area and limited writing space for desktop.”

 

“Distractions free mode is an utter joke.”

 

“Would like to see a full screen version. Distraction free just removes the menus, full screen would allow the menus on top and bottom but still give the complete screen width.”

 

“I wish the distraction free mode was how it used to be with bigger fonts and centered.”

 

Installing plugins that added features to the Editor

Exploring these questions might help reveal which features respondents are looking for in the Editor itself. The majority answered that they had installed plugins to add features. The most common features are graphed below.

Current Editor ease-of-use and organization

On a scale of 1 to 5 (5 being Very Easy or Very Organized), the majority of respondents found the current Editor’s ease-of-use and organization to be sufficient or better.

Editor Accessibility

105 respondents use a screen reader. 94 of those people feel the screen reader experience is sufficient or better. Other assistive technologies used by the respondents include: On-screen keyboards, alternative input devices like wands & sticks, voice recognition programs, screen enlargers, text to speech synthesizers, and braille embossers.

 

Some quotes from the survey question about accessibility issues with the Editor:

“You need to add more notifications for screen reader when somethings change on the page.”

 

“I reached and pressed the Publish button and forgot that there are meta boxes after that. So then I had to fill up the category and tags then shift + tab to go back to Update the post.”

Is there anything in the Editor you never use?

I was hoping to discern some of the less used items in the Editor. This question is not intended to provide for support for eliminating any elements within the Editor, but rather to help with visual hierarchy in the new Editor. By far, the main element never used was the “Text color” dropdown, followed closely by the “Special character” button, the “Insert Read More tag” button, and the “Distraction-free writing mode” button.

Is there anything else about the Editor you’d like to share?

The last question yielded 37 answers. I’ve pulled a few interesting ones below.

 

“Please make the editor to seems as an a4 paper it is best for authors :)”

 

“Add a no follow option in the link editor.”

 

“I’d like to see the bullet points/numbers to go along with the text if I increased or decreased indentation.”

 

“Would be way better if you could edit directly on the site instead of having to open the dashboard and find the content somewhere there.”

 

“Better implementation of shortcodes would be a real benefit.”

 

“I would like that to see an easier way to bring the cite tag to the editor to use with blockquote.”

 

“Wish there was better support for content columns.”

 

“I would love much better WordPress support for writing in various apps and then posting to WordPress. […] In particular I’d like to see it in a lot more text editors / note taking apps, […]. Writing in a web page in a browser is never going to be comfortable, or at least never as comfortable as a “native” experience, so I recommend focusing on letting people use the native experiences with which they’re most comfortable.”

 

Conclusion

The Editor Team is working hard on redesigning the Core Editor experience to be something WordPress users could enjoy using daily. If you feel anything important was not represented in this survey, please comment below. If you have any feedback regarding the results or future work on the Editor, please feel free to comment as well. I look forward to the improved Editor experience in Core!

 

 

 

#core-editor, #survey

Dev Chat Summary: March 29th (4.7.4 week 4)

This post summarizes the dev chat meeting from March 29th (agendaSlack archive).

4.7.4 Planning

  • There were only 35 open tickets in the milestone at the time of the meeting.
  • 2 bug scrubs over the last 2 weeks helped close a lot of those open tickets.
  • The release is still on schedule for the first week of May, but a few more bug scrubs are necessary.
  • If you have owned a ticket, please help test it!
  • Next bug scrub will take place on April 3, 2017 at 17:00 UTC. @stevenkword offered to help.

Editor Team

  • Nothing in particular to discuss this week.
  • Work continues on the editor feature plugin.
  • Day to day discussion and work happens in the #core-editor Slack channel, and the Gutenberg GitHub project.
  • Help testing, feedback, and contributions are welcome in both places.

REST API Team

  • No updates this week.
  • Work continues in the #core-restapi Slack channel.
  • There are some component tickets in the 4.7.4 milestone that will hopefully be closer to merge this week.

Core team reps

Open Floor Items

  • @dlh brought up #36188
  • @stevenkword brought up #20899
  • Both requested additional eyes, and people to test the fixes. Both offered to trade tickets and test.

#4-7, #4-7-4, #community-summit, #core-editor, #core-restapi, #dev-chat, #summary

Dev Chat Summary: March 22nd (4.7.4 week 3)

This post summarizes the dev chat meeting from March 22nd (agendaSlack archive).

4.7.4 Planning

  • Moving dev chat back an hour to 20:00 UTC starting with next week’s chat (due to DST)
  • That makes next week’s meeting at Wednesday, March 29, 20:00 UTC
  • Bug scrub planned for Thursday, March 23, 15:00 UTC to review tickets in 4.7.4 milestone, likely tackling needs-patch tickets first
  • Tentatively aiming for first week of May for 4.7.4 release, but will adjust as bug scrubs determine what needs to / should land in 4.7.4

Core team reps

  • Still looking for nominations for a Core team rep
  • Core team reps need to plan to be at the Community Summit and can take on organizing topics and people
  • @logankipp planning to be at the summit, open to helping; will tag him as Core team rep, but would like to find one more person to help
  • Please comment or contact @jbpaul17 directly if you’re planning to attend the summit and can help organize topics/people for Core

Editor team

  • Moving into feature plugin phase with Gutenberg, looking for and greatly appreciate contributions and feedback to the GitHub repo
  • Lots of discussion ongoing in the GitHub repo (e.g., Plugin: Implement block registering API), so please follow along and chime in
  • Will proceed on Gutenberg without support for older browsers
  • Will start surfacing things that may need broader discussion in how we use JS, what tools we develop, etc.

#4-7, #4-7-4, #community-summit, #core, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Dev Chat Summary: March 15th (4.7.4 week 2)

This post summarizes the dev chat meeting from March 15th (agendaSlack archive).

4.7.4 Planning

Browser support

  • Additional dev chat earlier today on topic of Browser support (Slack archive)
  • After some discussion, we arrived at the following strategy.
    • A “text” editor available to everyone is the best fallback – the new visual editor will leave old browsers behind.
    • Some form of the current version of the editor can be packaged into a plugin. Sites with users requiring a more advanced editor experience for older browsers can install this plugin.
    • The WordPress admin screen will display a notice of some sort to users with older browsers explaining the changes and how they can install the plugin for the experience they were used to (possibly utilizing BrowseHappy).
    • The editor team will use their research for the new editor to determine which buttons need to remain in the “text” editor with support for older browsers.
    • A more general discussion about browser support policies is slated to be had at the Community Summit before WordCamp EU. But this discussion can start before that (@jorbin is working on a Make post to start that conversation).
  • Any additional feedback from anyone who could not attend then is welcomed!

Core team reps

  • Last week we had nominations for @jorbin and @afercia.
  • Core team reps need to plan to be at the Community Summit and can take on organizing topics and people
  • @afercia not currently scheduled to be at summit, but would like to
  • Please comment or contact @jbpaul17 directly if you’re planning to attend the summit and can help organize topics/people for Core

Customize team

REST API team

  • Day of REST event was successful, but delayed continuing bug triage, will pick back up on 4.7.4 to make sure we keep solving the critical pieces
  • @jnylen0 & others resolved issue with tests & daylight savings time
  • due to bandwidth the existing REST API contributor group is fully occupied with the API itself
  • existing REST API contributor group have neither the bandwidth nor the domain expertise to also be leading the WP Admin implementations that will consume the REST API
  • @adamsilverstein lead the charge with Quick Draft, and work has begun in several parallel channels, but as of right now there’s nothing that appears to have momentum
  • We need help to drive adoption of the REST API within WP Admin, please come chat in #core-restapi any time
  • We need more explicit awareness of how the other feature teams want to use the REST API, or volunteers to lead separate implementations to move away from admin-ajax where it introduces inconsistency
  • If you’re not able to lead the separate implementations, then please chime in on component tickets as they’re opened to help us triage the pain points

General announcements

  • PHPunit tests (#39265: Missing @covers and @uses in the comments block in phpunt test for wordpress)
    • @pbearne: I am trying to do is get support to have @cover and @uses required for PHPunint tests
    • @pbearne: Willing to work through the old tests to add the missing comments
    • @pbearne: I would like to propose that we require for all new / updated tests and that the code committers commit updates with these added ASAP
    • How would we use that information going forward?
    • @pbearne: add to WordPress.org as way of show code quality and tell how well we are doing
    • What would be a realistic number we’d want to achieve?
    • @pbearne: anything over 80%
  • If you use the editor, please look to complete the Editor Experience Survey.

#4-7, #4-7-4, #community-summit, #core, #core-customize, #core-editor, #dev-chat, #summary

Editor Experience Survey

As you’re well aware, a project is underway with the focus on redesigning the editing experience in the wp-admin. As the project moves forward, a better understanding of how WordPress users actually feel about the editing experience is needed. Please take a few minutes to fill out this survey and help influence the future of your favorite CMS, WordPress.

Survey Link:

http://wordpressdotorg.polldaddy.com/s/editor-survey

+make.wordpress.org/design

 

#core-editor, #design, #survey

Dev Chat Summary: March 8th (4.7.4 week 1)

This post summarizes the dev chat meeting from March 8th (agendaSlack archive).

4.7.3 Update

4.7.4 Planning

  • The release lead for the next regularly-scheduled minor release (currently versioned as 4.7.4) will be @swissspidy.
  • Timeline tentatively set for April-May 2017, but we’ll have to get into bug scrubs and work with @swissspidy on an actual timeline for 4.7.4 as time goes by.
  • Just like 4.7.3, the timeline may change and will be highly dependent on how triage get tickets goes.

Browser support

  • @desrosj graciously compiled a summary of the discussion along with stats –> The New Editor and Browser Support
    • The overwhelming developer sentiment in the comments was for dropping support. A handful of people expressed that we did not have a full list of pros for dropping support.
    • But there was not as much discussion as I would have liked comparing the three potential fallbacks mentioned in the post, and no new potential fallbacks were mentioned.
    • I think if a solid, workable fallback that everyone is comfortable with can be decided on, then making the decision to drop support would be made a lot easier.
    • Dropping support for lower versions of IE could impact up to 2m WordPress users on the high end.
  • Discussion continues on a follow-up post –> Continued Discussion on Browser Support
  • There will be an additional dev chat this week to further discuss the fallback strategy to be used if support is dropped for older browsers. This chat will take place on March 15, 2017 at 12:00 EDT.

Core team reps

General announcements

  • A11y: #35566 to replace widget, create new widget, or other option from @afercia
    • A couple proposals on the ticket. Some work was done on them also at WC Europe.
    • We’ve discussed this issue during last accessibility bug-scrub on Monday and thought to bring it to everyone’s attention.
    • Before moving on, we’d like to:
      • see if there’s consensus in removing the title attributes there
      • and most of all, get feedback and recommendations about the best path forward, especially from people who have more experience than the a11y team has in managing backwards compatibility issues
    • As “tooltips” can be a controversial topic so the second proposal doesn’t use them
    • Looking for input on the best option: Deprecating the old widget and introduce a new one? Just replace the current widget? Or something else?
  • #39377: wpautop adds a extra </p>
    • @pbearne looking for dev-feedback, input from @azaozz
  • In a minor release we can consider string changes in moderation and for core focuses only, but we’d need a string freeze two weeks prior.

#4-7, #4-7-3, #4-7-4, #community-summit, #core, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Dev Chat Summary: March 1st (4.7.3 week 5)

This post summarizes the dev chat meeting from March 1st (agendaSlack archive).

4.7.3 Schedule

  • Reminder of plan to release 4.7.3 as bugfix and maintenance release on Monday March 6, 2017
  • RC is available so please test

Community Summit

  • Working to review submissions on Planning for Community Summit 2017 post on Make/Core as well as submissions to the Make/Summit team via the Community Summit 2017: Sign-up Request post
  • Between now and Friday, March 5th the Core team needs to come up with:
    • 1) a list of topics for the summit
    • 2) A list of representatives to attend the Community Summit
    • 3) One or two contributors who are willing to help with the organization of the event
  • “participating” generally means being physically present for the discussions in Paris, France days prior to WCEU this summer for the Community Summit
  • Each topic facilitator will do both a pre-summit and post-summit Make/Core post. @jbpaul17 to confirm timelines with @_dorsvenabili to help prep those facilitators for those post timings.
  • Javascript in core [will submit to CS]
    • “what we hope and imagine for the future with the REST API, and how we hope to get there… what we have in core now and how we can improve it and how we can attract more JavaScript first developers to build on WordPress and especially contribute to core… How the REST API relates to wp-admin.” Submitted by @adamsilverstein to attend and volunteer to help in whatever role is most helpful.
    • “REST API admin usage: Where we can start moving things to using the API (and maybe even get a couple of them done at the summit)” Related submission from @chriscct7, recommended to include @rmccue
    • @kadamwhite: A heavy dependency on “the future of JS in core” and that discussion should originate from the broader WP community, not be mandated by the REST API group
  • Technology version support policies [will submit to CS]
    • @jorbin: (versions of PHP, MySQL, Browsers, Screen Readers, other AT, etc.) Let’s come up with some concrete plans for when we intend to deprecate things and how we want to handle it. People Who would be good to have in this discussion: @dd32 (to help with stats) @pento (to help with messaging) @afercia and @rianrietveld ( to help formulate AT support policies if they don’t exist already), @westonruter ( as maintainer of the largest JS component) @azaozz ( as maintainer of tinyMCE component) @matveb ( as dev lead of new editor)
    • @getsource, @boonebgorges, and @matt as additional reps for this topic
  • Improved management of contributors with time to spare [will submit to CS]
    • @johnbillion: This topic is particularly focused on pre-existing contributors who are paid to contribute to WordPress (eg. those whose time is sponsored by their employers), but also pre-existing contributors who aren’t sponsored but who do want to contribute a significant and/or consistent amount of time, and also potential contributors in a similar position.
      As a project, we need to manage these people’s time much better. These people need to be project managed in one way or another to avoid repeats of situations we’ve had in the past where a contributor is literally being paid to fix things in WordPress and the project is failing to enable them to do so effectively, or even at all. I’d (@johnbillion) like to attend the summit, and I’d be happy to jointly lead this discussion with someone who has good project management experience and some ideas about how WordPress might be able to better manage contributors, but at the same time do it in such a way that retains the fun and interesting aspects of contributing without turning it into something that too closely resembles “work”. [Side note from John: Worth noting that this doesn’t only apply to core, but it’s a good place to start.]
    • @helen did a survey of time availability a while ago, sent list to John to use for this topic
    • @aaroncampbell, @getsource, @jorbin, @boonebgorges, and @logankipp as additional reps for this topic
  • On-boarding experience for new contributors [will submit to CS]
    • @joemcgill: Lots of people who want to get involved have no idea where to focus their efforts.
    • @kadamwhite: Speaking for myself this is hugely related to the future of JS in core and the REST API, since those pieces really need the energy new contribs would bring
    • @getsource: I am willing to participate or lead, although I don’t know what leading it means besides guiding conversation at this point. @aaroncampbell also willing to lead.
    • @peterwilsoncc, @flixos90, @logankipp, @jorbin, @johnbillion, and @stevenkword as additional reps for this topic
  • Communicating changes to WordPress Core [will NOT submit to CS]
    • @jorbin: For the past few years, core has produced a field guide and worked with the meta and plugins team to email plugin others about changes to core. Each release though triggers a number of people who don’t know about changes until after the release. Challenge: How can we help ensure changes that aren’t worthy of user marketing promotion are known by a far greater percentage of WordPress developers?
      Might also impact or benefit from input from +make.wordpress.org/plugins +make.wordpress.org/themes +make.wordpress.org/marketing +make.wordpress.org/meta.
      Even when we get the field guide out on time, issues come up post release.
      two ideas:
      1) Translating the field guide (is this reasonable if the posts that it links to aren’t translated?) Also means polyglots should be in the discussion
      2) Using the new release email mailing list to announce RC
    • @helen: I think it’s worth at least starting the conversation earlier, even if it ends up still being valuable to continue something in person.
    • @desrosj: There may also be some great ideas from people who cannot attend in person. It would be a great opportunity for them to have their ideas heard and contribute, even if they are not able to follow through with the discussion in person at the summit.
    • @jorbinI’m going to withdraw the communication topic as my proposal for the summit with the note that I might want to resubmit it depending on how the virtual discussion goes
    • @azaozz and @sergey as additional reps for this topic
  • Security [will submit to CS]
    • @chriscct7: The process of a security ticket from report through triage through disclosure. Aaron Campbell (security czar) has made it clear this needs to be discussed at some point and I feel like the community summit would provide a good venue as many of those on the team will be there in person and we can mirror the conversation easily for those who are not. Recommend including @aaroncampbell
    • @aaroncampbell: This is actually a good idea, although I don’t think it’s because “those on the team will be there” but rather because I’d love to get input from some other people too, and security is generally sensitive enough that a place like the summit seems useful
    • @rmccue, @kadamwhite, @matveb, @joen, @westonruter, @melchoyce as additional reps for this topic
  • Collection of Anonymous data [will NOT submit to CS]
    • @chriscct7: If core is interested in doing it, I think my experience with doing it for a trac ticket (settings reduction) might prove to be useful to add to the discussion. Recommend including @drewapicture
    • General agreement to NOT include this topic since this is currently opt-in and the issue is finding an owner of this topic
  • Bootstrap/Load [will NOT submit to CS]
    • @schlessera: Opening up the WordPress Core Architecture to make it flexible enough as a platform so that it can:  * serve both novice end-users as well as large-scale enterprise installations in an optimized way;  * quickly adapt to changing external requirements, to keep up with the accelerating pace of the web. Recommend including @rmccue
    • General agreement to NOT include this topic since it does not need to happen in-person, already has discussions underway, and should be scheduled in next couple of weeks
  • Code editor [will NOT submit to CS]
    • @georgestephanis: Code Syntax Highlighting implementation and accessibility concerns — how we can get CodeMirror or whatever better library there is implemented and rolled out for both Customizer Custom CSS, Theme/Plugin Editor, and Content Blocks. Recommend including @afercia @westonruter
    • General agreement to NOT include this topic since it does not need to happen in-person and should happen sooner than the CS.
  • REST API authentication [will NOT submit to CS]
    • @georgestephanis: Third-party authentication with the REST API.    Between OAuth 1.0a, OAuth2, central application brokers, Application Passwords, or some other system — there’s a lot of possibilities here, and it’d be really nice if Core could pick something and move forward with it before folks start spoofing cookie authentication in applications to integrate with core.
    • Relevant chat summary from the last time we had one
    • This really needs an owner, otherwise it’ll continue to be punted. There’s fundamental differences on what the direction should be.
    • @samuelsidler: I don’t think core can decide until someone has documented the possible options, along with their strengths and weaknesses, then had some discussions on what would be best for core and why.
    • @georgestephanis, @rmccue, @logankipp volunteered post on Make/Core to move this topic along
    • We will table this idea and maybe propose it for the summit based upon how the near term discussions go
  • Front-end Editing [will NOT submit to CS]
    • @westonruter: Frontend editing powered by bootstrapping the customizer onto the frontend, with inline direct manipulation of elements on the page and the controls sidebar being lazy loaded to slide in from the left as needed. Editable elements include post content and site configuration (sidebars, menus, options, etc). Recommend including @celloexpressions
    • General agreement to NOT include this topic since it depends on too many other things we won’t know by then, so we will pass on that topic (at least for now).
  • Nextgen Widgets [will NOT submit to CS]
    • @westonruter: Next generation of widgets which harmonize with content blocks in the editor.
    • General agreement to NOT include this topic for the CS, but good conversation for the contributor day.
  • Feedback on Core focuses [will NOT submit to CS]
    • @georgestephanis: Six months in, how are we feeling about shifting away to a more top-directed set of focuses for the year?
    • General agreement to NOT include this topic as it’ll be hard to say until/unless we’ve shipped a core release by then (we likely won’t) and is a conversation that should happen in public.
  • Complete list of representatives nominated to attend the Community Summit: @matt, @nacin, @adamsilverstein@rmccue@kadamwhite@chriscct7, @dd32@pento@afercia@rianrietveld@westonruter@azaozz@matveb, @getsource, @boonebgorges@aaroncampbell, @jorbin, @logankipp, @peterwilsoncc, @flixos90, @johnbillion, @stevenkword, @azaozz, @sergey, @karmatosed, @joen, @westonruter, @melchoyce, @jnylen0, @ipstenu, @joemcgill, @joehoyle, @rachelbaker, @michael-arestad, @petya, @danielbachhuber, @ocean90, @samuelsidler, @afercia@desrosj, @iseulde, @jjj@celloexpressions
  • We’re still searching for 1-2 contributors who are willing to help with event organization, so please comment here or reach out to @jbpaul17 if you’re interested
  • @jbpaul17 will send the Core team responses to the Community Summit team by Friday, March 3rd.

Browser support

  • Please take a look at @desrosj’s post: The New Editor and Browser Support
  • This will be a topic of discussion at next week’s devchat.
  • Please leave your thoughts there as comments, and bring them along next week as well.

#4-7, #4-7-3, #community-summit, #core, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Dev Chat Summary: February 22nd (4.7.3 week 4)

This post summarizes the dev chat meeting from February 22nd (agendaSlack archive).

4.7.3 Schedule

  • Planning to release 4.7.3 on Monday March 6, 2017.
  • This will be a bugfix and maintenance release, nothing major.
  • Latest view of what’s in/coming in 4.7.3: Trac report
  • This date is coming up pretty soon.  Ideally anything going into 4.7.3 would already be in trunk.  So please make your remaining commits ASAP.
  • Aiming for a code freeze and release candidate either Friday, February 24th or Monday, February 27th
  • Bug scrub planned for February 24, 19:00 UTC in #core

Customizer team update

  • Looking for help on testing the Media widget (#32417: Add new core media widget) as well as proposal for a minor release
    • There will be a Translation need for this widget
    • @westonruter: I’ll do final touches on the patch via the GitHub PR to avoid stepping on each other’s toes and to run the builds. If you have anything to add to the patch, please push to the feature branch. Otherwise, I’ll manually re-sync new patch changes to the PR.
    • Additional tasks to see this land in a release:
      • 1) Search for plugins and communicate with them [@ipstenu to help]
      • 2) Test and try to break the patch in it’s current form [@jnylen0 to help]
      • 3) Confirm Forums response to the question: “why didn’t you ‘just’ use {{my existing widget}}”?
      • 4) If you have a widget that does similar things, try out compat and/or extensions [@helen to help]
      • 5) Make sure that it looks good in all default themes [@jnylen0, @melchoyce to help]
      • 6) Consider whether the widget should be extendable for plugin authors to add new types [@helen to help]
    • Likely means this won’t land in 4.7.3, but will target an upcomming minor release

Editor team update

  • Looking to continue discussion on browser support, no need for an urgent decision, but there’s been some discussion that core devs might want to be aware of and review. The current Plan B is to include an old version of TinyMCE for the browsers that will not support the new one.
  • Related post with more detail: A quick guide to browser selection models
  • A lengthy, pro/con discussion ensued. @desrosj is working to summarize everything from the conversation, will add some browser stats, and post to Make/Core for the discussion to continue
  • If you have statistics that you feel will be valuable to look at, please to send it to @desrosj and he will try to include it in the conversation summary for further discussion

REST API team update

  • The REST API team has no significant updates since last week.

Trac tickets

  • set of tickets with patches from @mte90 that are looking for review. If someone out there has some time to go through any of these for review/feedback that would be appreciated.
  • #16778: wordpress is leaking user/blog information during wp_version_check()

Community Summit

  • Between now and next Friday, the Core team needs to come up with:
    • 1) a list of topics for the summit
    • 2) A list of representatives to attend the Community Summit
    • 3) One or two contributors who are willing to help with the organization of the event
  • See also: Community Summit 2017: Sign-up Request
  • @jbpaul17 posted to Make/Core request to capture input on the three items above, will capture that input and summarize for review in next week’s dev chat, and then send the Core team response to the Community Summit team by next Friday, March 3rd. Please review the post on Make/Core and respond with your input.

#4-7, #4-7-3, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Dev Chat Summary: February 15th (4.7.3 week 3)

This post summarizes the dev chat meeting from February 15th (agendaSlack archive).

4.7.3 Schedule

  • Completed first pass on all tickets in the 4.7.3 milestone, @jnylen0 is reviewing those that “need” to land in 4.7.3, and identifying a release date for 4.7.3 in the coming week

Customizer team update

  • #23601 (Use ACE Code Editor for Theme and Plugin editors) and #12423 (Include Ace (or similar) as default code editor)
    • Topic of discussion is a code editor library to be used in Custom CSS, WP content editor HTML view, file editor, and any other place that code is modified
    • Had planned to go ahead with CodeMirror since it is what Jetpack uses in its Custom CSS module, but @afercia pointed out accessibility problems
    • So we’re looking for insights into best of breed accessible code editor libraries
    • @afercia: looking to to understand if (1.) there’s consensus about introducing some sort of syntax highlighter library (plus other functionalities) and (2.) if it is going to completely replace the current WP content editor HTML view
    • @jorbin: Once one is decided upon, would like to encourage reaching out to the project maintainers and opening a dialogue about things like security and backwards compatibility
    • @helen: each area (Custom CSS, WP content editor HTML view, file editor) needs individual consideration and rationale
    • Goal is to provide a better user experience for when users edit code in WP
    • Custom CSS:
      • #38707: Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out
      • @westonruter this is what #core-customize is most interested in, but picking a code editor library should be done ensuring that it doesn’t cause headaches if code editors are implemented for HTML view and file editor. i.e. the same library should be used throughout core.
    • WP content editor HTML view:
      • @joemcgill: the text editor now is not technically an HTML view, but is a plain text editor that is parsed into HTML. For instance, breaks are turned into `<p>` tags, shortcodes can be typed, etc., so a “code editor” is something slightly different.
      • @helen: per @iseulde and lots of discussions over time, is a little more complicated in that it’s not an actual HTML editor, so is getting rid of wpautop() is a requirement
      • @mike: I’d love to see code highlighting in the HTML view.
      • @afercia: If both the visual editor and the text editor are going to be replaced by Gutenberg and some sort of CodeMirror-like, well the level of accessibility for both is still uncertain and there’s the danger to introduce an accessibility barrier for the main scope of WordPress: entering content.
    • File editor:
      • @jorbin: I seem to remember that having been replaced with something fancier than what is in place now, but that having been ripped out
      • @helen: File editors really raise the question of whether users should be made more comfortable in them vs. being encouraged to use something else.
      • @brechtryckaert: security-wise I’m not a fan of the ability to edit files from the backend, people who are comfortable enough to edit code usually have a prefered editor
    • @jorbin: We already have our agreed upon accessibility coding standards that state:
      • All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA

    •  @westonruter: if CodeMirror fails this test, as it seems to, then we need input on GPL-compatible code editors that are accessible.
    • @afercia: I propose to discuss this at the next accessibility meeting on Monday, invite people to do research, and possibly involve the testers group.
  • #38900 (Customize: Add REST API endpoints for changesets) and #39634 (Customize: Add REST API endpoints for panels, sections, controls, settings, and partials)
    • Thanks to @kadamwhite we have an initial (empty) feature plugin repo for the REST API endpoints for customization
    • Feel free to watch that repo and be apprised of developments
    • Next steps are to design the endpoints, write the failing tests for them, and then  go about writing the endpoint controllers
    • @kadamwhite: this is the first major effort within other areas of core that are turning up inconsistencies like #39805 (Expose featured_media property on post resources in “embed” context) so I’m excited to see what other improvements we can make as this work continues

Editor team update

  • Working full steam on prototypes, notably the Gutenberg UI prototype
  • The related GitHub repo has quickly become wonderfully active
  • Looking to discuss browser support for the new editor
    • @georgestephanis: So long as it can fall back to something that doesn’t utterly die, it should probably be fine.
    • WP Admin currently supports IE 8
    • Current browser market share
    • @jorbin: I would love to see us not drop support for anyone if possible
    • @joemcgill: Alternately, if we’re going to bump the browser requirements at any point, now is probably the time.
    • @joen: flexbox was mentioned as being nice to use in context of editor UI
    • flexbox support
  • The agenda for the Editor chat today was to discuss how using the UI prototype felt in the past week, and deciding where to take it next
  • We are looking for people to use and provide feedback the prototype, so please take a look if you can!

REST API team update

  • The REST API team has no significant updates since last week.

#4-7, #4-7-3, #core-editor, #core-restapi, #dev-chat, #summary