Feature/gutenberg deprecation fix

[jomurgel]

Closes #51, #50, #49

DESCRIPTION

Reference: https://wordpress.org/gutenberg/handbook/reference/deprecated/

Resolves issues that arose during mass deprecation/improvements from the core Gutenberg build 2.9.2+

Relocates the following once in wp.blocks now in wp.editor. In our case:

• ColorPalette
• InspectorControls
• BlockControls
• BlockAlignmentToolbar
• AlignmentToolbar
• RichText
• MediaUpload
• PlainText
• BlockIcon
• UrlInput

Resolved issues with uses of this.props.focus or props.focus which no longer exist. Used, instead, more stable this.props.isSelected or props.isSelected where applicable.

Removed { description } = wp.blocks used in a few places related to the MediaUpload and SelectControl components. No longer a valid block, removes in favor of inline paragraph.

Resolved issue with the Related Posts block search parameter defaulting to users instead of posts.

Resolved issues with any RichText component which was throwing deprecation warning. Focus handlers no longer required with updates above.

Raw TinyMCE event handlers for RichText is deprecated and will be removed from gutenberg in 3.0. Please use Documented props, ancestor event handler, or onSetup access to the internal editor instance event hub instead.

I believe this also closes #51, as I can no longer replicate the issue described in the task, and resolves the width issues described in #50.

It also closes #49 which was missing the ability to remove and image or video once uploaded.

Note

There are still issue with media upload buttons rendering when ACF is active — a known issue documented here. This was fixed in ACF 5.7, but older versions may run into issues below that version.

Steps to Verify

Tested all blocks by adding to new page changing, updating and modifying block content, background options, block options and inline search/select options.

Everything works as initially intended except for a few issues noted in the issues here regarding a few blocks.

[gregrickaby]

My only issue is the Recent Posts block. As soon as I add it, I get the "cannot update post" error, and then when I reload the page I see this in the dashboard: 😬

• Chrome 67
• I just did a MigrateDB Pull from Lab
• I have the latest versions of all themes/plugins and WP v4.9.6

I went ahead and bumped the versions and such in anticipation of this getting merged in. Thank you for your effort here @jomurgel! 🌮 ❤️

[jomurgel]

@gregrickaby have the same chrome version, fresh MigrateDB pull from Lab and all of the latest versions of the plugins + repo and I don't have the same outcome. Might have to do a screen share on this to hopefully nail it down. I would bet it has something to do with the render.php file though given some similar behavior once upon a time during initial dev.

[jomurgel]

The issue still appears to be around the use of the_excerpt() or get_the_excerpt() which is documented here: WordPress/gutenberg#5572

The issue also appears to affect the Related Posts block also depending on the posts that are pulled in. I'm unable to replicate the issue if I use older posts that contain any post_content.

In this case, the post_content of the "Test" post 243 is empty containing only the commented list of attributes to render the Recent Posts blocks.

Sort of two issue here, one is if there is no post content to display ( in this case it is since the Recent Posts block is dynamically relying on the render.php function ) it will error, and two if there is no manual excerpt AND no post content we error. Obviously, this isn't ideal and most people don't add manual excerpts. So we need to compensate for an instance where the excerpt doesn't exist.

One potential fix is to do something like this which makes sure we have an excerpt before trying to call either of those two functions.

<?php
// Make sure we have an excerpt.
if ( ! empty( $the_query->post->post_excerpt ) ) :
	the_excerpt();
endif;
?>

The downside to this is that the excerpt here in this case is an empty string '' where as the excerpt via the api is what appears on the admin editor screen so our admin looks like this:

and our front end looks like this:

Option two is to create an excerpt manually with post content. Something like (obviously would need refactored):

echo substr( strip_tags( strip_shortcodes( $the_query->post->post_content ) ), 0, 200 );

Which would output this

It's not the ideal solution either because it still differs from the API post.excerpt.rendered, what is shown in the admin.

Option three is to pull the excerpt directly from the API during render. There are a few issues I'm seeing with this other than that it could be expensive and that is that it may not work in every environment (certainly doesn't work with Local by Flywheel without some additional work.

Option four is to pass the excerpt in from the js into the $attributes and utilize that. A little more work required to get that working and I feel like a large undertaking for a small issue.

The solution I've come up with is a mixture of options 1 and 2 and I think might solve our problem which, if our excerpt is empty, generate one from post content. If we don't have post content return an empty string. Of course if we have a manual excerpt, return that.

Not the best solution as, again, it doesn't render the same as what's in the API's post.excerpt.rendered, but it also is actually a more accurate reflection of post content.

Added a new block-helpers.php file in template-tags and calls that in the Recent and Related Post Blocks.

• cf6cfd3
• 184dd2d
• a909a2d

Output ends up looking like this:

Test, in this case, has no post content and thus has no excerpt. It's not 100%, but more in line with what's in the admin.

[gregrickaby]

@jomurgel This worked on the first try! 🥇