November 2019 Compatibility Updates

A number of updates were released this month that need testing. We're going to docu-blog this process for quality control and review. The first step is going to be working on the Foodie Pro theme because it's the most used, and hopefully the other themes will be easy going once we've worked through it.

The updates we're concerned about are:

• Genesis 3.2.0 (+ Genesis 3.2.1)
  • check edit-post-info feature, and compatibility with the Feast Plugin
  • possibly: check Genesis implementation for lazyloading images - though we still recommend the battle-tested WP Rocket at this time
• WordPress 5.3
  • styling overrides/changes
  • large-image rewriting feature that's been auto-enabled
• Block editor (Gutenberg) 7.0

Per the demo site update, we're going to be testing this directly on the new FoodieProClassic.com demo site that only uses the theme without the Feast Plugin, then re-do the process on the theme + plugin demo site.

Remember: we always advise performing updates on a staging site, in case (or more accurately, when) things go wrong.

Updating to Genesis 3.2.1

Let's start by updating to Genesis 3.2.1 in the dashboard:

Checking out the changelog: https://studiopress.github.io/genesis/changelog/

We can see that the only potentially breaking change is the Entry Meta (above content) (we traditionally called this post-info) and Entry Meta (below content) editor introduced into the customizer screen. It looks like the posts have remained unchanged:

Let's head over to Customizer > Theme Settings > Singular Content

So far so good - editing the Entry Meta above/below changes the appropriate sections on the page.

The child theme never modified these areas so no need to change the child theme files. But two things immediately jump out at me:

Do you see it?

1. the link to the author archives (this was always in place, but we recommended changing it months ago in the Feast Plugin's Edit Post Info)
2. the entry-meta font size is 11px on mobile - too small for mobile devices

We're going to resolve #1 by adding instructions to the tutorials to update your author bio to point to an actual page about the author. Here it is: update your author bio.

#2 is going to get resolved by updating the theme's CSS so that font-size setting to a CSS media query for desktop only, and letting the entry-meta display at the theme default (font-size: 100% = 16px) on mobile, so that it doesn't trigger a font-size too small warning in Google Search Console.

User experience, yay!

Generally, the category and tags links at the bottom of the post Entry Meta (below content) isn't very useful to readers, so we're going to recommend removing those. This is low value to readers and 99% of bloggers don't use categories and tags effectively. See this tutorial on removing the Genesis Entry Meta (below content).

Genesis Chrome Lazyloading

Support for Chrome's native lazyloading is neat and worth checking out later, but thankfully requires opt-in, so isn't urgent.

We recommend WP Rocket rather than this, because it works across all browsers and some initial reports we've seen indicate that it's faster than Chrome's current implementation. Implementing support for Chrome lazyloading at this point would be a regression to our current recommendations.

Whenever a new feature is released, we always recommend waiting a few months before jumping on the bandwagon. These things always change and improve over time, so let other people be the guinea pigs and struggle with the initial bugs and glitches. You don't get paid to do this. Your job is to write recipes, not play with technical settings. Waiting for features to reach a stable point is critical.

We consider WP Rocket a bare essential plugin and recommend using it over Chrome lazyloading at this time.

WordPress 5.3 Update

The WordPress 5.3 update contains at least one poorly thought out, forcefully implemented feature without adequate documentation. These kinds of things should always be opt in.

If you don't feel like reading this whole post, just install the Disable Big Image Threshold plugin. Yeah - you have to install another plugin to disable an unwanted WordPress feature.

While this theoretically only applies to new uploads that are over 2560px, the potential impact of automatically renaming images has huge implications for SEO as well as potentially disk space.

This is one of the reasons why we recommend high quality hosts like BigScoots who hold off immediately updating your site for you.

They're able to delay the immediate update so that they can catch if anything breaks, and gives the WordPress developers time to patch things, before releasing it to Bigscoots hosted customers.

Worth every penny.

After updating, nothing crashed. No layout issues to report on. Just a slightly jarring UI update in the block editor, reportedly an accessibility update (improved contrast).

Let's dive into the image uploading. First, a new upload of a 3000x3000 image. We'll go grab a photo from unsplash from our favorite photog Brooke Lark.

It gets uploaded and inserted fine, with the "large" image size of 1024x1024 selected by default. Fair enough. The theme content width is actually 720px, and 80% of pageviews are mobile which will display at 360px, so there's some potential room for improvement. That's if we assume people won't be using the full-content width layout, which we generally don't recommend.

note: if we simply say that only the content + layout should be used/supported, this eliminates the need for a 1024x1024 thumbnail, which reduces the amount of disk space required, as well as reduces the server load when uploading/regenerating thumbnails.

However, selecting the "Full Size" image width now uses the 2560x2560 image the WordPress automatically generates, instead of the image we actually uploaded, and appends with "-scaled".

Having "-scaled" appended to new uploads probably won't hurt anything, but isn't optimal. Google's SEO guide for image optimization says:

So - not great. But probably not the end of the world.

note: you can still insert the full size image by going to "edit as HTML" on the image, and removing the word "-scaled". But this seems to override something and stops outputting the srcset on the image. This is very, very bad for pagespeed.

The next step would have been to test how old images, that are over 2560x2560, are handled - whether they're automatically scaled, or left alone, but we don't have any images that large.

We've historically err'd on the side of recommending images too small - 680px width in the case of Foodie Pro - which has led to images being undersized in versions later than 4.0.0 where we changed the content width to 720px.

It's long been a best practice on the web to not upload images that are oversized, but people have done this anyway. And so far, WordPress + Genesis + our themes have handled this well.

So the next question is...

Does this affect previously uploaded images?

We'll head over to BrunchProClassic.com and upload the same 3000x3000 test image, update to 5.3, and see if the pre-existing image is automatically resized in the post.

And after the update, same file! It looks like updating to 5.3 does not automatically resize your previously oversized images.

What about saving the post - does WordPress check for oversized images and automatically resize them? Turns out, no! WordPress 5.3 does not automatically resize existing images in your posts.

There is what can only be described as a bug however - with the block editor (Gutenberg) in WordPress 5.3, all images without a corresponding thumbnail size show that the image is a "thumbnail" despite the dimensions not being a thumbnail:

Selecting a different value for "Image Size" then re-selecting "Thumbnail" actually sets the image as a 150x150 thumbnail - not what you want. A more accurate term for non-matching dimensions would be "Custom".

This is a bug in the block editor (Gutenberg) and something we'll have to live with for now. It's a shining example of why we don't say it's ready for public use, and don't offer support for it.

Okay, but what about inserting an oversized previously uploaded image and inserting it into the post? It turns out that previously uploaded images are not resized when inserted into the post.

Through the testing above, it seems like we can confirm that only new uploads over 2560px are affected by this new auto-enabled setting.

There's no harm to previous posts or images when updating to WordPress 5.3.

Again - as a best practice, properly re-size and optimize your images before uploading. This will save disk space on your host, and help avoid server slow-downs when generating thumbnails and having an image optimization plugin like Shortpixel optimize those thumbnails.

We recommend uploading post images at 1200px or 1440px width. Height doesn't matter for in-content post images.

Building theme compatibility with automatic oversized-image resizing

WordPress has built in the ability to disable this automatic resizing, as well as modify it to better suit our needs.

My first thought is that this should be disabled. It should be an opt-in feature, not forcefully implemented and randomly changed without any notice to the users.

If we were building a theme from scratch however, and making it as easy to use as possible, this could be a useful tool. Moving forward, we're likely to recommend only ever displaying images at content-width desktop content, which is 720px. In theory, we could set the large size to 720px and remove a number of oversized thumbnails from being generated.

However, we know that Google wants 1200px width images and we'll be recommend featured images be 1200x1200 px, so 1200px would be a more reasonable setting.

Ultimately, people use our themes in a number of ways and being restrictive is going to impact some percentage of people, however small. We have seen people displaying full-width images in the "Homepage: Above Content" section on Cook'd, which is 1560px wide, and is supposed to have 3 images. And isn't a mobile-first design.

Because of this, I don't think it makes sense to add modify or add support for the new large-image automatic resizing into the themes, which the vast majority of people simply don't update. And when they do, it's a pain.

This kind of functionality belongs in a plugin. Thankfully, we have one.

Feast Plugin

One idea we've been toying with is using the plugin to disable the theme thumbnails and replacing them with thumbnails registered in the plugin. This gives us some leniency with updating the thumbnail sizes in the future, without requiring people to re-install the theme, which everyone struggles with.

Currently, the 3 thumbnail sizes that matter the most are:

• 720px (full-width images in post content on desktop)
• 360px (full-width images in post content on mobile, plus half-width thumbnails on the homepage and category pages on desktop)
• 180px (half-width images in post content on mobile, plus quarter-width/4-wide thumbnail display on the homepage and category pages on desktop)

If for some reason the theme width changes in the future, we can simply re-set the size to 1200 and have everyone run the regenerate thumbnails plugin. The 1200px width image will still be appended "-scaled".

Actually, we need 1200x1200 as well for Google's updated requirements for featured images. So that makes 4 important sizes.

This isn't something that can be decided lightly though, because there's a metric ton of knock-on effects.

For example, the server will be overloaded while thumbnails are rebuilt, potentially slowing pagespeed. And if a different image optimization plugin was previously run (eg. Smush) vs. current recommendations (Shortpixel), are the previous copies automatically deleted? Are the previous sizes deleted? Did people insert those previous sizes into the post, and now the filename referenced no longer exists?

Hint: the answer is yes. I experienced this when myculturedpalate.com was updated from an old Foodie Pro (680px) to the modern one (720px) and the images were inserted at the 680px sizes instead of full. (this was resolved by installing the "Better Search Replace" plugin and replacing all occurrences of "-680x790", which just left the name of the file that was originally uploaded).

Why would this happen? Who knows. The future is impossible to predict. Everybody could be walking around with an oculus rift on their face and the default width should suddenly be 1633px.

But wait, there's more!

Each thumbnail you (re)generated has to be run through an image optimization plugin like Shortpixel, all over again. Shortpixel has recently started charging per image generated (unclear as to why: is this being done on my server, or on Shortpixel's server?).

500 posts x 5 images per post x 10 thumbnails = 25,000 images that need to be re-optimized. At current pricing, 30,000 optimized images costs $19.99.