Improve the process for adding / updating block plugins

[bobbingwide]

Issue #1 makes it easier to get a new run time version of a component in a Git repo which just contains the released versions. This is needed for re-parsing the PHP, using the oik-shortcodes batch routine.

For components which deliver WordPress blocks ( primarily plugins ) we also want to be able to automate, as far as is possible, the process of registering the plugin and identifying and then registering the blocks delivered by the plugin.

We want a process similar to oik-update.php which will bring together the manual steps required. The process should take into consideration whether or not the plugin has an existing Git repository. Ideally the routine would be run as a batch routine. For the time being we’ll call it oik-blocker.php

Syntax:

cd wp-content/plugins/oik-update
oikwp oik-blocker.php plugin version etc etc

Where Plugin is the name of the plugin to download Version is the version number to download - latest will do Etc are other parameters we might need to pass manually

The manual process will need to evolve to cater for my development and run-time environments.

[bobbingwide]

In the first stage of this development we'll copy the functions from the OIK_component_update class into a parent class OIK_wp_a2z which the OIK_blocker class will extend.

We'll implement the logic to:

• download assets
• download the latest ZIP file
• install the selected version

[bobbingwide]

Note: Some plugins aren't versioned in wordpress.org. These need to be downloaded with a blank version parameter. e.g.

oikwp oik-blocker.php block-gallery "" url=blocks.wp.a2z 
oikwp oik-blocker.php coblocks "" url=blocks.wp.a2z

[bobbingwide]

In the next stage we'll attach the banner image to the oik_plugin post. We may need to create an attachment A new banner file will replace the existing file.

[bobbingwide]

Then we'll add logic to update the post content to match the desired structure, if the content doesn't already contain a bw_plug shortcode. And logic to create the oik-plugins post if it doesn't already exist.

[bobbingwide]

Now we need to improve the creation of the block list block. Adding the ‘component’ is easy. Getting the prefix is harder. the prefix can be found using v1.2 of the WordPress plugins api. I’ve added some logic to the downloads routine in wp-top12 that gets the list of blocks known to wordpress.org.

Seems to work.

[bobbingwide]

This routine’s been working reasonably well but needs a couple of tweaks.

1. When it can’t find a banner to upload it shouldn’t upload an empty file
2. I need to make sure it’s safe to use when I want to catalogue my own single block plugins.

[bobbingwide]

15 months later... I've been going through the rather laborious process of updating the blocks for the plugins already catalogued. On the live site:

• 113 plugins
• 691 blocks
• 1443 - total delivered

So less than half way.

Requirements

There are some plugins with many blocks and variations that I haven't catalogued and I need a faster mechanism for creating the missing blocks.

Example plugins:

Plugin	slug	# blocks	catalogued	# block.json
WooCommerce Blocks	woo-gutenberg-products-block	51	28	21
Cosmic Blocks	cosmic-blocks	50	0	0
Stackable	stackable-ultimate-gutenberg-blocks	125	0	63
Ultimate Addons for Gutenberg	ultimate-addons-for-gutenberg	66	33	0

For the complete list of numbers of blocks to be catalogued see https://blocks.wp-a2z.org/about/block-plugin-summary/ WooCommerce blocks are also created in woocommerce.wp-a2z.org

Proposed solution

• [x] Update the blocks routine to automatically detect blocks that are registered from block.json files
• [x] For each block invoke the equivalent of the AJAX call to create / update
• [x] Change the content for a block so that the screenshot can be pasted in from the editor, replacing the oik-fields block

WIBNI's...

• [x] Automatically set the featured image from the attached image
• [ ] Rename the uploaded image to the same as the block
• [ ] Automatically edit the page to get the block info block to correct itself
• [ ] Run oik-loader update to refresh the list.

[bobbingwide]

Using the blocks social-share-buttons-lite routine to register the Algori Social Share Buttons Lite plugin the post_name for the generated block didn't match the name generated by the oik-block/blocklist block.

The Block title is Social Share Buttons but the generated block has a post title prefixed with Algori

Workaround is to remove the Algori prefix from the generated block's post title and update the permalink.

