What’s new in Gutenberg?

This new release completes some cool additions to the editor. It includes the ability to create reusable templates by selecting multiple blocks in the editor. It then allows exporting and importing these templates using a JSON file transport. There’s also a visual diff mechanism for comparing options when a block was detected as invalid (which could scale in the future to improved UX for revisions as a whole), toolbar groups can be defined as collapsible into a dropdown to better organize available block controls.

Showing visual comparison and reusable templates

There’s also the addition of a much clearer drag handle for drag and drop block operations next to the block arrow controls. It’s also possible to convert an image into a cover image and back, retaining the caption as the main text among many other small improvements and fixes.

3.9 🍒

Mobile Native

Deprecations removed with this version.

#core-editor, #editor, #gutenberg

Dev Chat Summary: September 19th (4.9.9 week 6)

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

4.9.9 planning

  • @westonruter: highlighted this discussion about the scope of HTTPS support to target in 4.9.9
    • Looking for wider visibility on those items to get thoughts on what makes sense to include in 4.9.9
    • Relates to umbrella ticket #28521
  • @audrasjb: Accessibility team has a spreadsheet where we sort all the tickets on the focus a11y in order to facilitate lead’s work (see this week’s meeting notes)
  • Bug scrubs not scheduled yet, when they are it’ll be posted to Make/Core

Updates from focus leads and component maintainers

  • @kadamwhite from the REST API team wants to propose the inclusion #41305 in 5.0
    • This covers altering how we evaluate translation strings, originally with the intent of deliberating a performance improvement to the REST API. In discussions about how Locale can be applied to REST API responses for Gutenberg this issue resurfaced, because the current order of operations precludes evaluating string translations based on a passed flag (required to permit the API to provide translations in a user’s locale). To support these localization needs and to improve overall performance at the same time, we intend to milestone this ticket for 5.0.
    • @schlessera: There are two proposed solutions in the above ticket: one that fixes REST API schema translations only, and one that generally optimizes translations (REST API component team’s strong recommendation). The latter is highly preferable, but includes breaking changes for edge cases (as noted in the ticket), so might need a check against plugins first. We otherwise would like more eyes on the forthcoming patch to validate the approach and to help test it.
  • The Editor / Gutenberg team released v3.8 last week including “full screen” mode, improved mechanisms for styling blocks from a theme perspective, and exposes the custom post type used to store reusable blocks from the block inserter as a way to manage saved blocks in bulk.
  • The JavaScript team published notes from their last meeting including documentation of available Gutenberg scripts, reducing exposure of Moment.js in the `wordpress/date` module, and a couple announcements on introducing a formal asynchronous data flow as part of `wordpress/data` and the new `wp-polyfill` script added to Gutenberg.

General announcements

  • @psykro posted about alternate devchat options. Please give that a review and feedback, as ideally we get to a conclusion during next week’s devchat.
  • @whitneyyadrich & @dkotter looking for eyes on / update to Gutenberg issue#7762 as they are running into an issue where they need to be able to insert and manipulate media attachments within the Classic Block, but that’s not currently possible
    • Also imagine this being a bigger issue when migrating sites over to Gutenberg and all their existing content will be thrown into that block. There’s currently not a great way for them to modify/add to that content, if they need to do things with images.
    • Will review with Gutenberg team in next #core-editor weekly chat

Next meeting

The next meeting will take place on September 26, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-9, #a11y, #accessibility, #core, #core-editor, #core-https, #core-js, #core-restapi, #dev-chat, #gutenberg, #javascript, #summary

Dev Chat Agenda: September 19th (4.9.9 Week 6)

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

  • 4.9.9 planning
    • Discussion on tickets to be milestoned for 4.9.9
  • Updates from focus leads and component maintainers
    • Proposal to include #41305 in 5.0
    • Scope of HTTPS support to target in 4.9.9
  • 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!

#4-9-9, #agenda, #core, #dev-chat

JavaScript Chat Summary – September 18th

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

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

Announcements

Open Floor

Documentation of Available Gutenberg Scripts

(Slack Conversation)

Gutenberg registers a number of scripts, but an exhaustive set of all scripts isn’t available, nor is it well-documented how these scripts can be used by a plugin.

Decision: Create new documentation to be included in the “Reference” section of the Gutenberg Handbook, detailing which script handles are available for plugin authors to reference.

Issue: https://github.com/WordPress/gutenberg/issues/10005

Reducing Exposure of Moment.js in the @wordpress/date module

(Slack Conversation)

Our @wordpress/date module uses the popular Moment.js library to implement date formatting. We should be conscious of the long-term maintenance burden in committing this into our public API, particularly in light of alternative date formatting offerings and future maintenance likelihood of Moment.js.

Decision: We’ll continue to use Moment.js for the immediate future, but we should eliminate its availability from the public interface.

Issue: https://github.com/WordPress/gutenberg/issues/10007

Future Action Items:

  • Gain a better understanding of the requirements of our public interface by auditing existing usage, understanding server-imposed restrictions (site formatting as an option), and knowledge transfer from equivalent WordPress PHP APIs (strive for seamless transition)
  • Explore alternative offerings to Moment.js 

