How to (not) correctly load Gutenberg JS

On Facebook someone asked me how to do Gutenberg the right way to avoid loading too much JS on the frontend, this is a somewhat better organized version of my answer;
I’m not a Gutenberg specialist (for from it, really) but:

  • the wrong way is adding JS with wp-block/ wp-element and other gutenberg dependencies on init calling wp_enqueue_script,
  • the right way is either hooking into enqueue_block_editor_assets (see https://jasonyingling.me/enqueueing-scripts-and-styles-for-gutenberg-blocks/)
  • or when using init doing wp_register_script and then register_block_type referring to the correct editor_script previously registered (see https://wordpress.org/gutenberg/handbook/designers-developers/developers/tutorials/block-tutorial/writing-your-first-block-type/).

I’ve tried both of these on a “bad” plugin and can confirm both solutions do prevent those needless wp-includes/js/dist/* JS-files from being added on the front-end.

Developers: don’t make Gutenberg go Badass-enberg on my frontend!

Over the past couple of months, since the release of WordPress 5.0 which includes Gutenberg, the new JavaScript-based block editor, I have seen many sites loading a significant amount of extra JavaScript from wp-includes/js/dist on the frontend due to plugins doing it wrong.
So dear plugin-developer-friends; when adding Gutenberg blocks please differentiate between editor access and visitor access, only enqueue JS/ CSS if needed to display your blocks and when registering for front-end please please frigging please don’t declare wp-blocks, wp-element, … and all of those other editor goodies as dependencies unless your 100% sure this is needed (which will almost never be the case).
The performance optimization crowd will thank you for being considerate and -more likely- will curse you if you are not!

(When) Should you update to WordPress 5.0?

Concerning the very short-notice release-announcement of WordPress 5.0 with Gutenberg for Dec 6th: I’m with Yoast;He has a great “should I update”-checklist and conclusion in this blogpost;

  • Is now the right time to update?
  • Can your site work with Gutenberg?
  • Do you need it?

So our advice boils down to: if you can wait, wait. 

So if you have a busy end-of-year, if you’re not 100% sure your site will work with Gutenburg or if you don’t really need Gutenberg in the first place; wait (while WordPress 5.0 stabilizes with some minor releases).

Long overdue: WP YouTube Lyte update

It took me way too long (Autoptimize and related stuff is great fun, but it is eating a lot of time), but I just pushed out an update to my first ever plugin; WP YouTube Lyte. From the changelog:

So there you have it; Lite YouTube Embeds 2018 style and an example Lyte embed of a 1930’s style Blue Monday …

Orkestra Obsolete play Blue Monday using 1930s instruments - BBC Arts

How to extract blocks from Gutenberg

So Gutenberg, the future of WordPress content editing, allows users to create, add and re-use blocks in posts and pages in a nice UI. These blocks are added in WordPress’ the_content inside HTML-comments to ensure backwards-compatibility. For WP YouTube Lyte I needed to extract information to be able to replace Gutenberg embedded YouTube with Lytes and I took the regex-approach. Ugly but efficient, no?
But what if you need a more failsafe method to extract Gutenberg block-data from a post? I took a hard look at the Gutenberg code and came up with this little proof-of-concept to extract all data in a nice little (or big) array:

add_action('the_content','gutenprint',10,1);
function gutenprint($html) {
  	// check if we need to and can load the Gutenberg PEG parser
  	if ( !class_exists("Gutenberg_PEG_Parser") && file_exists(WP_PLUGIN_DIR."/gutenberg/lib/load.php") ) {
  		include_once(WP_PLUGIN_DIR."/gutenberg/lib/load.php");
	}
  	if ( class_exists("Gutenberg_PEG_Parser") && is_single() ) {
	  // do the actual parsing
	  $parser = new Gutenberg_PEG_Parser;
	  $result = $parser->parse(  _gutenberg_utf8_split( $html ) );
	  // we need to see the HTML, not have it rendered, so applying htmlentities
  	  array_walk_recursive($result,
		function (&$result) { $result = htmlentities($result); }
		);
	  // and dump the array to the screen
	  echo "<h1>Gutenprinter reads:</h1><pre>";
	  var_dump($result);
	  echo "</pre>";
	} else {
	  echo "Not able to load Gutenberg parser, are you sure you have Gutenberg installed?";
	}
  	// remove filter to avoid double output
  	remove_filter('the_content','gutenprint');
  	// and return the HTML
	return $html;
}

I’m not going to use it for WP YouTube Lyte as I consider the overhead not worth it (for now), but who know it could be useful for others?

Of bugs, inconsistencies and tag soup in (future) core

In general i rarely bother looking into WordPress core code or what’s on the horizon. The last month or so however I came across 3 problems that were due to core.
1. Shortly after pushing Autoptimize 2.3.x out, a subset of users started complaining about a flood of “cachebuster”-requests bringing their site to a crawl. It turned out all of them were using Redis or Memcached and that due to a longstanding bug in WordPress core Autoptimize did not get the correct version-string from the database, triggering the update-procedure over and over, purging and then preloading the cache. A workaround -involving a transient featuring my wife and daughter- was introduced to prevent this, but “oh my gawd” what an ugly old WordPress core bug that is! Can someone please get this fixed?
2. A couple of users of WP YouTube Lyte noticed their browsers complaining about unbalanced tags in the Lyte HTML output (which is part of the_content). It took me a lot of time to come to the conclusion that WordPress core’s wpautop was messing things up severely due to the noscript and meta-tags in Lyte’s output. As wpautop has no filters or actions to alter the way it works, I ended up disabling wpautop when lyte’s were found in the_content.
3. My last encounter was with the ghost of WordPress Yet-to-come; Gutenberg … To allow WP YouTube Lyte to turn Gutenberg embedded YouTube’s into Lyte’s, it turned out I had to dive into the tag soup that Gutenberg adds as HTML-comments to the_content. I have yet to find documented functions to extract the information the smart way, so regexes to the rescue. But any plugin that hooks into the_content better be aware that Gutenberg (as part of WordPress 5.0) will potentially mess things up severely.
Although I cursed and sighed and I am now complaining, I felt great relief when having fixed/ worked around these issues. But working in the context of a large and successful open source software project and depending on it’s quality can sometimes almost be a pain as much as it is a joy. Almost … 😉