PHP Meeting Recap – October 15th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • We discussed how the php-error.php drop-in in WSOD protection and the 500.php in the PWA feature plugin would relate to each other and how work could potentially be deduplicated/harmonised.
  • The php-error.php drop-in in WSOD protection is used server-side when a fatal error was caught. As it could be triggered by a theme or before the theming functionality has actually been loaded, it cannot be styled through a theme. It is “always-on”, though, and catch fatal errors very early on in the bootstrapping process.
  • The 500.php template from the PWA feature plugin is displayed by client-side code when the request made by the service worker returns a HTTP 500 status code. To achieve this, an offline cache is built through the service worker, and the site is requested to do a server-side rendering of the 500.php once so that it can be cached for the case where it is needed. Because of this, it can be styled through the theme, as the request to actually render is is a normal “render a page template” request. It requires for the service worker to have been installed previously and the server to have successfully rendered the page template once so that it can be cached. This means that there scenarios where this mechanism is not yet available.
  • There is an error query variable that would be a good fit to reuse for the 500 and offline mechanisms of the PWA feature plugin, but this would first require a change in WordPress Core as this query variable is currently being unset. There is already a Trac ticket to change this. For now, the PWA feature plugin uses a custom query variable wp_error_template instead.
  • Currentl functionality already should work as-is to always catch fatal errors on the server side and display the php-error.php drop-in, and if the service worker is active and the 500.php has already been cached, it will be used to progressively enhance the php-error.php drop-in to style it according to the current theme.
  • @westonruter suggested a change to make this more reliable and explicit by adding header information to the WSOD screen along the lines of X-WP-WSOD: true.
  • We should also add some token to the rendered page, as the headers might already have been sent in some scenarios, like a special form of HTML comment.
  • @joyously has added that for diagnosing errors, having access to even half of a HTML page can help, so cleaning everything out might further obfuscate the nature of errors.
  • @flixos90 argued that the php-error.php might not even be needed, with PWA as a later option in the future.

Next week’s meeting

  • Next meeting will take place on Monday, October 22nd, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss current roadmap and priorities.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summary

What’s new in Gutenberg? (19th October)

This update is considered to be the feature complete for starting the WordPress 5.0 cycle.

Highlights include a block navigation system that can be used to access child and parent blocks within nested blocks easily. It also works as a way to navigate quickly through all the blocks in post. This is a top level affordance that works as a “path” finder and would be the basis for many of the phase 2 layout implementations.

Alternative mechanism for selecting nested groups.

There is also a new block, new style variations for Table, support for video backgrounds in the newly renamed Cover block, accessible date and color pickers, better visibility for style variations, and an “options” modal similar to the former “screen options” to toggle document and meta-boxes on and off.

And this one shows a convenient block for splitting media and text in two columns with mid resizing. In phase 2, this can be the base for internal resizing of columns:

The next step is going to be to freeze the numerous APIs while bugs and outstanding backwards-compatibility issues are addressed.

4.1 is at the release candidate stage, which can be grabbed here.

4.1 🎾

Bug Fixes

Other Changes

Mobile Native

Deprecations removed with this version.

Call for Testers: Community Gutenberg Accessibility Tests

The Accessibility Team last conducted a series of accessibility user tests in March. A lot of effort has been made to improve the accessibility of Gutenberg since those tests were conducted. It’s time to conduct another set of tests, so we want your helpWhat’s working better? What still needs work?

If you currently use an assistive technology, we’d like you to test Gutenberg with us again. Please comment on this post or ping tofumatt in the #core-editor Slack channel to coordinate the tests. The tests will focus on common tasks to gauge Gutenberg’s current accessibility.

We’ll work out logistics (remote testing or in-person, etc.) for each person. This way the process will be as simple as possible for you. 😊

5.0: JS package inclusion update

News from the #core-js front! The JavaScript packages published on NPM have been included in WordPress core. Initial work on this was done last week by @atimmer. This week we were able to finalize the work after processing some feedback that we had received.

How does it work?

In the 5.0 branch, you can now run npm install && grunt build:js. That will download the NPM packages and build the scripts that need to be registered. Updating a script is a matter of changing its version number in the package.json and running the same command again.

