Requirements

• Display UK tides information in a block
• Implement a block for the [bw_tides] shortcode
• Attempt to short circuit the need for the oik base plugin

Proposed solution

• New block oik-block/uk-tides - UK tide times and heights
• Depends on uk-tides for the server logic
• Implemented as a dynamic block for server side rendering
• Support easier to use parameter for source of tidal information
• Support easier to use parameter for specifiying the location
• Server side rendering to be performed when the block is not selected.

The block to be added to the list of experimental blocks in #16.

To help with future development of blocks, it would be nice to accumulate some of the console messages that are seen when developing blocks and the problem resolution.
e.g.

BlockiconsSelect(...): Nothing was returned from render. This usually means a return statement is missing. Or, to render nothing, return null.

In a class that extends component, the render() method should return something.
wrong code

render() {
        <ul>
            <li>oik-csv icon?</li>
        </ul>
    }

corrected code

render() {
        return(
            <ul>
                <li>oik-csv icon?</li>
            </ul>
        )
    }

The [bw_contact_form] shortcode displays a simple HTML form.
We would like to be able to use the existing logic in a dynamic block.

Requirement

• Develop a new block called Contact form
• Support the attributes that may be passed to the existing [bw_contact_form] shortcode

Proposed solution

• Implement as a Dynamic block.

Messages I've seen are:

wp.editor.InspectorControls is deprecated. 
Please use wp.blockEditor.InspectorControls instead.

Also the CSS class names of blocks are now prefixed block-editor-; was editor-.
Some of the .scss files will need updating to ensure the blocks are correctly styled. e.g blockicon/style.css

Implement a countdown timer block for the [bw_countdown] shortcode.

Requirement

Implement a Countdown block that will demonstrate...

1. Using different control types for different parameters
2. A block with JavaScript, albeit still being supported as a shortcode.

Proposed solution

Minimum logic for the first version.

• Get it to work with text fields.
• Create examples for:
• until - WordPress’s next anniversary
• since Gutenberg first appeared on wordpress.org

For the next level of capability I want to be able to create a block which is flexible enough to support an array of attributes.
Many of my shortcodes accept a huge number of parameters.
I don't want to have to hardcode the logic for each of the different parameters.
I need to discover how to use arrays to dynamically set the values for the block attributes which in turn become the shortcode parameters.
This solution should hold me in good stead until such a time comes that the shortcode becomes unnecessary and the solution can be implemented natively using blocks.
At which time we'll find a way to add logic to convert the shortcodes to blocks.
That'll be fine for "blocky" shortcodes but pretty useless for inline shortcodes.

So, since it appears fairly simple, let's try creating a block that will expose the parameters to the bw_follow_me suite of shortcodes, passing the attribute names in a variable array / object and dynamically creating the Additional settings fields.

WordPress / Gutenberg delivers many icons which are used to help selection of the blocks in your content. The SVG for these icons is often hand crafted. Sometimes it's a dash icon, but not often.
In the block documentation in WP-a2z we need to display the actual BlockIcon for the selected block.
For most blocks we can find this using the block name. e.g. core/audio.

Initially this block will be delivered as a static block.

Many of the shortcodes for which I'm creating block editor front ends have attributes which can either be chosen from a pre-defined list or can have custom values.
e.g.

Requirements

• A control that can display the standard options but also allows the custom value to be entered.
• When the field contains the Custom value the select list should indicate this somehow
• Preferably use existing Gutenberg code.

Advanced requirements

• Multiple selection of predefined options with a user defined order
• Ability to display icons and other non-text data in the "selection" part of the list

Proposals seen elsewhere

Blocks

Nivo - I prototyped this with the theme field being a text input that was shared with a select list called t2. See #10 ?
Shortcode block - With the shortcode text field and drop down list

Meetup Cheltenham

This subject was very recently discussed in #meetup-cheltenham UK WordPress Slack. A suggestion was

• to fake it with a faux dropdown and a normal text input
• Use JS in some way to populate the text input with whatever you select from the faux input,
• but also have it manually editable
• Dave Beesley created a CodePen https://codepen.io/davebeesley/pen/NWxvqpg
• hide the select unless the input is focused, then only let the user select from the dropdown

Windows print - Pages field

In Windows, when printing, the Pages field allows customised values.

Requirements

