While testing the new improved patterns display in blocks.wp.a2z I came across a Doing it wrong message.

Notice: Function _register_theme_block_patterns was called incorrectly. Could not register file "C:\apache\htdocs\wp-a2z/wp-content/themes/jace/patterns/register-block-patterns.php" as a block pattern ("Slug" field missing) Please see Debugging in WordPress for more information. (This message was added in version 6.0.0.) in C:\apache\htdocs\wp-a2z\wp-includes\functions.php on line 5831

The code in gutenberg_register_theme_block_patterns() is trying to process the register-block-patterns.php file as a pattern.

The $pattern_data for this file is

C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg\lib\compat\wordpress-6.1\block-patterns.php(72:0) gutenberg_register_theme_block_patterns(37) 105 4 2022-10-08T16:13:56+00:00 1.285582 0.000946 cf=init 8333 12 0 6291456/6291456 512M F=688 pattern data for C:\apache\htdocs\wp-a2z/wp-content/themes/jace/patterns/register-block-patterns.php Array

    [title] => (string) ""
    [slug] => (string) ""
    [description] => (string) ""
    [viewportWidth] => (string) ""
    [categories] => (string) ""
    [keywords] => (string) ""
    [blockTypes] => (string) ""
    [postTypes] => (string) ""
    [inserter] => (string) ""

hence the message I saw.

C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\includes\bwtrace-actions.php(198:2) bw_trace_doing_it_wrong_run(1) 106 5 2022-10-08T16:13:56+00:00 1.286035 0.000453 cf=init,doing_it_wrong_run 8336 12 0 6291456/6291456 512M F=688 3 Array

    [0] => (string) "_register_theme_block_patterns"
    [1] => (string) "Could not register file "C:\apache\htdocs\wp-a2z/wp-content/themes/jace/patterns/register-block-patterns.php" as a block pattern ("Slug" field missing)"
    [2] => (string) "6.0.0"

Update code to run without problems in PHP 8.1 and 8.2

See bobbingwide/bobbingwide#103

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.

Between WordPress 5.6 and WordPress 5.6 the blocks prefixed core-embed were changed to variations of the core/embed block.
The oik-block posts for each of these blocks need to be updated.

Requirement

• a batch process to rename the existing posts
• If specified do all the core-embed blocks
• otherwise do the one specified - defaults to core-embed/amazon-kindle changing to core/embed:amazon-kindle
• variation indicated by the separating colon.

Proposed solution

• develop and run oik-block-rename.php
• apply manual updates to take into account other changes
• clone the posts to core.wp-a2z.org

I need to improve the method whereby updates to plugins and themes can be applied to wp-a2z.org efficiently. A time consuming part of the process has been downloading the latest runtime version of a component, extracting it to the WP-a2z repository, updating the repository and then running the batch process to rebuild the API reference.

This issue is to document the requirements and solution for building the API reference for the existing plugins and themes.

The logic has to cater for exceptions such as:

1. The repository name for WordPress is wp-a2z.
2. wp-a2z has some hand cranked files: README.md and .gitignore
3. The Genesis theme framework is not downloadable from wordpress.org

The Frost theme is dependent upon WordPress 6.2 and won't install on WordPress 6.1.1

oik-themer doesn't detect this and fails with a call to missing function gob() when it can't upload the screenshot for the theme.

Proposed solution

Upgrade to WordPress 6.2.2

When running blocks.bat to update a plugin the logic to download new versions of the assets fails.

Failed to download: premium-blocks-for-gutenberg png
Failed to download: premium-blocks-for-gutenberg jpg

The logic in save_icon() needs to be changed to use the cURL method to download the image.
See https://github.com/bobbingwide/bw/issues/11

When a new release of WordPress is under development which contains a new default bundled theme the theme isn't yet available from wordpress.org/themes but it would be nice to document the new theme.
twentytwentyfour is the new theme to be bundled into WordPress 6.4

Requirement

• Add logic to support documenting of a new WordPress bundled theme prior to its actual appearance in wordpress.org/themes

There are now 31 FSE themes registered in wordpress.org https://wordpress.org/themes/tags/full-site-editing/
I need a quick process that will register the themes in blocks.wp.a2z then clone them to blocks.wp-a2z.org
OR to simply run on the live server.

• oik-blocker is used for updating blocks
• oik-update is used for update the API reference
• oik-themer is needed to define and update themes

Proposed solution

• Download the theme's zip
• Unpack to wp-a2z
• fetch theme info
• create / update theme
• set featured image to screenshot
• find directory for patterns

It may not be necessary to download the theme to the local installation other than to be able to verify that the templates, template parts and patterns are located. Not that there's support for patterns yet.