Deliver blocks in their own plugins

[bobbingwide]

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.

[bobbingwide]

Common logic would be delivered in a shared library files

See: https://github.com/bobbingwide/oik/issues/137

deliver each of the blocks that are prototyped in oik-blocks as part of the plugin to which they apply

Plugin	Issue	blocks	Status
oik	https://github.com/bobbingwide/oik/issues/138	6 blocks	Done oik v4.0.0
oik-css	https://github.com/bobbingwide/oik-css/issues/9	2 blocks	Done oik-css v1.0.0
uk-tides	https://github.com/bobbingwide/uk-tides/issues/7	1 block	Done uk-tides v2.0.0
oik-bob-bing-wide	https://github.com/bobbingwide/oik-bob-bing-wide/issues/25	5 blocks	Done oik-bob-bing0wide v1.34.0
oik-fields	tbc	1 block
oik-nivo-slider	tbc	1 block
oik-user	tbc	1 block
oik-blocks	this issue	3 blocks

[bobbingwide]

Still need to extract the Fields block into oik-fields and the Nivo block into oik-nivo-slider.