• Ability to document code styled using GeSHi
• Implement a block for the [bw_geshi] shortcode
• Primary purpose is to avoid problems with unwanted p and br tags created by Gutenberg when attempting to write a post using the Block editor which contains the [bw_geshi] shortcode.

Proposed solution

• New block oik-block/geshi - GeSHi - Generic Syntax Highlighting
• Depends on oik-css plugin for the server logic
• Implemented as a dynamic block with server side rendering
• Supports the language selection parameter, defaulting to "none".

This block to be added to the list of experimental blocks in #16

Each block that we create should be documented with a README file

Requirements

To consist of some or all of the following sections

• Overview
• Browser view
• Editor view
• Additional settings view
• Requirements
• Future requirements
• Scope and exclusions
• Issue summary
• links for further information

Proposed solution

• The built version of the plugin does not need to contain this information

With Gutenberg 11.9.0 the block list block displays icons in the editor but they're missing in the front end.
They look OK in the Visual editor.
If you switch to the Code editor the SVGs are gone.

Note: Some icons don't even appear in the block list in the editor. eg. Comment Author Name
This could be a separate issue.
The blockinfo block doesnt display the icon but the blockicon block does.
However the SVG's missing when you switch to the Code editor.
And it's not saved in the post.

I typed a non-numeric value for the bwscid1 parameter, which is used by oik-navi, and got

Warning: A non-numeric value encountered in /home/bworguk/public_html/wp-content/plugins/oik/shortcodes/oik-navi.php on line 243

https://blocks.wp-a2z.org/oik-plugins/gutenberg/?oik-tab=blocks&bwscid1=`0

Pagination was for -9 to 0 of 113.

Workaround

