Enable dynamic display of latest plugins count, total downloads and related charts from post meta data

[bobbingwide]

While migrating from the oobit theme to oobit-2025 I considered some additional enhancements. Since most of the posts displayed on the home page don't have a featured image I wondered if it would be possible to have a featured block such as a particular chart extracted from the post.

Currently posts in the top10 category display a countup block for the Total downloads to date and Plugins, followed by a short list of observations. When you scroll down the page the countup blocks all start counting. This is OK but it would be nice to be able to see this information regardless of the latest post.

Requirements

At the top of the home page display a group that shows

• The latest countups for both Total downloads and Plugins
• Charts showing the changes over the last n months, for both Total downloads and Plugins

Note: There is already a post showing some of this information. But the charts were created manually. https://top-10-wp-plugins.com/2024/02/16/total-downloads-and-plugin-count-history-oct-2019-to-dec-2023/

Proposed solution

• Add two fields to store this information for posts with a category of "top10"
  • _plugins
  • _total_downloads
• Populate these retrospectively from the post archives
• Add a template part to the theme that displays the information required
• Write code to hook into the render_block_data filter in order to replace the relevant attributes with the latest values

[bobbingwide]

When I was developing the code it was created as a group block in part of a post https://s.b/bwcom/top-10-wp-plugins/2024/10/09/wp-top12-issue-27/

I then copied and pasted this group into a template part called dynamic-charts which I embedded into the home page.

Having noticed that I'd copied a debug block, the [bw_fields] shortcode, into the template I edited the template part and noticed that the dashicon block for the admin-plugin dashicon didn't display in the site editor. But it still worked in the front end. This was the first mystery.

Then, after having changed the initial post to a draft, I noticed that the wp-countup-js code was no longer being loaded. I assume this is something to do with the plugin. I have yet to investigate. Meanwhile, I could consider removing the template part and make the original post, from which the template part was created, a sticky post.

[bobbingwide]

Screen capture of the template part in the site editor. Notice that the admin-plugins dashicon is not displayed.

Note: While in the site editor I tried the Play Counter button for the CountUp block. It didn't work. It does work in the block editor.

[bobbingwide]

Workaround

• Mark the post that contained the dynamically adjusted blocks as sticky
• Change the home template to display two query loops
  • • The first only displays the sticky posts
  • • The second doesn't display sticky posts and starts from offset 1.

Note: The sticky post is not displayed on page 2 and above. Does this mean that some posts are omitted?

[bobbingwide]

Does this mean that some posts are omitted?

Yes, The second query block should not include sticky posts and should start from offset 0.

[bobbingwide]

In the wp-countup-js plugin the enqueue_scripts method is called when wp_enqueue_scripts is invoked.

The reason that the countup js logic wasn't enqueued is because the method should_enqueue_assets() returns false if the global $post is not set or the post doesn't contain the roelmagdaleno/wp-countup-js block.

This can occur when the first post to be displayed is not a "Top-10" category post.

Note: The latest version of the wp-count-up plugin is 4.2.4, last tested with WordPress 5.8.2. Is it time to switch to a similar plugin?

[bobbingwide]

This problem is related to https://github.com/bobbingwide/oik-blocks/issues/41 It's similar to Gutenberg issues #44205 and #53528 except that it's not affected by the setting of SCRIPT_DEBUG. Here's the trace output for the enqueue_block_assets hook.

C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\includes\bwtrace-actions.php(582:0) bw_trace_attached_hooks(3) 188 2 2024-10-12T02:41:31+00:00 1.055377 0.000130 cf=enqueue_block_assets 12806 53 0 14680064/14680064 256M F=862 enqueue_block_assets 
: 0   bw_trace_parms;9 bw_trace_attached_hooks;9 bw_trace_backtrace;9
: 10   wp_enqueue_registered_block_scripts_and_styles;1 oik_blocks_frontend_styles;1 Closure;1
: 30   enqueue_block_styles_assets;1
C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\includes\bwtrace-actions.php(666:0) bw_trace_backtrace(1) 189 2 2024-10-12T02:41:31+00:00 1.055491 0.000114 cf=enqueue_block_assets 12806 53 0 14680064/14680064 256M F=862 1 
0. bw_lazy_backtrace C:\apache\htdocs\wordpress\wp-content\plugins\oik-lib\libs\bwtrace.php:108 0
1. bw_backtrace C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\includes\bwtrace-actions.php:667 0
2. bw_trace_backtrace() C:\apache\htdocs\bwcom\wp-includes\class-wp-hook.php:324 1
3. apply_filters(,array) C:\apache\htdocs\bwcom\wp-includes\class-wp-hook.php:348 2
4. do_action(array) C:\apache\htdocs\bwcom\wp-includes\plugin.php:517 1
5. do_action(enqueue_block_assets) C:\apache\htdocs\bwcom\wp-includes\block-editor.php:340 1
6. _wp_get_iframed_editor_assets C:\apache\htdocs\bwcom\wp-includes\block-editor.php:623 0
7. get_block_editor_settings(array,object) C:\apache\htdocs\bwcom\wp-admin\site-editor.php:74 2

oik_blocks_frontend_styles(), in the oik-blocks plugin, used to call

 wp_enqueue_style( 'dashicons');

But I removed the logic thinking it was no longer necessary.

enqueue_block_styles_assets(), part of WordPress core, could possibly perform the enqueuing if the dashicon block's styles were dependent upon dashicons. I haven't checked this yet.

wp_enqueue_registered_block_scripts_and_styles() does something similar. It also makes use of wp_should_load_separate_core_block_assets().

The functions attached to the hooks are the same when Gutenberg is activated. This suggests that there's a block in Gutenberg which needs dashicons but not in core!

[bobbingwide]

When Gutenberg is activated the second time that enqueue_block_styles_assets is invoked the queue of styles to be registered already includes dashicons.

This is due to the fact that Gutenberg has used a function called gutenberg_override_style() to add dashicons as a dependency on wp-components.

This isn't done in WordPress core.

See https://github.com/WordPress/gutenberg/pull/20003 for the pull request that added the dependency that's not in core.

[bobbingwide]

It's similar to Gutenberg issues #44205 and #50897, except that it's not affected by the setting of SCRIPT_DEBUG.

Regarding #44205 it would appear that the fix to Gutenberg wasn't released to WordPress core. The wp-components package style is registered in wp-includes/script-loader.php Line 1713 is the where the $package is named components. The $handle becomes wp-. $package in the style adding loop. This line of code hasn't changed since TRAC #45065

    'components'           => array(),

Re #53528

I concur with the investigation documented in https://github.com/WordPress/gutenberg/issues/53528#issuecomment-1674376362.

I also agree that the workaround, if not using Gutenberg, is to ensure dashicons is enqueued in response to enqueue_block_assets.

But I'm just wondering if script-loader should have been changed

  'components' => array( 'dashicons' ),

[bobbingwide]

Here's a screen capture showing the dashicons block working with the above change to script-loader.php.

Note that until the change is made to WordPress core I'll still need to use the workaround. This can be implemented in wp-top12, oik-bob-bing-wide and/or re-implemented in oik-blocks.

[bobbingwide]

This can be implemented in wp-top12, oik-bob-bing-wide and/or re-implemented in oik-blocks.

oik-bob-bing-wide is the most sensible place. This is the plugin that implements the oik-bbw/dashicon block. See https://github.com/bobbingwide/oik-bob-bing-wide/issues/68