Related Resources:

#javascript

Dev Chat Summary: September 12, 2018 (4.9.9 week 5)

This post summarizes the weekly dev chat meeting held Wednesday, September 12, 2018 at 20:00 UTC. Agenda | Slack archive


4.9.9 Planning

We have a Road Map and she is gorgeous. Thank you @antpb and @schlessera for putting it together. Here’s a summary:

Suggested Timeline

We will reassess these dates after the three-week mark:

  • Beta : Monday October 22, 2018
  • Release Candidate : Monday October 29, 2018
  • Release Date : Monday November 5, 2018

Key Focuses

If you’re interested in helping out with these topics, hit up these Slack channels:

*Not real but should be.

Bug Scrubs

  • The plan is to run them weekly in the #core Slack channel across multiple timezones. Schedule 👏 Coming 👏 Soon 👏

Focus Lead and Component Maintainer Updates

Notes and Summary Posts

Additional Updates/Requests

  • From PHP Servehappy: More testers are needed for the WSOD protection on real-life, complex sites to reveal edge cases. A “complex site” is basically any site running locally with random plugins and random code.

If you’re thinking about get all up in these Focus and Component Maintainer teams, try attending a chat. Here’s the comprehensive list.


Open Floor

Tickets

Anyone can submit a ticket for the Open Floor. Send your submission to @jeffpaul or moi (@whitneyyadrich), or comment on the agenda for that week’s chat.

  • #12563: New action on body open – Submitted via @welcher. Will be discussed in the #themereview meeting.
  • #32326: Improve Support for Structured Data – This one pairs nicely with the ticket above, so the conversation should be happening in the #themereview room and scheduled chat.
  • #25280: wp_localize_script unexpectedly converts numbers to strings – Submitted via @adamsilverstein and Ivan Kristianto. Lots of words about code were had in the chat, and then the conversation was moved to the ticket itself.

General Announcements

Dev Chat Schedule

@psykro published his proposal for a second <dev chat> and it’s open for your comments. I’m sure we’ll touch on this during tomorrow’s dev chat, too. 

As always, anyone is welcome to join <dev chat> every Wednesday at 20:00 UTC. As I said in the chat, to sorta quote the late, great Notorious B.I.G.

I’m goin’ go call my WP crew
You go call your WP crew
We can rendezvous in <dev chat> tomorrow around two (or Wednesday at 20:00 UTC)

#summary, #4-9-9, #core, #dev-chat

Javascript Chat Summary – September 11th

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

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

Announcements

  • WordPress packages are using Babel7 and the @wordpress/babel-preset-default has been updated to support it.
  • The packages do not include the polyfills by default anymore. It’s the responsibility of the consumer to add the required polyfills to their applications or bundles. The context for this change can be found on this issue.
  • WordPress (via Gutenberg) exposes a new script wp-polyfill-ecmascript (and will be simplified soon as just wp-polyfill) that you can add as a dependency to your script to ensure the polyfills are loaded.

Discussions

  • Having a separate polyfill script even without conditional polyfill loading is still a decrease in bundle size (Gutenberg is 118.64kb smaller).
  • We also discussed whether to include “web” polyfills in the wp-polyfill-ecmascript instead of including them per dependency. A decision was made to have a unique wp-polyfill script you can depend on and use all the polyfills made available by WordPress. This script would include both ECMAScript polyfills and also different Web Standards that require polyfills such as window.fetchor element.closest. This results in a better developer experience as it’s not always easy to know what polyfill is needed for per script.

Action items

#core-js, #javascript, #summary

Javascript Chat Summary – September 4th

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

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

Agenda: Deprecation policy

Slack Conversation

Gutenberg has a policy where deprecated functionality is kept for two additional minor versions to allow time for plugin developers to move away. As we start deprecating functionality in the published npm modules, the idea of tying to Gutenberg version doesn’t make a whole lot of sense, as these packages could be used independently of Gutenberg or WordPress.

It was raised by many that our packages should just follow semver. The most likely scenario for the 5.0 merge will be that the JavaScript will still be maintained on Github and included in WordPress through npm. The aforementioned deprecation policy is mostly something that applies to the Gutenberg / WordPress context then. The initial idea in terms of flow looks somewhat like this:

  • Packages follow semver, so something could be removed in a major version, ie. 3.0
  • Then the package adds a deprecation warning in a minor version before that, ie. 2.x
  • The deprecated call as used by packages wouldn’t include anything specific about Gutenberg, but somehow Gutenberg extends the message it logs (by filter), analyzes the generic deprecation version (the npm SemVer) and maps it back to an equivalent Gutenberg / WordPress release.

Actions

  • Explore extensibility of deprecated to allow Gutenberg to define its domain-specific messaging (@aduth, @youknowriad)
  • (Re-)consider how and where to define boundaries between packages and core-specific JavaScript (proposal by @atimmer, @omarreiss)

Open floor: Also allow building in src

Slack Conversation

The build step that was introduced in #43055 seems to cause quite some friction for PHP development, since now you also need to build to see a change in the PHP reflected. This turns out to be a weird experience for PHP development, since there’s no real reason why it needs to be built. A solution that allows for building with symlinked PHP files was pursued in #44492, but seems to run into a dead end. @omarreiss is now working on a grunt build:dev task which allows to build into src after all and asked if anyone had any input / objections.

