The-seo-framework: Gutenberg.

[sybrew]

The goal: Add complete compatibility with Gutenberg. Improve layout if necessary.
AFAIK most works already.

Please report any issues as you find them 😄

[sybrew]

Found issues:

Metabox

• It's out of place and ugly.
  
  
  
  • We'll probably disable the metabox (see this, ['__block_editor_compatible_meta_box' => false]) (repurposed) and put it in the "Document" sidebar (see image below).
  
  

Example, a quick and dirty manually injected "metabox":

Titles

• The title listeners no longer work.
  
  
  
  • The (updated) page title isn't reflected upon in the SEO title.
  
  
  • Setting the post to private/password protected no longer displays its prefix.
  
  
• The title input field isn't full-width anymore.

Debug

• The TSF debug screen overlaps the editor. It needs to be pushed down.

[sybrew]

The sidebar has been made possible.

To not pollute the Gutenberg's GitHub (pull request 4777), here's the sample execution:

wp.editPost.registerSidebar( 
    "my-plugin/my-sidebar", 
    {
        title: "Name",
        render: () => { return <div>My sidebar</div>;}
    } 
);

wp.editPost.activateSidebar( "my-plugin/my-sidebar" );

[sybrew]

We're going to skip the sidebar implementation for now and work on making the current meta box' data reactive to the Gutenberg interface only.

---

To get an idea of how f7552fc looks, which is going to be reverted due to the huge number of bugs:

[sybrew]

_A foreword: We don't have to integrate, migrate, or resolve anything.
The SEO Framework works as-is with Gutenberg, already. However, the perfectionist in me knows that the current behavior isn't what it should be. The "trick" (more on that below) in Gutenberg is not done nicely._

That said, the full integration will be moved from 3.1 to a later version.

Putting everything in the sidebar

Remember, Gutenberg never intended to support the Metabox API. I believe the Gutenberg team wanted to release it without this support. This is a fundamental flaw in the system, which the project team (eventually) alleviated via a "trick" system in Gutenberg 1.5, AKA gutenberg_trick_plugins_into_registering_meta_boxes(). The proof is in the pudding code.

Injecting the settings in the sidebar (as shown above) won't work. The input-data will be erased as soon as the user switches a block (by deleting the DOM elements). This is how React is intended to work.
However, users on Facebook (where React is originally written for) generally don't have to save important business-related work on their platform.

To resolve this, we'll have to implement something like SidebarContentsWithDataHandling from their API example. This will need to be written with React.

With this, using JSX would be the smartest path to follow. Settings this up will probably require us to create and maintain a sub-project. And, after compiling this for Gutenberg, it will triple the size of our plugin.

With ES6, we could do this with just a few kilobytes. But, maintaining it will be a nightmare.

Estimated integration time: 600~900 hours.

Which roughly equates to 15 to 28 weeks (3 to 7 months) of work. Taking opposite ends of full-time work-schedules into account.

This number is based on the number of things that need to be (re)written. Most prominently, the way TSF currently communicates via posts; which, mind you, is according to the current Post Meta API. We need to put the current meta handler aside, and write a new one for Gutenberg from the ground up. And, we'll have to find a way to migrate the current post meta. I have no idea how to do this, I couldn't find any documentation (not even in the code) on integrating metadata.

After spending all this time migrating and integrating the new settings, we'll have brought nothing new to the user.

In short: Gutenberg alienates existing plugin developers.

Solving current (and known) issues.

The current issues, listed here, aren't ground-breaking. They're mere annoyances. They lead to impeded UX behavior: The user needs to refresh the page to know what TSF renders.

Now, we currently can't read the data from Gutenberg via plain JS (or jQuery, if you're in that boat).

There are no specific 'events' accessible that allows us to read data on-the-fly (without a huge amount of overhead). See SyntheticEvent. With this limitation, we can only read Gutenberg's live data via two methods:

1. By adding DOM observers, that periodically look for DOM elements and read their data as they become accessible. We'll then have to maintain a cache.
2. By integrating into Gutenberg via React.

Adding observers will be a good way to introduce bugs. Integrating via React is the smartest thing to do; but, that'll force us to add external observers regardless. This, too, adds a lot of work-load.

Automattic: Please add a data-interface

What would be awesome is that Gutenberg adds an API from which we can access all live post-data on-the-fly, via predefined IDs, while emitting "hey we updated"-events. This might already be possible, but I have yet to find an interface.

As a small reminder on why WordPress is where it is today, see this innovation.

If this were to be available, I'll be able to resolve all known issues easily.

[sybrew]

Update, I found the data-interface!

TSF's Gutenberg integration is back where it should be. Although one major version later.

I've found a way to access the data. In a single line, it should look like this:

wp.data.select( 'core/editor' ).getEditedPostAttribute( attribute );

We can instantiate the wp.data object into a constant, and even the function thereof.

The attributes we're interested in:

content (Focus)
title (Focus & Title Reference/Placeholder update)
generated_slug & slug (Focus & Canonical Placeholder update)

Focus can benefit from using an interval or observer (via wp.data.subscribe()).
This will be placed into the monkeypatch() area.

[sybrew]

WP 5.0 is going to be released much sooner than I (many of us) expected:
https://make.wordpress.org/core/2018/10/03/proposed-wordpress-5-0-scope-and-schedule/

TSF 3.2.0 will be solely Gutenberg focussed.