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

4.8 Bug Scrubs for Beta 1

The following bug scrubs have been planned for the 4.8 release:

Reminder that Friday, May 12th is 4.8 Beta 1 and from that point on, no more commits for any new enhancements or feature requests will be allowed in this release cycle, only bug fixes and inline documentation. Work can continue on enhancements and feature requests not completed and committed by this point, but will not be picked up for commit again until the start of the WordPress 4.9 release cycle.

As a refresher, here’s a post from the 4.7 release cycle answering questions about bug scrubs.

#4-7, #4-7-5, #4-8, #bug-scrub

Week in Core, April 26th – May 2nd 2017

Welcome back the latest issue of Week in Core, covering changes [40557-40568]. Here are the highlights:

  • 12 commits
  • 13 contributors
  • 76 tickets created
  • 4 tickets reopened
  • 29 tickets closed

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes


  • Accessibility: Avoid a keyboard trap on the date and time custom format settings. [40568] #40515

Build/Test Tools

  • When asserting microtime output as a number, make it a number [40566] #30336
  • Automatically skip tests in the ms-required and ms-excluded groups. [40564] #40531
  • Pin the WordPress Importer plugin to version 0.6.3 when testing on Travis. [40562] #40620
  • Add object-cache.php to the unit test suite. [40561] #40619



  • Allow select dropdowns to stretch full width in widened controls pane. [40567] #32296


  • Introduce page_menu_link_attributes filter in Walker_Page::start_el() for the HTML attributes applied to a page menu item’s anchor element. [40565] #40359

Posts, Post Types


  • Users: Add two missing special cases to the capability tests for non-logged-in users. [40563] #37405


  • Ensure user counts remain accurate if users are added to or removed from the users table without corresponding usermeta entries being added or removed. [40560] #38741, #29785

Thanks to @afercia, @boonebgorges, @dots, @jdgrime, @johnbillion, @pbiron, @psoluch, @ptbello, @SergeyBiryukov, @stephdau, @tharsheblow, @timmydcrawford, and @westonruter for their contributions!


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

Dev Chat Agenda for May 3rd (4.8 week 1)

This is the agenda for the weekly dev meeting on May 3, 2017 at 20:00 UTC:

  • 4.8 timing
  • 4.8 bug scrubs
  • 4.8 dev notes / field guide
  • @flixos90: multisite update
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-8, #agenda, #dev-chat

JavaScript Chat Summary: May 2nd

The first-ever JavaScript Chat took place today (agenda, Slack archive). Below is a summary of the conversation:

Meeting Goals

  • Identify common requirements and ensure consistency between individuals and projects making heavy use of JavaScript in core
  • Discuss what must be provided as the “base” APIs to provide similar functionality in the browser as what’s available in PHP
  • Decide patterns and tools / frameworks to accommodate modern and future requirements
  • Understand how plugins and themes plan to use the browser context to avoid conflicts and incompatibilities


The following tickets were discussed, chosen as having most immediate impact:

Actions and Filters

  • An effort to mirror PHP extensibility in the browser by providing hooks to transform data and take action in response to specific events
  • Consistency with PHP equivalents can improve developer experience by providing familiar tools, but we should be sure that the paradigms apply well across the languages
  • Worries
    • Are there special considerations for asynchronous coding patterns prevalent in JavaScript?
    • Do we first need to better outline how we expect data to be structured and managed in the client before deciding on transformation APIs?
  • Alternatives
    • Hyper.is extensions apply themselves as decorations, or intervene as middlewares in the application’s data flow
    • Reactive programming styles with observables (spec proposal, RxJS)
  • A side-exploration of data modeling requirements was raised, with a general desire to encapsulate state (perhaps in a single store) and provide options to inspect data and apply modifications at specific entry points. This should be able to be adopted incrementally, rather than as a full rewrite.