[bobbingwide]

This routine’s been working reasonably well but needs a couple of tweaks.

1. When it can’t find a banner to upload it shouldn’t upload an empty file
2. I need to make sure it’s safe to use when I want to catalogue my own single block plugins.

1. Ditto for when the plugin name was incorrect in the first place. Don't create the plugin at all.

2. I definitely want to do this.

[bobbingwide]

The blocks.bat file, which runs oik-blocker.php, extract below is OK for creating blocks for a new block plugin.

cd c:\apache\htdocs\wp-a2z\wp-content\plugins\oik-update
php c:\apache\htdocs\wp-a2z\wp-content\plugins\oik-batch\oik-wp.php oik-blocker.php %* url=blocks.wp.a2z

But it's no good for existing plugins that needs updating.

Requirement

Improve the process such that if no parameters to oik-blocker.php are specified it finds the list of plugins that need updating and applies the updates, running $oik_blocker's methods as appropriate.

The logic that detects if the plugin is a Git repo should not apply updates to plugins in the WP-a2z organization. These would still need to be processed by the update.bat file.

Proposed solution

Obtain the list of plugins to be updated from the wp_sitemeta table _site_transient_update_plugins. The API to access this information $option = get_site_option( "_site_transient_update_plugins" );

For each plugin in the list apply the updates to the plugin and any blocks listed in block.json files.

Note: Similar logic can be applied for themes.

[bobbingwide]

For each plugin in the list apply the updates to the plugin and any blocks listed in block.json files.

I changed the logic to get a list of plugins to be updated. There are a couple of problems.

1. Sometimes the list appears empty. I believe this is when the transient has timed out. So how do we re-build it?
2. The list of plugins to update includes those which are not block plugins. These plugins do not need to be added.
3. One of those plugins was media-file-renamer. I got a Fatal with this.

   Fatal error: Cannot redeclare media_upload_tabs() 
   (previously declared in C:\apache\htdocs\wp-a2z\wp-admin\includes\media.php:18) 

[bobbingwide]

I also got the same Fatal attempting to upload the todo-list-block banner. Looks like I've got to change some more include commands to include_once or require_once, as I had to do in update_installed_plugin() when first enabling the loop.

[bobbingwide]

Having implemented the changes to oik-blocker.php I ran it against blocks.wp.a2z and blocks.wp-a2z.org There were a couple of problems.

1. Blocks created for wptravel and other plugins don't have a title
2. Blocks were created for WooCommerce Blocks, but don't work properly unless WooCommerce is activated on the main site. See also https://github.com/bobbingwide/oik-loader/issues/18
3. Some plugins didn't get updated since they can't be downloaded using the version number.

• Envira Gallery Lite
• GT3 Photo & Video Gallery - Lite
• WPDM - Gutenberg Blocks

[bobbingwide]

1. Blocks created for wptravel and other plugins don't have a title

Block	Explanation
a8c/post-lists	Incomplete block.json found in full-site-editing\posts-list-block\blocks\posts-list
homepage-articles	Incomplete block.json in full-site-editing\newspack-blocks\synced-newspack-blocks\blocks\homepage-articles
core/widget-group	Incomplete block.json in gutenberg\build\widgets\blocks\widget-group
shareablock	Incomplete block.json in block-options\src\blocks\shareablock
wp-travel x n	Incomplete blocks.json in wp-travel-blocks\src\blocks subdirectories

[bobbingwide]

Several blocks with theme-isle prefix were created for the otter-blocks plugin, which is registered as Gutenberg Blocks and Template library.

• This oik-plugin post has the wrong value for the plugin slug: facebook-for-woocommerce.
• Several other oik-plugins have this value for the plugin slug.
• These need correcting.
• Along with a number of other plugins which have the wrong information in the post meta data.

Correcting the problem involved matching the oik-plugins entry with an existing plugin.

• There were some plugins where the plugin name has been changed.
• These needed to be updated manually.
• The update logic, which was introduced to set the post modified date, needs to ensure the post meta data is also updated.

[bobbingwide]

3. Some plugins didn't get updated since they can't be downloaded using the version number.