Tasks

We’ve got the following tasks left:

Must haves for RC

Should haves for RC

Nice to haves for Beta, maybe RC

Core-privacy Office Hours Summary – 17 October

Below is a summary of the discussion from this week’s #core-privacy chat. You can read the chat in its entirety in Slack.

Roadmap Progress

There was no roadmap related progress to report this week. The component’s focus until post-Gutenberg remains the 31 bug tickets, with a goal of marking at least 75% of them as ready for commit.

Gutenberg Privacy Review

@allendav, @garrett-eclipse, and @azaozz have been reviewing Gutenberg for potential privacy issues.

In response to concerns about the source of the data presented on https://gutenstats.blog, @allendav will add a note to the footer on that site clarifying that the post counts come from Jetpack-connected sites. @allendav also reports that there is no Automattic tracking code in Gutenberg, and that if a site has Jetpack and Gutenberg installed, some of Jetpack’s Gutenberg blocks are loaded from Automattic’s CDN.

Related to CDNs, @azaozz confirmed that reliance on unpkg will not be an issue once Gutenberg is merged into WordPress Core. Third party resources are loaded from a CDN when Gutenberg is in development mode. Whether this carries over after the merge into WordPress core needs to be verified.

There is a bug in Gutenberg regarding the display of the privacy notice tool. @desrosj has noted this as Gutenberg ticket 10448.

Gutenberg utilizes the Noto Serif Google Font for supported locales. @garrett-eclipse asks whether a font replacement should be proposed for the 5.0 merge, or whether the suggested privacy policy content should be updated to include Google Fonts verbiage.

The emojis in Gutenberg load from s.w.org and need further review. @garrett-eclipse seeks clarification on whether emojis are part of core and therefore covered by the existing privacy notice language.

Regarding embed blocks, @garrett-eclipse suggests that how core handles them from a privacy standpoint should follow whatever is done for embeds in general. He suggests it would be useful to propose to Gutenberg/core the feasibility of creating a “privacy flag” on blocks which could flag users about potential privacy concerns, and/or flagging admins that blocks with potential privacy ramifications have been added on their site.

BuddyPress and Privacy Reviews

@garrett-eclipse and @jjj have arranged to conduct a basic privacy review of BuddyPress.

This led to a discussion about privacy reviews being a service which the team could offer, akin to theme, plugin, or accessibility reviews. All were in agreement that the parameters and deliverables of these reviews would need further discussion. All in attendance also agreed on the need to make absolutely clear that privacy reviews would not be legal advice, nor could they be carried out in regards to achieving compliance with any specific privacy law. Rather, the reviews would focus on general issues of data collection, flows, retention, and sharing. Any action items which reviews might identify would be the developer’s responsibility to address, and not the core-privacy team.

@allendav suggested that “needs-privacy-review” could be added as a tag in Trac for patches and tickets.

@garrett-eclipse and @allendav will document the processes they have used in their Gutenberg and BuddyPress evaluations, with a view towards using these steps as the basis of a potential privacy review checklist for the handbook.

Component Documentation Review

@allendav wrote handbook documentation as part of the V1 roadmap earlier in the year. All in attendance agreed it would be good to review the handbook for new material that could be added, and to see if additional audiences could be accommodated. @allendav and @riankinney will review the existing documentation and report back with suggestions. Documentation from other teams, including design and accessibility, provide good examples to follow.

@garrett-eclipse suggested that the Privacy by Design standards used by core-privacy could be more widely adopted across the WordPress project, and more visible documentation could help to promote this.

Team Issues

A healthy and constructive discussion was had on whether the core-privacy team should continue to identify as a core component or should seek to additionally become a team. The team agreed to consult with @chanthaboune on what options are available within the team and component structure.

Group Meta Issues

Last week @desrosj circulated a Doodle poll to find a better time for weekly office hours. From the suggestions provided there, he has launched a second Doodle poll narrowing the selection down to the four most popular answers. Please provide your two best choices. The Doodle poll will appear in your local time zone, not in UTC.