Date Handling

  • Ticket patch provides basic date formatting and localization on a wp.date global, matching those available in PHP (format, date, gmdate, date_i18n)
  • Non-controversial and ideally merged soon
  • Current proposed patch uses Moment.js, but interface does not bind us to it
  • We may want to consider future compatibility with overlapping browser APIs, such as DateTimeFormat. However, these implementations are browser-specific and compatibility with the date format site setting can’t always be guaranteed.


  • We need gettext support in the browser
  • How do we make strings available in the browser
    • By passing strings in HTML via wp_localize_script?
    • Asynchronously through REST API endpoints?
    • Probably best to stick with simpler approach to start (passed in HTML)
  • Need to consider build tools to extract strings from JavaScript
    • PHP solutions may not be future compatible with the frequently changing JavaScript language specification. This is a solved problem with JavaScript parsers tending to follow closely to the bleeding edge.


Please join us when we meet again next week at the same time. In the meantime, there are many tickets in the Trac JavaScript focus that can use help! https://core.trac.wordpress.org/focus/javascript

#javascript, #summary

REST API meetings moving to 1300 UTC Weds

The REST API team meeting is moving to 13:00 UTC on Wednesdays. After several weeks of schedule difficulty we will reconvene tomorrow (Wednesday May 3 at 13:00 UTC) to reprioritize our ongoing efforts in light of the new JavaScript working group chat. See you there!

Announcing the first Weekly Core JavaScript Chat

Please join us tomorrow Tuesday May 2nd at 13:00 UTC for the inaugural Weekly Core JavaScript Chat.

The following is the meeting agenda:

  • Discussion of goals of Weekly JS meetings – whats next for JavaScript in core?
  • Ticket discussion:

What goals or topics do you think deserve discussion? Add your ideas in the comments below.


Dev Chat Summary: April 26th (4.7.4 week 8)

This post summarizes the dev chat meeting from April 26th (Slack archive).

News & Updates

Target Browser Coverage

  • WordPress is officially ending support for Internet Explorer versions 8, 9, and 10, starting with WordPress 4.8
  • @voldemortensen: When patches are backported to versions pre-4.8 should they be tested against older IE versions? Are we maintaining that sort of back compat for this or once 4.8 ships we drop support for it everywhere?
    • Unlikely that anyone will test that support on backported branches
    • The “Everything else: Bugs fixed as reported.” rule from the handbook could be stretched and applied to those IE versions
    • Will continue down that path until an alternate approach for backports to versions pre-4.8 is confirmed more officially

Editor Team

  • aiming for prototype parity by the end of month
  • will gladly take any assistance on resolving issues and testing via their GitHub repo

Customize Team

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

Dev Chat Summary: April 19th (4.7.4 week 7)

This post summarizes the dev chat meeting from April 19th (agendaSlack archive).

4.7.4 Release Timing

  • We pushed out that RC for 4.7.4 yesterday, please test it diligently
  • So far there’s been one bug report on Trac which is assigned to @azaozz: #40480: Cursor position bug when updating WPView shortcode in 4.7.4 RC
  • Otherwise no apparent activity in the forums
  • If everything goes well the plan is to release 4.7.4 by tomorrow, Thursday, April 20th starting at 16.00 UTC


  • A few common themes coming up while we’ve been working on with using the REST API in the dashboard
  • In particular, a common need for date handling, hooks, and i18n across various different components
  • The other two foci will either hit into this or already have, so we propose to coordinate on a common goal here (see: #39222, #20491, and #21170)
  • Propose that we nominate someone to coordinate efforts across these, including use in the Gutenberg prototype
  • Potentially someone who can look at wider, longer term plans with JS as well
  • Assumption that there’s a broad problem here, which is that we’re lacking coordination and direction for our JS stuff
  • It may help to start having core-js meetings to coordinate this, and/or for someone to take charge of the discussion
  • @aduth & @adamsilverstein will team up to lead this effort

General Announcements

  • #40462: Add placeholders to wp_login_form()
    • users in the Israeli WordPress community requesting feature
    • Previously #24324: Placeholder support to login form
    • Will add use cases to the ticket to explain why it would make sense
    • Otherwise mark it as a duplicate and keep discussion in one place

#4-7, #4-7-4, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary