EditorsKit Adds Nofollow Options for Links, Fixes Bug with Gutenberg Metaboxes Overlapping in Chrome

EditorsKit Adds Nofollow Options for Links, Fixes Bug with Gutenberg Metaboxes Overlapping in Chrome

EditorsKit is becoming somewhat of a “hotfix” plugin for Gutenberg, especially with the additions to the 1.14 release this week. Developer Jeffrey Carandang added new link formats for nofollow rel attribute options, along with a fix for an annoying bug in Chrome that causes Gutenberg metaboxes to overlap. He has been closely monitoring feedback on both Gutenberg and EditorsKit, introducing features for which users have an immediate need.

Google recently announced new ways to identify nofollow links with two additional rel attribute options for specifying links as sponsored and/or user-generated content. The Gutenberg core team has expressed hesitation on a PR that would add nofollow link options, invoking WordPress’ 80/20 rule.

Since the related PR doesn’t seem to be a priority, with no movement for two weeks, Carandang decided to add the nofollow and sponsored rel attribute options to EditorsKit, so users can start following Google’s recommendations without having to switch to HTML mode. He also managed to make it work with the version of Gutenberg included in core.

Nofollow link options

Chrome users may have noticed that the block editor has a nasty bug with metaboxes overlapping, obscuring the main content area. This problem was introduced in the recent Chrome 77 update and is present on WordPress 5.2.3 and older versions.

Chrome developers are aware of the issue and a fix will be in the next release. Version 78 is expected October 22. Since it is a bug with Chrome, the Gutenberg team has opted not to release a fix/workaround for this problem. In the meantime, they recommend updating to WordPress 5.3 if it is released before the Chrome bug is fixed. This isn’t likely, as 5.3 is scheduled for mid-November.

The Gutenberg team also recommend using a different browser or installing the Gutenberg plugin to fix the issue. Andrea Fercia noted on the ticket that the plugin is still listed among WordPress’ beta plugins and may not be advisable to use in production on some sites. Users with a technical background can implement one of several CSS solutions in the ticket, but this is a frustrating bug for users who don’t know how to apply code fixes.

Carandang added a fix for this bug to the most recent version of EditorsKit. So far his strategy of being responsive to users’ requests seems to have been successful, as his Gutenberg utility plugin now has more than 1,000 active installs. He said he is happy to add hot fixes for EditorsKit users and will remove them once the fixes have been added to Chrome and/or the block editor.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let’s discuss your ideas.
Chrome 76 Adds Native Lazy-Loading, WordPress Contributors Continue Discussion Regarding Core Support

Chrome 76 Adds Native Lazy-Loading, WordPress Contributors Continue Discussion Regarding Core Support

lazy cat – photo credit: Kate Stone Matheson

The latest version of Chrome (76) shipped with a new “loading” attribute that allows developers to specify resources, such as images and iframes, to defer loading until the user scrolls nearer to them. In the past, developers have used third-party libraries to achieve lazy loading but soon this will no longer be necessary, as more browsers adopt the loading attribute. Chrome developers published a compelling, in-depth explanation of how browser-level native lazy-loading can improve performance.

Given Chrome’s seemingly unshakeable, staggering market dominance, it will not be long before the loading attribute is supported for the vast majority of the web’s users. Firefox has an open ticket for implementing lazy loading using this syntax and the feature is also supported in Chromium 76-based browsers. It even works when the user has disabled JavaScript. In the meantime, Chrome recommends developers continue to use a third-party library along with loading=”lazy” is to provide a polyfill for browsers that do not yet support the attribute.

Morten Rand-Hendriksen filed a trac ticket 14 months ago, recommending WordPress introduce a lazy-loading API for media and other elements. Millions of WordPress users already have have some form of lazy loading on their sites using popular plugins like Jetpack, Autoptimize, Smush, WP-Optimize, and others.

Rand-Hendriksen contends that lazy-loading should be added to core because it is a performance best practice that WordPress should not require site owners to implement on their own. Without a core standard for lazy-loading, themes and plugins are all taking different approaches to solve this problem, which can cause conflicts and unexpected behavior. Contributors working on the ticket are still discussing the specifics of how WordPress core can best support lazy loading.

Meanwhile, WordPress developers who are excited about taking advantage of native lazy-loading are sharing their their own functions and custom plugins on GitHub, WordPress.org, and in the Advanced WordPress Facebook group.

Peter Shaw created a plugin called LH Native Lazy Loading that adds the “loading” attribute to IMG and IFRAME tags detected when filtering the_content(), post thumbnails, and oembed. It does not add any extra CSS or JavaScript and is compatible with JavaScript-based image lazy loaders, in case you want to use one as a fallback for browsers that don’t support the attribute.

Chris Franchetti shared a gist for a function that adds lazy loading to it to anything with a src. Chris Zähller published a set of functions on GitHub called WP Lazy that work in a different way. It adds the loading=“lazy” attribute when inserting new media or displaying a gallery via the WordPress gallery shortcode.

If there is a long delay on the core trac ticket, there will inevitably be a proliferation of native lazy-loading solutions that allow WordPress users to implement what several major browsers are already supporting. Existing lazy load plugins may also change to add support for the “loading” attribute, with their previous solutions as a backup for browsers that don’t yet support it.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let’s discuss your ideas.