@allendav has been looking into more privacy-conscious collaboration tools and reports he is not happy with the UX of Etherpad.

Sarah Gooding interviewed @idea15 for an article about the team on WP Tavern. @riankinney is doing a privacy podcast with WPBob later this month.

The next core-privacy office hours is Wednesday, October 24, 2018 at 1500 UTC. A new office hours time will be decided in this meeting.

#core-privacy

Regarding Accessibility in Gutenberg

There have been some important questions and concerns about accessibility in the upcoming new editor. First and foremost, it goes without saying that work on these areas is never finished and we can always go a step further in improving the experience for all users of WordPress. That is a big part of the project’s core mission. We need to continue to develop close feedback loops with different users interacting through their preferred tools to make sure what we build is relevant to their experiences.

A large amount of work and effort has gone in building mechanisms necessary to make the editor accessible for a wide user base, some of which will be highlighted in this post. For example, it is entirely possible right now to recreate the “demo post” that comes with the Gutenberg plugin using the keyboard. In many ways, these tools are better and more sophisticated than what we offer in the current editor.

There are bugs, of course, and rough edges to still address. From release to release these have been refined and iterated by many people and I want to thank all of them for their hard work. There are about 270 tickets closed specifically labeled “accessibility,” and around 90 more that remain open, so we still need your help. The goal is to make this experience as seamless as possible for all users, so if you are encountering an issue, please share it so it can be addressed.

Let’s go over some of the accessibility related capabilities that exist right now in the new editor…

The cropping is a bit too tight on the video and doesn’t show the “regions” in all its crystal clarity

Region Navigation

