What’s new in Gutenberg? (June 23rd)

Released version 0.1.0 in the plugin directory last week. 🎉

Releasing version 0.2.0 today, which includes all the following changes:

We welcome all your feedback and contributions on the project repository, or ping us in #core-editor. Check the “gutenberg” tag for past updates.

#core-editor, #editor, #gutenberg

What’s New in Gutenberg? (June 12th)

In Progress (all)

We welcome all your feedback and contributions on the project repository, or ping us in #core-editor. Check the “gutenberg” tag for past updates.

#core-editor, #editor, #gutenberg

Dev Chat Summary: June 7th (4.8 week 6)

This post summarizes the dev chat meeting from June 7th (agendaSlack archive).

4.8 timing recap and Pre-Final Release & Dry Run checklist items

  • Beta 1 went out on Friday, May 12th; Beta 2 went out on Monday, May 22nd
  • RC1 went out on Thursday, May 25th; RC2 went out on Thursday, June 1st
  • 4.8 is scheduled for June 1, 2017 at 9am EDT
  • Events widget looks ready
  • Credits API to be updated by @ocean90 tomorrow morning
  • About page update for responsive, CDN-hosted images coming from @melchoyce
  • Announcement post draft is ready to go; @jorbin & @ocean90 to help provide contributor & language count as input
  • Announcement email being drafted by @matt
  • Codex page to be updated by @jbpaul17
  • Agreed to remove “partial back to IE8” from Browser support page in Design handbook
  • tinymce/plugins/wpembed to be added to $_old_files by @ocean90
  • No new default theme, so $_new_bundled_files is fine
  • Updates to default themes and submission to repo to be done by @davidakennedy, committed by @ocean90
  • Hosts email to be drafted by @jbpaul17, email to be reviewed & sent by @jorbin
  • Systems to be covered by @vnsavage
  • grunt prerelease check for tests & standards to be run by @jorbin

4.8 Bug Scrub

  • Reviewing four tickets in Defects Awaiting Review, reported against trunk section from Report 40
  • #40929: relates to improved translator docs, punting to next minor release (4.8.1)
  • #40932: moved to Future Release
  • #40927: not a regression, moved to Future Release
  • #40906: marked as a dupe of #40685, not a blocker for 4.8

Other News

  • Customize: looking for a new contributor to work on the HTML/Code widget, a good-first-bug, please chat in #core-customize if you’re interested
  • Editor: working to get the plugin in the plugin repo so that more people can review it and provide feedback. Goal is this week.
  • Devchat coordination: will be covered in upcoming devchat

#4-8, #core, #core-editor, #dev-chat, #summary

What’s New in Gutenberg? (June 5th)

In Progress (all)

We welcome all your feedback and contributions on the project repository, or ping us in #core-editor. Check the “gutenberg” tag for past updates.

#core-editor, #editor, #gutenberg

Dev Chat Summary: May 31st (4.8 week 5)

This post summarizes the dev chat meeting from May 31st (agendaSlack archive).

4.8 Timing

  • Beta 1 went out on Friday, May 12th; Beta 2 went out on Monday, May 22nd; RC1 went out on Thursday, May 25th
  • RC2 is scheduled for Thursday, June 1st
  • With RC2 we’re aiming for a hard string freeze so that translators can complete all the new strings in 4.8
  • Should things continue to go to plan, 4.8 release would be next Thursday, June 8th

4.8 Bug Scrub

  • Currently at 4 tickets in the milestone, goal is to get to 0 by RC2
  • #39822 has ongoing commits to improve Build/Test Tools in relationship to PHPUnit 6
  • #40893 is a bug that used to be caused by themes, but now there is a notice in the UI about it [Note: since committed and closed]
  • The TinyMCE-extended Text widget provides a suboptimal UX for users who have been accustomed to pasting in 3rd-party JavaScript code (widgets) into the Text widget
    • Relates to #2833
    • Considerations considered include code, documentation, and/or UI updates to improve the UX
    • Suboptimal UX includes three separate but related issues:
      • 1) Extra whitespace from content pasted in
      • 2) HTML being encoded after it is pasted in
      • 3) line breaks in JS causing the JS to break due to new <p>
    • #1 & 2 are likely best solved with documentation and some outreach
    • #3 appears to be the most severe, but also the biggest edge case
    • Proposal:
      • 1) In the very short term, create documentation to help 3rd parties (e.g. MailChimp, Infusionsoft) and utilize people with a wide and respected reach to do some outreach with that documentation
      • 2) For 4.8.0, don’t make any code related changes
      • 3) Continue looking into this and exploring what we could change for 4.8.1
    • Note the TinyMCE Text Widget post has been amended to note the need to remove extraneous line breaks, especially when pasting in script snippets
    • If you’re able to help with documentation or outreach on this, please call out in #core.
  • #40865 has patch, needs review for commit in 4.8/punt to 4.8.1
  • #40721 committing final strings tonight, only hours remain for feedback