It was raised that some PHP files (ie. formatting.php) need to be built right now and this is really confusing. Since PHP is a dynamic server language, we should look if we can avoid any PHP from being built statically. Apart from this there seemed to be no objections to the approach.

Actions

@omarreiss will work on a patch.

Open floor: Guidelines for including WP packages

Slack Conversation

Currently it’s not clear if plugin developers should consume WordPress packages through the wp global or by importing them from the @wordpress/ namespace. Documentation and guidelines about this are currently lacking. It was raised that different approaches are probably needed in different scenario’s. Factors that play a role are:

  • if the plugin author needs to backport these API’s or not in order to support classic editor.
  • If the plugin author uses ES2015 or older versions of JS.
  • If the plugin author uses a build proces.

Actions

@atimmer will work on a guideline for the plugin development handbook in which he plans to document different scenario’s and approaches.

Dev Chat Agenda: September 5th (4.9.9 Week 4)

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

  • 4.9.9 planning
  • 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!

#4-9-9, #agenda, #core, #dev-chat

Javascript Chat Summary – August 28th

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: Preparing for Gutenberg Merge

Slack Conversation

What tasks do we need to complete on the core side to be ready for Gutenberg Merge?

Prior Work

Remaining Tickets

Actions

What? Who?
Experiment with the following steps to see how this works:

WordPress side:

– Gutenberg packages stay where they are
– Gutenberg’s PHP (script registration and bootstrapping) move to core.
– Webpack config to alias wp.* to npm dependencies moves to Core’s webpack config.

Gutenberg side:

– Kept as plugin for ease of maintenance, updates.
– Plugin re-register’s the scripts (overriding wp’s registrations)
– No more php bootstrapping in the Gutenberg repository.

Some experimentation could involve consuming packages in WordPress core.

Example: Usage of shortcodes.js could be replaced with @wordpress/shortcodes

edit-post needs to be moved to a package.
Resolve componentsand block-library which have some code that lives outside packages.

Agenda: Hooks

Slack Conversation | Context

The following things were discussed:

  • Standards for naming/namespacing hooks
  • Criteria for adding/accepting a new hook
  • Expanding documentation for available hooks (including inline documentation)
  • “All” hooks.

No clear resolution to the above points was made in the meeting.

Agenda: Babel 7 & Polyfills

Slack Conversation | Context

Actions:

What? Who?
Decision: Ship packages without any polyfills, then bundle all polyfills in WordPress core.  Documentation will include something like this:

This package assumes that your code will run in an ES2015+ environment. If you’re using an environment that has limited or no support for ES2015+ such as lower versions of IE then using core-js or @babel/polyfill will add support for these methods. Learn more about it in Babel docs.
@gziolo 

Agenda: Converting from lodash to lodash-es for distributed packages

Slack Conversation | Context

Actions:

What? Who?
Continue discussion on the related issue.  

PHP Meeting Recap – August 20th

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 continued reviewing the content of the Update PHP page, which is available in this Google document.
  • We specifically looked at the closing section that acts as a summary, wondering whether it could be highlighted more or whether it is even needed. In the end it was decided to keep it as it is, as web readers typically expect a conclusion to occur at the end of a resource. Furthermore it leaves them with a positive attitude about their (future) achievement.
  • There were two comments about redundancy of paragraphs describing what would be the topic of the respective next section, since they are followed by a heading telling the same thing. However, as linking paragraphs they improve the reading flow and therefore should remain present.
  • A couple of minor wording improvements were discussed and applied.
  • It was agreed that the only outstanding change is the removal of all the hosting-specific tutorial links. They should be replaced with a single link to an external resource containing those links, similar how it is in the current live version of the page. A long list of links would distract readers, furthermore a single external resource allows for more flexibility on how this is managed. For now, the single link should point to the hosting-specific tutorials list in the Servehappy resources repository. Once this change is present, the content of the Google document can go live, replacing the current Update PHP page content.
  • Before the meeting, at WordCamp Brighton, a new idea of coming up with a documentation pattern and distributing it to hosts in order to get them provide guides on how to update PHP on their environment was discussed. The idea was appreciated by everyone. While an involved task, it will iterate on the already present crowd-sourced resources repository.
  • It would make sense to use GitHub Pages for such a repository. Pointing to a repository directly would easily confuse non-technical users, and a simple website fetching the content from GitHub Markdown files would improve that greatly.
  • A consideration is the URL to use for that. GitHub Pages URLs for organization repositories contain both the organization name and the repository name, so for the servehappy resources directory, it would be WordPress.github.io/servehappy-resources, which is not very obvious for what it contains. A repository named update-php or update-php-resources would be a better alternative. Alternatively, a custom domain could be used. This needs to be carefully evaluated.

Next week’s meeting

  • Next meeting will take place on Monday, August 27th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Further discuss the approach for streamlining hosts’ PHP update tutorials and using GitHub Pages (or possible alternatives) for those resources.
  • 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, #summary