Support for WordPress 5.0 and the new editor - Gutenberg

[bobbingwide]

Since early 2017 a new editor has been under development. Code named Gutenberg this new editor is being developed as a feature plugin. It is expected to be merged into core for WordPress 5.0. We need to be aware of Gutenberg and to attempt to be compatible with it.

Area	Problem	Reference
Editor	Does not show when HEARTBEAT false	see below

Editor not showing when HEARTBEAT = false

In oik-clone there is some logic that was developed to prevent heartbeat processing while updates are in progress.

// Temporarily disable heartbeat processing
// 
    if ( defined( "HEARTBEAT" ) && false == HEARTBEAT ) { 
        wp_deregister_script('heartbeat');
    }

Gutenberg is dependent upon the heartbeat script and won't work at all when it's been deregistered.

Workaround

Don't define( 'HEARTBEAT', false ) in wp-config.php

Proposed solution

Find another way of disabling heartbeat processing when running clone on update.

[bobbingwide]

Two other problems arose when cloning a post created using the new block editor.

1. Uploaded images were not cloned... since they had not been attached to the post.
2. After attaching they were still not cloned since the _wp_attached_file post meta contained the full path name where it should have been a relative path name.

Both problems are known issues the second one being a core REST API issue.

1. Https://github.com/wordpress/gutenberg/issues/1586
2. Https://github.com/wordpress/gutenberg/issues/5332 There is no simple workaround for the second problem.

[bobbingwide]

The cloning logic will also need to be improved to detect post IDs stored in block attributes that will need to be mapped to different ID when cloned. It will also need to be able to clone wp_block posts.

[bobbingwide]

Problem encountered today is that new line characters stored for block attributes in the HTML comments for the block are lost in the cloning process. The \n loses the backslash - so we get unexpected ns and the tables are all wrong.

[bobbingwide]

Further investigation of the backslash cloning problem is that it occurs when cloning a post for the first time. For updates the backslashes are not lost. Therefore it must be something in the wp_insert_post logic in the target server. At least I've reproduced it locally so can now test it; cloning from s.b/wordpress to s.b/wp50.

For updates follow #22.

[bobbingwide]

Cloning of the Block icon block does not work properly. When the cloned post is edited in the block editor we see.

Source of the Block before cloning is:

<!-- wp:oik-block/blockicon {"blockicon":"oik-block/address","className":"svg64"} -->
<div class="wp-block-oik-block-blockicon svg64"><span class="editor-block-icon"><svg aria-hidden="true" role="img" focusable="false" class="dashicon dashicons-building" xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewbox="0 0 20 20"><path d="M3 20h14V0H3v20zM7 3H5V1h2v2zm4 0H9V1h2v2zm4 0h-2V1h2v2zM7 6H5V4h2v2zm4 0H9V4h2v2zm4 0h-2V4h2v2zM7 9H5V7h2v2zm4 0H9V7h2v2zm4 0h-2V7h2v2zm-8 3H5v-2h2v2zm4 0H9v-2h2v2zm4 0h-2v-2h2v2zm-4 7H5v-6h6v6zm4-4h-2v-2h2v2zm0 3h-2v-2h2v2z"></path></svg></span></div>
<!-- /wp:oik-block/blockicon -->

Source of the block after cloning, when viewed in the Code editor is:

<!-- wp:oik-block/blockicon {"blockicon":"oik-block/address","className":"svg64"} -->
<div class="wp-block-oik-block-blockicon svg64"><span class="editor-block-icon"></span></div>
<!-- /wp:oik-block/blockicon -->

The SVG tag appears to have been stripped. The console log contains this message.

[bobbingwide]

In the server, the post content is filtered in the content-save_pre filter with wp_filter_post_kses. When the post is editied in the client this filter function is not being invoked.
So the proposed solution is to remove the filter during cloning. Just need to find out when the filter function is added and when it's not.

OK then, let's just call kses_remove_filters() in oik_clone_attempt_import.

[bobbingwide]

Of the problems reported above this one has not been addressed. https://github.com/bobbingwide/oik-clone/issues/24#issuecomment-369845157 Cloning of wp_block posts should be possible by updating the post type registration. That can be done using oik-types.

But it’s detecting the referenced posts that could be more of a problem.

[bobbingwide]

The cloning logic will also need to be improved to detect post IDs stored in block attributes that will need to be mapped to different ID when cloned.

This problem has now occurred. When cloning the block definitions for the two advanced-gutenberg-blocks blocks that are dependent upon WooCommerce the productID attributes are not mapped.

Failure to map the IDs led to fatal errors in the blocks. The problem is compounded by the fact the WooCommerce may not be activated on either end of the clone... so the post IDs may not be recognised as mappable; get_post() might fail if the post type is not registered? Perhaps get_postmeta() can be used to find the mapping.

New logic will be needed to perform mapping of attributes which contain IDs.

[bobbingwide]

The new logic implemented for #38 goes a long way to solving the problem of dealing with WordPress blocks. It’s a hybrid solution at present that uses a new method for dealing with IDs in attributes in blocks and the original method for handling IDs in shortcodes.

Although it has its limitations, such as not being able to map taxonomy term IDs, and it lacks unit tests, I feel it’s OK for this to be closed.