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: bobbingwide/oik#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	bobbingwide/oik#138	6 blocks	Done oik v4.0.0
oik-css	bobbingwide/oik-css#9	2 blocks	Done oik-css v1.0.0
uk-tides	bobbingwide/uk-tides#7	1 block	Done uk-tides v2.0.0
oik-bob-bing-wide	bobbingwide/oik-bob-bing-wide#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.