4.8 Dev Notes / Field Guide

  • Many thanks to all writing, reviewing, and otherwise contributing to getting all the dev notes published recently!
  • Also 🙌 to @pbiron & @desrosj for their help getting the field guide published alongside RC1

Other News

#4-8, #dev-chat, #summary

What’s New in Gutenberg? (May 29th)

In Progress (all)

We welcome all your feedback and contributions on the project repository, or ping us in #core-editor. Check the “gutenberg” tag for past updates.

#core-editor, #editor, #gutenberg

What’s New in Gutenberg? (May 22nd)

We’ll start making weekly posts here in the name of making the ongoing editor updates more visible outside of the Slack channel and the GitHub development stream. At the moment there are 13 blocks implemented in the project, and a few more being worked on by the team and contributors.


In Progress

We welcome all your feedback and contributions on the project repository, or ping us in #core-editor.

#core-editor, #editor, #gutenberg

Dev Chat Summary: May 10th (4.8 week 2)

This post summarizes the dev chat meeting from May 10th (agendaSlack archive).

4.8 Timing

  • Reminder of Beta 1 on Friday, the complete 4.8 schedule is on Make/Core
  • At this point we’re not trying to get anything in 4.8 besides the core media widgets, dashboard news upgrade, and the next version of TinyMCE (4.6.0)
  • Merge deadline goal to have the target features today (Wednesday, May 10th), and things generally closing on Friday, May 12th
  • Friday 8 PM UTC as pencils down and the beta packaging process / release to happen
  • We’ll schedule a post hoc debrief on our workflows to be more like Chrome, with frequent, major, auto-updates

4.8 Bug Scrubs

4.8 Dev Notes / Field Guide

  • Target to post Dev Notes shortly so they can be combined, published in, and communicated with the Field Guide when the Release Candidate ships around May 25th
  • Updated listing of Dev Notes needed and those responsible:
  • Per the Releasing Major Versions page, we should aim for Dev Notes around Beta 1 so let’s call that sometime next week as current focus is on actually getting to commit for Beta 1 this week

Customize, Editor, and REST API Updates

  • Customize: A general heads up to theme authors to please test the core medias widgets for compatibility issues. The sooner issues are identified the better to get them resolved before 4.8 ships.
  • Editor: They hope to tag a first pre-alpha release of the plugin this week, so keep your radars scanning for that notification to jump in to test and provide feedback there. If you’re curious how they’re building out the foundation of Gutenberg, then read “Editor: How Little Blocks Work“.
  • REST API: They would greatly appreciate any and all feedback on #38323, especially those of you familiar with meta. This isn’t crucial for 4.8, is crucial for many use cases and any help getting this into an upcoming release would be great.

#4-8, #core-customize, #core-editor, #core-restapi, #dev-chat, #media-widgets, #summary, #tinymce

Editor: How Little Blocks Work

The editor focus is progressing at a steady pace, with some of the major elements taking shape, so it’s a good time to provide an update. This is a complicated flow so a diagram helps explain things a bit better:

The logic flow for the editor is the following:

  • ① inferring a block representation of the post content (parsing);
  • ② describing the post as an ordered list of blocks (state tree);
  • ③ representing the post in the DOM (rendering);
  • ④ attaching controls to manipulate the content a.k.a blocks (editing UI).

Generally speaking, in a declarative paradigm, the state of the application is structured in an easy machine readable format so that what is rendered is a reflection of the state of the application, and where manipulations are represented as a unidirectional flow. However, the reality is we don’t start in WordPress with a representation of the state of the post that has such structure—there’s no knowledge of “blocks” because content is stored serialized in a single flat field.

So our first step is to infer the structure we need from implicit cues. This is a crucial step that makes the double loop in the above diagram work. It is handled by the grammar and parsing mechanism which takes the flat content of the post and infers a tree of ordered block data using, preferably, syntax hints present in HTML comments. The editor is then initialized with a state representation of the block nodes (the middle yellow rectangle in the diagram) generated by the parsing of the raw post content.