When applying automatic updates we can save a bit of processing by using information from the plugin_info structure. eg. For the Download Manager plugin, which doesn't have any blocks, but is a dependency for WPDM - Gutenberg Blocks the plugin_info structure is:

stdClass Object
(
    [id] => w.org/plugins/download-manager
    [slug] => download-manager
    [plugin] => download-manager/download-manager.php
    [new_version] => 3.2.40
    [url] => https://wordpress.org/plugins/download-manager/
    [package] => https://downloads.wordpress.org/plugin/download-manager.zip
    [icons] => Array
        (
            [2x] => https://ps.w.org/download-manager/assets/icon-256x256.png?rev=1561688
            [1x] => https://ps.w.org/download-manager/assets/icon-128x128.png?rev=1561688
        )

    [banners] => Array
        (
            [1x] => https://ps.w.org/download-manager/assets/banner-772x250.png?rev=1722853
        )

    [banners_rtl] => Array
        (
        )

    [requires] => 5.3
    [tested] => 5.9.3
    [requires_php] =>
)

Here we can see:

• the package doesn't include the version number: https://downloads.wordpress.org/plugin/download-manager.zip
• Also, that the banner is a .png file.

[bobbingwide]

Run oik-loader update to refresh the list.

After updating plugins and blocks, oik-loader's Rebuild index logic shoud be run automatically.

Implementation

This is not the same as visiting https://blocks.wp.a2z/wp-admin/admin.php?page=oik_loader&mu=rebuild since this requires the user to be logged in. Just implement the underlying functionality.

[bobbingwide]

In wp.a2z I have multiple versions of Gutenberg installed. A couple of the versions are back level, they always appear to need updating. oik-blocker runs this when it's unnecessary. Perhaps it should ignore any plugin that starts Gutenberg

[bobbingwide]

To cater for plugins which don’t use block.json files, it might make sense to invoke a server function that will determine the blocks that are registered in the server and create/update the block post from this list.

The process will involve

1. Activating the plugin
2. Getting a list of registered blocks
3. For each registered block:
   • • check versus the DB
   • • add each one that’s not known if it’s for a known component ( plugin )
4. Updating the oik-loader list.
5. Deactivating the plugin afterwards

The first thing to write here are steps 2 and 3.

[bobbingwide]

I started writing some code for step 2 and quickly discovered that this may be a non-starter. The information for the registered blocks may not be as useful in the server; the list of blocks / variations is incomplete or key data may be missing.

Component	# server blocks	# client blocks	Notes on server registered blocks
core	136	193	Doesn't list the variations of core/embed
jetpack	47	50	No titles or descriptions available
coblocks	29	67	No titles or descriptions available
stackable	36	37 + 91	Doesn't list variations

Differences for Jetpack are: server includes: jetpack/donations, jetpack/simple-payments, jetpack/social-previews, jetpack/videopress-block client includes: jetpack/related-posts and the 7 variations.

I didn't look at the differences for CoBlocks or Stackable

[bobbingwide]

For plugin version updates I'm now considering another client-server solution that will perform a reconciliation of the blocks listed in the front end with those registered in the server for the selected component.

• This change will involve the oik/blocklist block, from the oik-blocks plugin.
• There will be another toggle labeled Determine updates to apply
• When selected the block will be dynamically rendered indicating which of the blocks are new, updated or deleted.
• I need to check what information I can determine from the static HTML generated in the block editor.

[bobbingwide]

Regarding Stackable ( stackable-ultimate-gutenberg-blocks ). In blocks.wp.a2z I'd already documented blocks prefixed with ugb. eg ugb/accordion.

• These blocks have a category of stackable-v2.
• Most of these were generated using the batch technique on 10th April.
• These block's titles now include a suffix of (v2).

Since v3 Stackable's blocks

• have been prefixed stackable and have a category of stackable.
• If you install Stackable on a new site then the deprecated blocks are no longer registered
• unless you tick a check box in the Migration Settings. See https://docs.wpstackable.com/article/462-migrating-from-version-2-to-version-3

Other than changing the title, I reckon I'll leave the documentation for the v2 blocks as they are.