Gutenberg introduces a mechanism for navigating across the major regions of the application with a simple keyboard shortcut that cycles through them — header, content, sidebar, publish flow are included. A user can press “Control + `” or “Alt + Shift + n” (this can vary based on keyboard configuration) to focus the different areas at any time. This is an entirely new addition to WordPress with the hope of streamlining navigation without a pointer device.

Keyboard Shortcuts

There is a wide array of keyboard shortcuts available to help access different functionality. These are built in a way that can be extended and integrated in testing flows. A panel listing most of the shortcuts can be accessed from the menu at the top of the editor or by pressing “Ctrl + Alt + h”. Tooltips used throughout the application also display their corresponding shortcuts when available. They range from editor functionality (save, undo, etc), to formatting options (adding links, italics, etc), to inserting new blocks (just type “/” on a new line), to navigation and selection of blocks. Keyboard shortcuts are contextual to the OS and displayed as such in tooltips and menus.

(Note: All keyboard shortcuts listed are available in Windows. MacOS includes these shortcuts but with different combinations; see the keyboard shortcuts panel in Gutenberg to see them all.)

Block Navigation

The main mechanism for traversing blocks is using the arrow keys. There is also a Block Navigation panel that allows keyboard users to quickly navigate through blocks without having to tab through their controls or flow through their contents.

Slash Command and Insertion

It’s important to be able to add new blocks and manipulate them with ease without leaving the keyboard. There is a very convenient shortcut (“/”) to add new blocks. There are also shortcuts for adding a new block before or after the current block. If there are ideas on how to surface these better and contextually to users, please chime in!

Toolbar and Sidebar

Main block tools are grouped in the toolbar, while secondary actions are often deferred to the sidebar panel and both can be accessed through keyboard navigation. The sidebar can be toggled with a single keyboard command (“Shift + Command + ,“). The toolbar — whether it’s docked at the top of the block or at the top of the editor — can be accessed with “Alt + F10”. Using the arrow keys, all focusable areas of a block can be navigated to (including things like the optional caption field for an image or an embed, or the source of a quote).

High-Contrast Mode

We’ve worked hard to fix edge cases for users of high-contrast mode in Windows, to ensure users with vision issues that require high-contrast mode do not encounter bugs when using Gutenberg.

Components

Gutenberg is built using JavaScript components that are published on NPM and these components can be re-used by third-party blocks. This presents the potential for raising the bar for accessibility across the ecosystem; when improvements are made to accessibility in Gutenberg, third-party blocks using our large list of components get these improvements without needing to update their code. This is a way to scale accessibility thinking beyond what can be controlled in core.

These components not only reduce the overhead of having to replicate UI controls and solutions, but also ensure consistency. Consistency is important so that learned behaviours can be transferred and interactions work as expected. Many of these components have built-in accessibility mechanisms, from things like containing focus within dropdown menus or modals, arrow navigation of menu items, to supporting and automatically assigning aria properties when possible. In combination with guidelines and tests, it can help ensure the editor and its extensions remain accessible to users beyond what core offers.

Helping the User Create Accessible Content

The editor also introduces helpful messages to the end user when using color combinations that might have contrast issues (it also takes font sizes into account for readability measurement) or when adding heading elements in the wrong order (like an h4 following an h2, for example). This is also a new addition that has the potential of both helping users learn and produce accessible content for their viewers, expanding WordPress’s commitment to web standards. These tools are also available for reuse by third-party developers in their own blocks.

Furthermore, the controlled nature of blocks means that the final HTML generated can remain semantic and accessible for viewers.

Autoformatting

To speed up the process of content creation, there are quick formatting shortcuts that can be used when starting new lines. For example, using an asterisk followed by a space would automatically create a list block while using “##” would create a heading block.

Audible Messages

Included in the WordPress/a11y npm package is a speak function that allows developers to announce changes in the UI for users with visual impairments. Adding speech commands to a JavaScript-heavy application like Gutenberg ensures users with visual impairments have changes in the UI announced to them. Our speech utilities include the ability to specify how assertive the speech should be, so users are alerted to important UI changes immediately. (Example: sidebar settings change)

Aria properties are also used throughout the application to inform about the purposes and meaning of controls and actions. This is an ongoing process that has benefited tremendously from the help of people like @afercia with a lot of experience in testing with different screenreaders and their intricacies (JAWS and NVDA, MacOS VoiceOver). It’s also a good place to lend a hand if you are familiar with them.

Automated End-to-End Tests

We have the ability to run and automate a full editor session in a browser. Using this, we can test a sequence of operations with the keyboard and validate the results. This will allow the editor to continue to improve while making sure things remain accessible and don’t regress interaction-wise. As an example: we test Block Navigation entirely with the keyboard and no mouse controls to ensure it is fully usable by keyboard users. This hasn’t been a well communicated capability, but it’s a great area for contributors to get involved with.

Speaking of such tests, this is a fully automated test that replicates the “demo” post using keyboard commands:

This is an automated test. It’d be great to see more of these tests covering a wide range of interactions and real use cases

Current Issues and Improvements

The above is a partial picture of what is currently in place. There is still work to do, and I’m confident we’ll be able to get there together. The following are some of the pending bug fixes and ongoing improvements on multiple fronts, many of which are landing in the next releases:

There’s also work to be done in better exposing many of these tools to end-users, specially around non-obvious keyboard navigation commands.

Huge thanks to everyone that has tested and contributed issues related to accessibility. It helps tremendously.

All in all, there is a significant volume of accessibility-specific tools and functionalities included in the plugin that already surpass comparable capabilities in the Classic Editor. This was the result of the work of multiple people’s collaboration that I hope continues to evolve and improve. It hasn’t always been easy among the product challenges and the new technologies involved and we need to collaborate better — communication is something that we need to always nurture and foster.

— Thanks to @lonelyvegan for collaborating on this post and the ongoing work.

REST API Chat Summary, Oct 11

This post summarizes the REST API component team chat on Thursday, October 11 (agendaSlack transcript) and the bug scrub on Tuesday, October 16 (Slack transcript).

Updates on 5.0 priority tickets

As with last week, the meeting worked off of this post listing REST API priority tickets as an agenda. We aim to have all major 5.0-related REST API tickets landed by Thursday, to allow time Friday for final adjustments as we move into the beta stage.

In Progress

  • Progressively load data through pagination when assembling large collections for Gutenberg dropdowns, to prevent memory errors (gutenberg#6694): @kadamwhite is working on a patch. (This ticket does not cover any UI changes; those are tracked separately.)
  • Post says updated when it’s a page (#3315): @earnjam has opened a pull request addressing the issue.
  • Autosaves support (#43316): @adamsilverstein is driving, and will also look into gutenberg#6556 related to autosaves.
  • Introduce a controller for searching across post types (#39965): patch is in final review.
  • Improve media titles when creating from filename (#44789): @dryanpress is working on a patch as of Oct 11.
  • Introduce WP_Block_Type, WP_Block_Type_Registry, WP_REST_Block_Renderer_Controller, and WP_REST_Blocks_Controller classes (#45097 and #45098): @desrosj has a patch in progress.
  • Localizing REST API responses: #44758 moved into milestone, support from core contributors versed in localization is strongly requested to evaluate #41305. #38218 may be a necessary compromise, though #41305 is the preferred approach given its additional benefits.
  • Saving Metadata fails if value contains slashes (#42069): waiting for final sign-off from @boonebgorges
  • More descriptive REST API error messages (#10492): needs direction on wording. Lowest priority of open issues.

Resolved Tickets

  • PHP notices should be disabled for REST API responses (gutenberg#10476): thank you @earnjam and @danielbachhuber!
  • Theme-supports data is now exposed through the REST API for privileged users at the /wp/v2/themes?status=active endpoint (gutenberg#10518 / #45016): we have also added conditional loading to the Gutenberg classes to prevent conflicts between the core and plugin controllers.
  • Permalink templates are now exposed on the posts controller (#45017
  • An action is now fired after items are completely inserted/updated (#42864)

A full list of recently completed tickets can be seen in this post.

Punted Tickets

  • Support post locking through the REST API (#44862): The current solution using the existing locking functionality is sufficient for 5.0; more discussion is needed to identify a way to represent this state in a RESTful manner.

Thank you to every contributor who has helped move these tickets forward in such a short period of time. We will have our next weekly meeting tomorrow, October 18 17:00 UTC, and have scheduled additional bug scrubs through the end of the month.

Dev Chat Agenda: October 17th (5.0 Week 3)

This is the agenda for the weekly devchat meeting on October 17, 2018 at 20:00 UTC:

  • 5.0 planning
    • Gutenberg and REST API bug scrubs
    • Gutenberg documentation
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, then please leave a comment below. Either way, we look forward to seeing you at the devchat this week!

This meeting is held in the #core channel in the Making WordPress Slack.

#5-0, #agenda, #core, #dev-chat

Core-privacy agenda – 17 October 2018

This is the agenda for the weekly #core-privacy meeting on Wednesday 17 October 2018 at 1500 UTC:

Roadmap issues

Team issues

  • Group definition: Are we a core component? A component? A team? @idea15
  • Group lack of visibility and consideration: how do we get more of it within and outside the project regardless of how we are categorised? @idea15

Group meta issues

#core-privacy

Javascript Chat Summary – October 16, 2018

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: “Props” for Gutenberg Merge

Slack Conversation

How are props being handled for the merge of Gutenberg code?

  • consensus was mostly reached on Github profile attribution for any involved in a pull request.
  • There were not concrete plans for technical process implementation of props yet.

Actions

  • Discussion can continue in the meeting notes, or revisited in a future meeting.

Agenda: “Internationalization”

Slack Conversation

  • Proposal for language packs
  • for v1, utilize `wp_localize_script` for loading/queuing translations.
  • for v1, generate translation file (po,mo,json…) for every single JS file

Actions

  • split this out into a meta trac ticket and create tickets/issues on different projects as necessary. (owned by @herregroen)

Agenda: Plugin and Block Scaffolding

Slack Conversation

There are some recently released projects designed to aid developer experience around plugins and blocks for Gutenberg:

  • https://github.com/youknowriad/wp-js-plugin-starter
  • Work also started on a solution based on the above which is purely JS based.

Action:

  • continue feedback/evaluation on the pull request

Agenda: Pending bump of Node’s LTS version from 8.x to 10.x

Slack Conversation | Context

Action:

  • probably only request a bumping of the relevant files with node version in them.
  • possibly some docs updating needed.
  • revisit in a following meeting.

#javascript