Create a dynamic content block for oik-shortcodes

[bobbingwide]

Now that oik v4.0.0 has been delivered with the simple oik/shortcode-block I want to deliver the oik/content-block.

This will be a front end to the following dynamic shortcodes.

Shortcode	Plugin
bw_attachments	oik
bw_images	oik
bw_pages	oik
bw_pdf	oik
bw_posts / bw_list	oik
bw_related	oik-fields
bw_testimonials	oik-testimonials
bw_thumbs	oik
bw_tree	oik

Proposed solution

• Develop functionality in oik-blocks, as oik/content-block
• Migrate to oik when it's working

To achieve this I'll create the issue under oik, then transfer it to oik-blocks, and transfer it back again.

[bobbingwide]

Just realised that commits I’ve made in the issue for oik-blocks will not be followable when the code is copied/cobbled back to oik.

[bobbingwide]

While testing Attachments and Images I had a hell of a time trying to work out what values I needed to pass for the post_parent parameter. I fell foul of a number of idiosyncrasies.

Differences in the parameters ( attributes) passed to dynamic blocks.

• When the block editor invokes server side rendering it passes one set of parameter values.
• When the block is invoked on the front end is gets a different set of values

This is due to the way defaults are handled in the editor. It's a known problem but I don't believe anything's going to be done about it.

Shortcodes behaving differently with post_parent=.

Some of the dynamic shortcodes allow you pass special values that cause certain parameters to be ignored or used in a non-standard way.

• If the value for post_parent is not set and the post_type is page or attachment then the logic in bw_get_posts() will default it to the curent post ID ( bw_current_post_id() ).
• For bw_tree passing a value of '.' uses the post's parent. a null ( missing ) value is used to identify the current post as the root of the tree

And the attachments weren't actually attached...

I was also making assumptions that the attachments/images being listed were actually attached to the posts.

Aside: The WordPress editor no longer provides an easy way to find out what's actually attached to a post.

You can just about use the Media admin interface if you can sort the display by Uploaded to and find the parent post.
Not easy when the list is huge.

In the classic editor you could choose the Add Media dialog and select Uploaded to this post.

TL:DR

Rather than change the logic of bw_get_posts() the logic in oik_content_block() works around the idiosyncracies to attempt to make the UI appear consistent for the functions it provides.

So, for Attachments and Images a value of '.' for post_parent will be converted to the current post ID, to list the attachments which are Uploaded to this post.

It was also necessary to ensure that the id attribute wasn't being passed as null. I think this might be fixing a bug from a long time ago.

[bobbingwide]

I also felt it necessary to update the function oik_blocks_attribute_unset_or_trim().
Its purpose is to attempt to eliminate unwanted attributes that have been passed from the editor which would adversely affect the behaviour of the server side rendering logic.
e.g. for the post_parent attribute/parameter we don't want to pass a null value if the field is blank as this won't allow the value to default.

Note: This function is in a shared library file, so other plugins will need updating.

[bobbingwide]

While looking at bw_list and bw_posts I realised that bw_posts was just an easy wrapper to bw_list. So we really only need the display option for bw_list.

[bobbingwide]

I think it's time to transfer the oik/content-block from oik-blocks to oik.
It should be a reasonably simple case of moving the source files and cutting and pasting the server side rendering.
But there's also i18n and l10 to consider.
Since oik-blocks doesn't yet implement i18n and l10n should this be done first?
Or is that just procrastination?

Migration steps

1. Copy src files from oik-blocks to oik
2. Copy server side rendering logic from oik-blocks to oik
3. Change build in oik
4. Deactivate oik-blocks and test the new block in oik
5. Remove oik/content-block from oik-blocks
6. Reactivate oik-blocks
7. Remove logic from oik-blocks
8. Commit changes to oik-blocks
9. Transfer issue to oik
10. Commit changes to oik under new issue number

[bobbingwide]

This is still open since:

1. The block hasn't been internationalised.
2. The block hasn't been tested for some of the harder to get right shortcodes

[bobbingwide]

The following Warning appears in the Chrome console log for the oik-content block.

wp.compose.withState is deprecated since version 5.8. Please use wp.element.useState instead.

See query_controls.js. Since this logic is not used the simplest fix is to comment it out.