type 10 rather than `0

The output for the block list block ( oik-block/blocklist ) assumes that the dashicons CSS is enqueued.
It appears that this is no longer the case with Gutenberg 9.1.0.
The result is that the icons for blocks which use dashicons are not displayed on the front end.

It would appear that the fix to this would be to enqueue dashicons.

Background

• WordPress core provides around 25 blocks and a multitude of different embeds.
• Page Builders such as Div, Beaver Builder, Fusion Builder and SiteOrigin Page Builder provide additional blocks.
• Some of these blocks are already supported by shortcodes provided by oik or oik-extension plugins.
• Some of the blocks can be made using combinations of oik-shortcodes and jQuery - i.e. mystery meat.
• Analysing the table of blocks/modules provided by core and a selected set of Page Builders we can determine which blocks are most likely to be required in the hybrid migratory period from classic WordPress to block based content.
• We need to create a plan for the development of these blocks.

Requirements summary

Taken from a summary table of known blocks/modules for the above mentioned page builders
the following blocks are required.

Notes:

• This requirements summary only covers a small subset of the shortcodes available from oik plugins.
• The priorities are very likely to change
• There is also a generic requirement for an enhanced Shortcode block.

Proposed development process

• Develop prototype blocks using shortcodes.
• Initially implement the code using server side shortcode expansion.
• Start with default processing
• Add support for parameters
• Determine which parameters should be Advanced Settings and which should be displayed in the block.
• Attempt to develop the enhanced shortcode block while discovering how to do the above.

Determining default parameters

Many of the oik shortcodes determine the values that they use from a variety of sources.

1. Shortcode parameters
2. Context/content sensitive - post type, post meta data
3. User defined options
4. Global options

The block should be sensitive to this.

For example. The default processing for [bw_show_googlemap] is to display the map associated with the company's primary address as stored in the global options field set bw_option. The alt= parameter allows selection of a different address.

When oik-user is activated the address is determined from the defined user, which can be specified as a parameter or default to the post's author.

Most values can be overridden using shortcode parameters.
Parameter overrides do not change the stored values.
We need to determine whether or not the stored values an be updated directly from the block. If not, what mechanism should we provide to allow the user to access those settings.

Requirements

• Display a Search form
• Implement a block equivalent to the [bw_search] shortcode

Proposed solution

• New block oik-block/search - Search form
• Implemented as a dynamic block for server side rendering
• No need for any parameters
• Does not need to call bw_search from oik-bob-bing-wide
• It can just use get_search_form()

The block to be added to the list of experimental blocks in #16.

In order to support the metadates.html template in FSE themes such as Written I want to replace existing shortcodes with blocks.
I found that the quickest way to implement the solution was to extend the Fields block with a co-requisite improvement to the oik-fields plugin upon which the block is dependent.

See bobbingwide/sb-field-block#5

Requirement

• Display the post_date, post_modified_date and author_name using a block or blocks.
• No need for Label as this will be provided in the template/template part.

Solution

• Extend the oik-block/fields block to add 3 new options to the fieldsOptions
• Extend oik-fields to support the rendering of the virtual field author_name.

Requirement

Create a Google Maps map block to replace/enhance [bw_show_googlemap]

Initial solution

• Dummy content in the editor
• Displays the GoogleMap using the [bw_show_googlemap] shortcode in the front end.

Requirement

• To easily add an Address block to content

Initial solution

A static block that will

• Display a simple heading
• Implement the [bw_address] shortcode
• The heading can be styled using Additional CSS class(es)

Future solution

Develop a long term replacement to accept the fields instead of having to use complicated parameters

Create a block displaying details of a person / user with contact information

The Person block will work with the oik-user plugin to display information about a particular user.
It will combine a set of shortcodes into a single block.

Initial version

Block to be the equivalent of

<h3>Person</h3>
[bw_user user=abc name,bio]
[bw_follow_me user=abc]

where abc is the user name or ID entered in the Advanced Settings User field.

Subsequent versions

• Toggle to decide whether or not to display Follow me buttons
• Options to choose the different fields
• Display other information
• Alter the block heading
• Dynamic selection from a list of users
• When oik-user is not valid use alt=0,1,2 settings

The [bw_css] shortcode, from the oik-css plugin, is used to create inline CSS.
It can also be used to document the CSS that it generates.

Gutenberg doesn't yet support this shortcode - see Gutenberg issues 5123 and 4456, already referenced by #22 - so we need to support it ourselves.

Requirements

• Develop a new CSS block which enables the user to enter CSS which will be applied inline.
• Support display of the "content" formatted using GeSHi, when required
• Format the content as is.

Proposed solution

• Create a new block called oik-css
• Support attributes as if the block were the [bw_css] shortcode
• Implement as a dynamic block, passing the block's content to the existing shortcode function oik-css.

Note: As previously noted I envisage there to be a problem with this - see #22 - and Gutenberg issues 5760 and 5968.

When analysing the block changes between Gutenberg 10.7.0 and the latest (11.6.0) I noted that the number of blocks and variations with WordPress 5.7.2 changed from 178 to 177 with Gutenberg 10.9.0, but with WordPress 5.8.0 there were many variations of the core/navigation-link block, giving 205 blocks and variations.

eg in blocks.wp.a2z the additional variations were:

1. Category Link - block_classification
2. Category Link - required_version
3. Category Link - compatible_up_to
4. Page Link - oik_file
5. Page Link - oik_class
6. Page Link - block
7. Post Link - wp_block
8. Post Link - product
9. Post Link - oik_shortcodes
10. Post Link - oik_sc_param
11. Post Link - shortcode_example
12. Post Link - oik_hook
13. Post Link - oik_api
14. Post Link - block_example
15. Post Link - oik-themes
16. Post Link - oik_themeversion
17. Post Link - oik_themiumversion
18. Post Link - oik-plugins
19. Post Link - oik_pluginversion
20. Post Link - oik_premiumversion
21. Post Link - download
22. Product Category Link - product_cat
23. Product Tag Link - product_tag
24. Tag Link - letters
25. Tag Link - block_category
26. Tag Link - block_keyword
27. Tag Link - oik_tags
28. Tag Link - oik_letters
29. Tag Link - block_letters

but the list didn't include Custom Link - core/navigation-link

With Full Site Editing coming along soon, a block's CSS styling may be defined using theme.json and the block's block.json file.
As I understand it, the theme can override the block's default styling by using theme.json
And I imagine other code can override the block's styling during registration.

But how can you tell, in advance from the front end, how the block's settings and styling are defined?

The block.json file defines the default supports and the names of the style files for the block: editor and front end.

eg for the cover block

"supports": {
		"anchor": true,
		"align": true,
		"html": false,
		"spacing": {
			"padding": true
		},
		"color": {
			"__experimentalDuotone": "> .wp-block-cover__image-background, > .wp-block-cover__video-background",
			"text": false,
			"background": false
		}
	},
	"editorStyle": "wp-block-cover-editor",
	"style": "wp-block-cover"

There are sections in theme.json which define settings, which I believe are similar to supports, and others which define the styles.
The settings may or may not trump the block's supports values
and the styles define the allowed values for the theme.

Requirement

• Display settings and styling information for chosen selected block in the front end.

Proposed solution

• TBC

In blocks which support the link tool the process of creating a link is:

• to write some text,
• then select it,
• choose the link tool,
• write most of the text again to initiate the search,
• then select the URL.

Couldn’t we just

• choose the link tool,
• perform a search,
• select the URL

and be done?

core-embed is not available in Prefix select box. Why not?

The [bw_dash] shortcode can be used to display icons from a number of fonts - dashicons, genericons, texticons and (soon) core block icons. See bobbingwide/oik-bob-bing-wide#26

While the [bw_dash] shortcode is still necessary for use in widgets and other places where it’s not yet possible to use a block, it would be nice to be able to implement an icon block.

Many page builder plugins already provide an icon like block, with lots of different options for Size, Colour, Links etc. Our block should have similar behaviour.

Requirements

• Icon block
• Allow selection of the icon to be used
• Support colour, size, positioning
• Support links e.g. as used in [bw_post] / [bw_page]
• Allow block to be nested
• Allow a post to have a featured icon, in a similar method to a featured image.

Proposed solution

TBD

Fatal error: Uncaught Error: Call to undefined function bw_get_field_names() in C:\apache\htdocs\wordpress\wp-content\plugins\oik-fields\shortcodes\oik-fields.php:74

while attempting to view a privacy policy page created by oik-privacy-policy.

Stack trace: 
#0 C:\apache\htdocs\wordpress\wp-content\plugins\oik-blocks\oik-blocks.php(322): bw_metadata(Array, NULL, NULL) 
bobbingwide/fizzie#1 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(221): oik_blocks_dynamic_block_fields(Array, '', Object(WP_Block)) 
bobbingwide/fizzie#2 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(211): WP_Block->render() 
bobbingwide/fizzie#3 C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\lib\compat.php(452): WP_Block->render() 
bobbingwide/fizzie#4 C:\apache\htdocs\wp55\wp-includes\class-wp-hook.php(287): gutenberg_render_block_with_assigned_block_context(NULL, Array) 
bobbingwide/fizzie#5 C:\apache\htdocs\wp55\wp-includes\plugin.php(212): WP_Hook->apply_filters(NULL, Array) 
bobbingwide/fizzie#6 C:\apache\htdocs\wp55\wp-includes\blocks.php(672): apply_filters('pre_render_bloc...', NULL, Array) 
bobbingwide/fizzie#7 C:\apache\htdocs\wp55\wp-includes\blocks.php(760): render_block(Array) 
bobbingwide/fizzie#8 C:\apache\htdocs\wordpress\wp-content\themes\fizzie\i in C:\apache\htdocs\wordpress\wp-content\plugins\oik-fields\shortcodes\oik-fields.php on line 74

When you’re using WordPress SEO there’s a meta box where you type a 156 character snippet.
WIBNI you had a block that displayed this to the user.
I’ve got a feeling I could use this on bobbingwide.com/problem-solving

Requirements

• Only type it once.
• Option to use this as the excerpt as well.
• Avoid confusing the SEO content analysis.

Block validation: Block validation failed for oik-block/blocklist (Object).

Content generated by save function:

and then a load of HTML.

See also bobbingwide/sb-toolicons-block#1

Gutenberg provides a mechanism called ServerSideRender which allows a block to be rendered by the server. It’s intended for legacy code, which is exactly what some of the shortcodes are. We should experiment with this solution to attempt to render the real block that’s displayed for a subset of shortcodes.
Starting with:

For some logic the server side rendering may require the global $post to be set.
Other logic needs to know the current user.

It's time to create a version of the oik shortcode blocks plugin that

• only contains working blocks
• does not have the "Preferred editor" meta box
• does not have any "opinions" logic

Create a clone from v0.0.0-alpha-20181118 of oik-block and refactor source files.

We'll change the functions and files from oik-block/ oik_block to oik-blocks / oik_blocks
BUT we won't change the block names, retaining oik-block as the prefix to allow an easy switch over.

While updating the blocks for WooCommerce I noticed that the description list icon in the CSV block's toolbar was incorrectly formatted. It was too big.

Investigate where this went wrong. Maybe it just needs a rebuild with Gutenberg 8.2.x

An alternative to #17 is to deliver each of the blocks that are prototyped in oik-blocks as part of the plugin to which they apply.

Proposed solution

Similar to how it’s done for core and WooCommerce blocks.

• New blocks would be developed in oik-blocks and released to the target plugin once past the experimentation stage.
• Blocks may be renamed in the target plugin.
  E.g. oik-block/css would be delivered in oik-css and be called oik-css/css
  Or retain the oik-block prefix;
  oik-block/googlemap, when delivered in oik, could continue to be called oik-block/googlemap.
• We’ll have to cater for duplicate registration.
• And support transforms between the prefixes.
• Common logic would be delivered in a shared library files. Already prototyped for oik-css. It shouldn’t be necessary to have oik as a pre-requisite when it’s only the block part of the plugin that’s are being used.

The [bw_csv] shortcode, delivered in oik-bob-bing-wide, provides a variety of formatting options for content entered as Comma Separated Values.
Since Gutenberg doesn’t yet support an ASIS block, which could be used as one solution to the problem, we should develop a dynamic block that supports the functionality implemented for the bw_csv shortcode

Requirements

• Develop a new CSV block which enables the user to enter Comma Separated Data
• Support the existing options to define the output format
• Support the existing options to load the CSV content from an attachment
• Support the existing option to convert selected characters to dashicon ticks and crosses
• Support inline shortcodes

Proposed solution

Initial solution

• Develop a dynamic block called oik-block/csv in blocks/oik-csv
• Support attributes as if the block were the [bw_csv] shortcode
• Store the data for $content in an attribute called content

Future

• Add support for displaying an uploaded CSV file

I'm raising this here while I figure out if this is a bug with WordPress 5.1 or something else.

Having upgraded to WordPress 5.1.1, I now get problems with Add new.
Almost immediately the message box saying "The editor has encountered an unexpected error." appears.

The console log reveals...

Uncaught TypeError: Cannot read property 'prefix/block_name' of undefined
    at getInsertUsage (editor.js:12344)
    at buildBlockTypeInserterItem (editor.js:12493)
    at Array.map (<anonymous>)
    at editor.js:12543
    at callSelector (editor.js:829)
    at runSelector (data.js:709)
    at editor.js:18325
    at getNextMergeProps (data.js:1738)
    at new ComponentWithSelect (data.js:1756)
    at constructClassInstance (react-dom.js:12604)

where prefix/block_name is the name of the Most Used registered block.
Sometimes it's oik-block/github, but when I deactivate the plugin that registers it, it's core/paragraph.

The problem is only a problem for one subdomain, in a local installation of wp-a2z.org.
The local domain is blocks.wp.a2z

The problem occurs on Chrome Version 73.0.3683.86 (Official Build) (64-bit)
It does not happen with Firefox or Edge.

Problem appeared to be resolved after clearing the cache but came back very quickly when I reactivated my own plugin. The block name appearing in the message changed back to "oik-block/github". Previously, when the only routine registering blocks was WordPress core the block name was "core/paragraph".

Requirements

Ability to write some text and have it formatted like magnetic poetry. See Wikipedia: Magnetic Poetry

Proposed solution

• A Block where every word is styled to look like one of the magnets from a magnetic poetry set.
• Similar to the CSV, CSS and GeSHi blocks.
• The styling to be added using CSS class names.
• Parsing of the text to be implemented using PHP initially.
• Possibly implemented partially or fully as a separate plugin.
• Consider using the lines from Hello Dolly as random source for the block when the content is left blank.
• But only when Hello Dolly is available... not necessarily active.

It's been some time since I built the code with Gutenberg. It was last built with 2.9.2. There have been many changes since, with code being deprecated and so on.
Some of the blocks no longer work. They need fixing. I'll use the original issues for each block, adding a comment on each on that doesn't yet work.
Some of the blocks may be rewritten to reflect a better way of implementing the code in the first place.

Note: Issue references needed updating after the issues were transferred from oik-block to oik-blocks. Labels also need re-creating.

For single block plugins with the same prefix ( e.g. sb ) I need a way to display a link to the block from the block's plugin page when more than one plugin with the block prefix is activated.

Currently the block info block produces something quite different. Normally it doesn't need to link to itself since it's used to document the block in question. In this example we want the block info block to display the link as shown for the sb/parent-block

Proposed solution

• An easy way of doing this is to implement logic in the Block info block to display the block using Block list block's logic.
• There should be a toggle to display the block in the block list style.
• Optionally support disabling of the link - for when the block is not actually catalogued.

The oik-blocks plugin was originally built using webpack.

When used in WordPress 5.8 the Widget block editor produces a "doing it wrong" message due to the enqueueing of wp-editor;
This is used for Server Side Rendering

It seems the best solution is to rework the code to build it using wp-scripts which will enable use of

import ServerSideRender from '@wordpress/server-side-render';

See bobbingwide/bobbingwide#30 (comment)

It also is dependent upon wp-editor for other functions such as getPermalinkParts, which is used by the oik-block/blockinfo block. When wp-editor is not enqueued the Widget block editor fails with:

blocklist.js?f522:116 Uncaught TypeError: Cannot read property 'getPermalinkParts' of null
    at getBlockLink (blocklist.js?f522:116)
    at BlockListItem (blocklist.js?f522:140)
    at BlockinfoStyled (blockinfo.js?df38:36)
    at edit (index.js?0538:188)
    at renderWithHooks (react-dom.js?ver=16.13.1:14938)
    at updateFunctionComponent (react-dom.js?ver=16.13.1:17169)
    at beginWork (react-dom.js?ver=16.13.1:18745)
    at HTMLUnknownElement.callCallback (react-dom.js?ver=16.13.1:182)
    at Object.invokeGuardedCallbackDev (react-dom.js?ver=16.13.1:231)
    at invokeGuardedCallback (react-dom.js?ver=16.13.1:286)

I don't yet know how to resolve this additional problem.

Note: When wp-editor is not enqueued the Block editor fails earlier than the Block widget editor, with Uncaught TypeError: Cannot read property 'ServerSideRender' of undefined.

Requirements

• Ability to use the Widget block editor without getting messages regarding wp-editor.
• Which means changing the build to allow the import above.
• Build using wp-scripts
• Register the blocks using block.json
• Ensure the blocks can be selected
• Add some color and typography settings where applicable
• Add text align capability where applicable
• Remove deprecated blocks which are now in other plugins.

Proposed solution

• Copy and cobble the solution developed for oik-bob-bing-wide
• Remove unnecessary files: webpack.config.js and .babelrc
• Change package.json
• Eliminate the blocks that are no longer needed
• Change block.json for each block
• Change each block's index.js to register the block
• Change each block's Server Side Registration to register the block from block.json
• Change each block to use get_block_wrapper_attributes(), where applicable
• Update node_modules and rebuild
• Internationalize and localize

Process for updating node_modules

1. Remove the existing node_modules folder
2. npm install
3. npm install @wordpress/scripts --save-dev

See https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/

When I tried to catalogue the blocks for the Qubely plugin I was dismayed to discover that the icons were enormous.
What do I need to do to get them to a manageable size?

Explanation

Qubely's icons are delivered as SVG images with no indication of size.
The size needs to be managed with CSS.
eg For the oik-block/blocklist the CSS could be

.wp-block-oik-block-blocklist dt img { width: 24px; height: auto; }

For the block icon it's

.wp-block-oik-block-blockicon img { width: 24px; }

For the block info block it's

.wp-block-oik-block-blockinfo img { width: 24px; }

Proposed solution

• Add the required CSS to the style.scss and editor.scss for the blocks, where relevant.
• Add support for each style: is-style-svg24, is-style-svg64, is-style-svg100, is-style-svg150
• Consider using a multiple style sheet approach

When the Dynamic content block is first displayed, very few of the attributes are set. The server side rendering is invoked but the shortcode attribute is not set. The result is '[]'.

How can this be improved?
See #34

While testing which plugin other than oik implemented the filter than enables oik-magnetic-poetry's block to localize correctly I got a Fatal error after activating oik-blocks.

Fatal error: Uncaught Error: Call to undefined function bw_load_plugin_textdomain() in 
C:\apache\htdocs\wordpress\wp-content\plugins\oik-blocks\oik-blocks.php:350 
Stack trace: 
#0 C:\apache\htdocs\cwiccer\wp-includes\class-wp-hook.php(303): oik_blocks_plugins_loaded('') 
#1 C:\apache\htdocs\cwiccer\wp-includes\class-wp-hook.php(327): WP_Hook->apply_filters(NULL, Array) 
#2 C:\apache\htdocs\cwiccer\wp-includes\plugin.php(470): WP_Hook->do_action(Array) 
#3 C:\apache\htdocs\cwiccer\wp-settings.php(441): do_action('plugins_loaded') 
#4 C:\apache\htdocs\cwiccer\wp-config.php(118): require_once('C:\\apache\\htdoc...') 
#5 C:\apache\htdocs\cwiccer\wp-load.php(50): require_once('C:\\apache\\htdoc...') 
#6 C:\apache\htdocs\cwiccer\wp-admin\admin.php(34): require_once('C:\\apache\\htdoc...') 
#7 C:\apache\htdocs\cwiccer\wp-admin\plugins.php(10): require_once('C:\\apache\\htdoc...') 
#8 {main} thrown in C:\apache\htdocs\wordpress\wp-content\plugins\oik-blocks\oik-blocks.php on line 350

Apparently it's no longer necessary to enqueue style sheets for the block editor with a dependency on wp-blocks.

It's still necessary to enqueue scripts with a dependency on wp-blocks.

At present oik-blocks builds one file containing all the oik blocks built so far, regardless of the availability of the server functionality to display the block. It would be nice if the blocks could be built in such a way that the user could choose which blocks are available for content creation. The server code will evaluate the installation and only register the components needed for the required blocks.

This would be a nice addition to use to document the Block CPT.

Requirements

• a Fields block for the [bw_fields] [bw_field] shortcode, from oik-fields
• Allows display of meta data and virtual fields

Proposed solution

• New block oik-block/fields - Fields
• Implemented as a dynamic block for server side rendering
• Easy options for choosing the fields attribute: featured, etc
• Checkbox to choose [bw_fields] or [bw_field] logic; with or without labels
• Allow entry of field names too

The block to be added to the list of experimental blocks in #16.

When I first tried to add styles to the block icon block I managed to write some CSS to display the icon with 4 different sizes:

It worked if I used the additional CSS class above but not when the class name was prefixed with is-style. eg is-style-svg64.

On reinvestigation - after finding out how to style paragraphs, list and groups into mutiple columns - I found some CSS that enables the is-style-svg64 CSS to take effect in the editor. It overrides the WordPress core styling for the .block-editor-block-icon class, setting the display to inline ( was flex ).

/**
 Override default styling for block icons.
*/
.wp-block-oik-block-blockicon .block-editor-block-icon {
  display: inline;
}

Requirement

• Provide styles as an easy way to choose the size of the icons displayed by oik-blocks/blockicon block
• Default to 64px
• Change the smallest size from 20px to 24px

Solution

• As above

Problems with Columns variations icons

In earlier versions of Gutenberg certain icons appear differently in the editor than in the front end.
eg Columns variations.

In the block editor the icons are not filled with black

Problem with Comment Author Name icon

With Gutenberg 11.9.0 the icon for the new Comment Author Name block is visible in the block icon block in the editor but not in other blocks nor on the front end.

The SVG for the Comment Author Name block is

<svg width="24" height="24" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg" fill="#FFFFFF" role="img" aria-hidden="true" focusable="false"><path d="M18 4H6c-1.1 0-2 .9-2 2v12.9c0 .6.5 1.1 1.1 1.1.3 0 .5-.1.8-.3L8.5 17H18c1.1 0 2-.9 2-2V6c0-1.1-.9-2-2-2zm.5 11c0 .3-.2.5-.5.5H7.9l-2.4 2.4V6c0-.3.2-.5.5-.5h12c.3 0 .5.2.5.5v9z" fill-rule="evenodd" clip-rule="evenodd"></path><path d="M15 15V15C15 13.8954 14.1046 13 13 13L11 13C9.89543 13 9 13.8954 9 15V15" fill-rule="evenodd" clip-rule="evenodd"></path><circle cx="12" cy="9" r="2" fill-rule="evenodd" clip-rule="evenodd"></circle></svg>

Here we see the fill='#FFFFFF' attribute on the SVG tag. For the block info block the icon is invisible.

Using the inspector and changing this value to #CCCCCC, for example, allows us to see the icon in the block editor.
Alternatively we can set a background colour.

This problem was originally mentioned in #50 (comment)

Requirement

• Icons should look the same in the editor and the front end

Proposed solution

• Discover what's needed to style icons that have the following attributes that need a little more care and attention: fill, fill-rule, cllp-rule etc
• Implement appropriate CSS

Fatal error: Uncaught Error: Call to undefined function is_plugin_active() in C:\apache\htdocs\wordpress\wp-content\plugins\oik-blocks\oik-blocks.php:408

  | Stack trace:
  | #0 C:\apache\htdocs\wordpress\wp-content\plugins\oik-blocks\oik-blocks.php(316): oik_blocks_check_server_func('shortcodes/oik-...', 'oik-fields', 'bw_metadata')
  | #1 C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\lib\compat.php(132): oik_blocks_dynamic_block_fields(Array, '', Object(WP_Block))
  | #2 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(221): {closure}(Array, '', Object(WP_Block))
  | #3 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(211): WP_Block->render()
  | #4 C:\apache\htdocs\wp55\wp-includes\blocks.php(864): WP_Block->render()
  | #5 C:\apache\htdocs\wp55\wp-includes\blocks.php(902): render_block(Array)
  | #6 C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\template-part.php(89): do_blocks('<!-- wp:group {...')
  | #7 C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\lib\compat.php(132): gutenberg_render_block_core_template_part(Array, '', Object(WP_Block))
  | #8 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(221): {closure}(Array, '', Object(WP_Block))
  | #9 C:\apache\htdocs\wp55\wp-includes\blocks.php(864): WP_Block->render()
  | #10 C:\apache\htdocs\wp55\wp-includes\blocks.php(902): render_block(Array)
  | #11 C:\apache\htdocs\wp55\wp-includes\block-template.php(171): do_blocks('<!-- wp:html --...')
  | #12 C:\apache\htdocs\wp55\wp-includes\template-canvas.php(12): get_the_block_template_html()
  | #13 C:\apache\htdocs\wp55\wp-includes\template-loader.php(106): include('C:\\apache\\htdoc...')
  | #14 C:\apache\htdocs\wp55\wp-blog-header.php(19): require_once('C:\\apache\\htdoc...')
  | #15 C:\apache\htdocs\wp55\index.php(17): require('C:\\apache\\htdoc...')
  | #16 {main}
  | thrown in <b>C:\apache\htdocs\wordpress\wp-content\plugins\oik-blocks\oik-blocks.php</b> on line <b>408</b><br />

Following on from #24 (comment) I now have requirements for a Block list block.

This block will be used on the home page for a component which delivers blocks.

Requirements

• Create a list of grid of the blocks associated with a particular block type name namespace prefix.
• Display the icon and block name
• Optionally, link to the block post where the block is documented

Proposed solution

• Use existing logic for Block icon and Block info to populate the List
• Construct the link using the same logic as that used by core to create permalinks.
• Layouts to be List, Table and Grid

Block type name: oik-block/blocklist
Title: Block list
Icon: block-default

Having battled with multiple attributes in the Countdown block I now want to try to implement a generic solution that uses the techniques suggested by @aduth.
We'll try doing this for the [nivo] shortcode.

These are the helpful notes from Andrew Duthie.

These aren’t really specific to Gutenberg, but to your questions on generalization, seems like it can be solved with a few functions, and maybe some partial application via Function#bind (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind) or Lodash/Underscore _.partial http://underscorejs.org/#partial

onChange={ partial( handleChange, 'someKey' ) }

/// ...

function handleChange( key, value ) {
var nextAttributes = {};
nextAttributes[ key ] = value;
setAttributes( nextAttributes );
// ES6: setAttributes( { [ key ]: value } );
}

I’d suggest reading more on the keys article, as the answer is not “add key to everything”, it’s specific to when you’re returning an array from a component (you can also return Fragment to avoid this, wp.element.Fragment https://reactjs.org/docs/fragments.html) or when mapping over arrays

And for the distinction on controlled and uncontrolled form components https://reactjs.org/docs/forms.html

Requirement

• An easy way to produce links to issues on GitHub

Prototype solution

• Initially the GitHub block will simply contain HTML to invoke the [github] shortcode ( from oik-bob-bing-wide )
• The only variable will be the issue number - the 4th parameter to the shortcode
• This needs to be extended so that multiple issue numbers may be entered

Future solution

• It should detect URLs pasted into the content and automatically update the block

• Or support conversion from a GitHub link to a block.

• Or just detect #xxxx in the same way that GitHub does.