The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
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.
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.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.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.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.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.X-WP-WSOD: true.php-error.php might not even be needed, with PWA as a later option in the future.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.
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.
info prop support to MenuItem and FeatureToggle. Show relevant description text on “view modes”.figure elements (like image and embed).FlatTermSelector.PostFeaturedImage component.path element) when comparing HTML./gutenberg/v1/block-renderer/ to /wp/v2/block-renderer/.getEditorSettings docs and update getTokenSettings docs.dangerouslySetInnerHTML with i18n string.default_title, default_content, and default_excerpt filters to function as expected.isDefault option for block styles.Deprecations removed with this version.
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 help! What’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. 😊
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.
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.
We’ve got the following tasks left:
Below is a summary of the discussion from this week’s #core-privacy chat. You can read the chat in its entirety in Slack.
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.
@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.
@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.
@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.
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.
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.
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…
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.
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.
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.
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!
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).
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.
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.
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.
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.
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.
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:
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.
This post summarizes the REST API component team chat on Thursday, October 11 (agenda, Slack transcript) and the bug scrub on Tuesday, October 16 (Slack transcript).
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.
/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.A full list of recently completed tickets can be seen in this post.
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.
This is the agenda for the weekly devchat meeting on October 17, 2018 at 20:00 UTC:
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.
This is the agenda for the weekly #core-privacy meeting on Wednesday 17 October 2018 at 1500 UTC:
Roadmap issues
Team issues
Group meta issues
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.
How are props being handled for the merge of Gutenberg code?
There are some recently released projects designed to aid developer experience around plugins and blocks for Gutenberg:
