Skip to main content
wordpress supportwordpress support services

Displaying Post Modified and Reading Times via WordPress Blocks

A couple of weeks ago, Rich Tabor announced a GitHub repository that listed all of his block plugins. These were already publicly available. However, some had yet to land in the WordPress plugin directory. As a fan of his simple approach to block design, I was quick to start tinkering with them.

One of those projects, Post Modified Time Block, landed on yesterday. Along with the yet-released Post Reading Time Block (available on GitHub), the two make a pair of post-meta extensions that should come in handy for many users.

Both blocks are meant to be used in conjunction with a post rather than dropped haphazardly around the site. Typically, users would place them in one or more of their templates via the site editor (which requires a block theme). As shown in the following screenshot, I added them to the post header area in Archeo:

WordPress post header that shows a split between the meta and featured image.  On he left, the published date, updated time, and reading time are shown above the title.
Adding post updated and reading times to the post header.

While WordPress has never had a “reading time” template tag, it does have a post-modified time function. However, there is no equivalent block. There is a recent ticket for selecting between the published or modified date/time via the Post Date block.

Until that lands in WordPress, which will almost assuredly not happen in the current 6.0 release cycle, users can rely on Tabor’s Modified Time block.

Adding it is as straightforward as inserting any other block. I chose to stick it next to the published date in my theme’s “Single” template.

WordPress site editor focused on the post header in the single template.  Highlighted is the Modified Time block.
Inserting the Modified Time block.

The most immediate thing I missed was the new date-formatting options available in the Post Date block in the Gutenberg plugin. With the recent version 12.9 update, users can choose between a locale-aware set of default formats or customize it. The experience is much improved from before, and I hope that Tabor adopts the new component when WordPress 6.0 rolls around.

The Modified Time block will only output anything if the post has been updated and is older than 24 hours. Depending on the site or theme design, conditionally-displayed blocks can be problematic. For example, if placing one in a Row alongside other post-related blocks and separating each with some character, the “separator” sometimes stands alone when the block displays nothing, as shown below:

Published by {author} | Published on {date} | 

This problem was simple to address in classic, PHP-based themes. However, there is no standard for handling it with blocks. It is not an issue specific to Tabor’s plugin but something to be mindful of.

“Reading time” plugins are a dime a dozen. They seem to have existed for as long as I can remember, but most are starting to show their age. They either rely on shortcodes or automatically inject their output onto the page, leaving the user without control. Tabor’s Reading Time block brings the feature to the block editor.

Users will primarily add this to one or more templates via the site editor, as with the first block. I stuck it below the published and modified times for display on single posts:

WordPress site editor focused on the post header in the single template.  Highlighted is the Reading Time block.
Inserting the Reading Time block.

The block worked well. My only complaint is that it has no text-formatting options. By default, it outputs “X min read.” I wanted to display “Estimated reading time: X” instead.

The block does not break times down into hours for long—really long—form works. It would be a welcome addition for the much rarer use case to display those times in an hour + minutes format.

Simple blocks like these may not garner a developer any fame or fortune. They are not the behemoth projects that one can build a business around. However, they are necessary. Our developer community must take the reigns and fill in the gaps that WordPress has yet to cover.

I would like to see more businesses and developers contributing such blocks. It is a way to pay it forward while gaining real-world experience building on top of the block system. And, there are opportunities aplenty. Look around the WordPress source code for functions or template tags with no block equivalent. For example, where is the “List Authors” wrapper for wp_list_authors()? There are also many plugins built on the old shortcode system that need a port.