We are basically augmenting the structured representation of the post to aid us in building a robust editing tool that can be expressive and limit side effects. The visual editor is then a view that contains and renders the list of block nodes from the internal state into the page, using the shape of markup defined by all registered blocks involved. This removes the need for imperative handling in both finding a block and manipulating its attributes. Blocks provide functions that describe how they want to be represented for both the editing context and the final markup to be saved. The internal representation of the post content is updated as blocks are updated, so during the editing session we can remain in the right side of the diagram above. Finally, when it is time to save the post, the data is serialized back into post_content with HTML comment delimiters to reset the cycle.

The foundation is a bit complicated, but the goal is that creating individual blocks is easier and protected from the technicalities of the process. The rendering of blocks for editing is handled by a VisualBlock component, which attaches event handlers and renders the edit function of a block definition to the document with the corresponding attributes and local state. The edit function is the markup shape of a component while in editing mode, which can be augmented to provide very rich interactions for users. You can take a glance at some of the existing blocks we have so far to get an idea for how the API works and what it takes to build a block. Keep in mind the API is not finalized and tweaks are happening frequently.

If you want to help with this project, head over to #core-editor in Slack or follow the activity in the GitHub repository.

#core-editor, #editor

Dev Chat Summary: May 3rd (4.8 week 1)

This post summarizes the dev chat meeting from May 3rd (agendaSlack archive).

4.8 Timing

  • 4.8 schedule page has been published
  • Beta 1 is next Friday, May 12th; Release Candidate is Thursday, May 25th; target launch is Thursday, June 8th; and WCEU quickly follows June 15-17
  • WordPress 4.8 will be the first “major” release of 2017 and ideally includes the TinyMCE inline element / link boundaries, new media widgets, WYSIWYG in text widget, and the WordCamp / meetup dashboard upgrade to the “news” section
  • Assuming all goes as currently planned, we have just over a week to commit any new enhancements or feature requests
  • Concerns were raised to the compressed timeline for 4.8 and the stresses of getting a major release out in ~5 weeks
  • Recommendations were made to the effect of allowing 4.8 to progress more gradually and target a July/August timeframe for launch
  • Update since devchat: Confirmed existing 4.8 timeline with @matt, plan is to proceed with the enhancements that are ready now, anything that’s not ready will wait for an upcoming release

4.8 Bug Scrubs

  • Will publish times for upcoming scrubs to review items in the 4.7.5 and 4.8 milestones in a separate Make/Core post
  • @jbpaul17 & @desrosj will run general scrubs, @flixos90 will deal with multisite tickets in the multisite-specific bug-scrub next Monday
  • Please reach out to @jbpaul17 if you have availability to run a general or focused scrub on tickets in the 4.7.5/4.8 milestones over the next wee

4.8 Dev Notes / Field Guide

  • Regardless of final decision on 4.8 timeline, we need to get started on creating Dev Notes and assembling the Field Guide
  • Several comments were made about potential improvements to the Dev Notes / Field Guide during the 4.7 Retrospective
  • In summary: have more than one person own the Field Guide coordination and Dev Notes creation; more Dev Notes are better than less; create component-specific Dev Notes where feasible
  • Updated listing of Dev Notes needed and those responsible:
    • 1) Editor: TinyMCE inline element / link boundaries – @iseulde & @azaozz
    • 2) Editor: TinyMCE version 4.6 – @iseulde & @azaozz
    • 3) Editor: Edge fixes – @iseulde & @azaozz
    • 4) Customize: Media widgets (#32417)
    • 5) Customize: Visual text widget (#35243)
    • 6) Customize: Dynamically-resized controls pane (#32296)
    • 7) WordCamp / meetup dashboard upgrade to the “news” section
  • If you can help write one of the unassigned Dev Notes above or have others that you feel should be written, please comment on this post or let @jbpaul17 know
  • Per the Releasing Major Versions page, we should aim for Dev Notes around Beta 1 and the Field Guide by the Release Candidate; so please get started writing those Dev Notes, thanks!

Multisite Update

  • Discussed yesterday the idea of introducing ms-site.php and ms-network.php files for the real site/network APIs we’ve been introducing over the past couple releases (and will continue to introduce further functions)
  • All functions currently reside in ms-blogs.php which is getting rather cluttered
  • We propose introducing those two files and moving some functions in there and are looking for concerns from the team
  • Another question was whether they would need to be included from ms-blogs.php (for backwards compatibility) or whether we’re fine including them in wp-settings.php
  • Relates to: #40647 (Introduce ms-site.php and ms-network.php files)
  • Feedback would ideally be left on the ticket above

#4-8, #core-customize, #core-editor, #dev-chat, #summary