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

This post summarizes the dev chat meeting from February 15th (agenda, Slack 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 PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party editors) and #12423 (Include Ace (or similar) as default code editor)
  • Topic of discussion is a code editor library to be used in Custom CSSCSS Cascading Style Sheets., WP content editor HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. 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 accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/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: CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.: Additional CSS highlight, revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
  • 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 GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/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 WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 2.0 guidelines at level AA

  •  @westonruter: if CodeMirror fails this test, as it seems to, then we need input on GPLGPL GNU General Public License. Also see copyright license.-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 APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/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 Adminadmin (and super 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 UIUI User interface
  • 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-3, #core, #dev-chat, #summary