blocks in the big picture

[carstingaxion]

As GatherPress strives to stay close to WordPress core development, this issue should provide on overview of recent changes within GatherPress' overall block architecture.

Leading goal is to have greatest flexibility while using the blocks, for the end-user and for developers. This could also help lowering the maintenance time needed, to keep GatherPress' blocks in sync with actual WordPress core development.

This involves two main aspects:

1. Allow for flexible styling of all (our) blocks, while still relying on any conventions given by the current theme.
2. Allow for flexible handling, insertion and removing of any blocks by extenders and themers.

1. Flexible block styling and full theme compatibility

As already pointed out extensively, Block Variations provide (actually) one of the best ways to extend WordPress. That's why GatherPress will convert as much of the existing custom blocks into core block variations with the needed extra functionality added.

While block variations seem to be the best option, there are stil some caveats to think about or discuss:

1.1 Caveats of block variations

• [ ] Naming things
• [ ] #631
• [x] the buggy isActive callback is fixed
• [ ] Request to re-open & re-think #207
• [ ] useless UI, that can not be (easily) removed, e.g. https://github.com/WordPress/gutenberg/issues/50458
• [ ] #630
• [ ] block deprecations for blocks prior 0.29.0

1.2 Blocks under construction

• [ ] Event List

  • 599

  • 414

  • 125

• [ ] Venue

  • 629

  • 562

  • [ ] NEW Venue Website

    • 638

  • [ ] NEW Venue Telephone
  • [ ] NEW Venue Map

    • 639

    • 561

    • 527

• [ ] Add to calendar

  • 606

• [ ] Event date

  • 135

• [ ] RSVP

  • 691

  • 589

  • 573

  • 592

• [ ] RSVP Response
• [ ] Online-Event

  • 690

2. Flexible block handling

2.1 Using the Block Hooks API

Since WordPress 6.5 the Block Hooks API allows to set attributes on injected blocks. Until 6.5 WordPress it was only allowed to hook in blocks by their name. This addition was a necessary need to use this feature in GatherPress, because since we (will) don't have custom blocks anymore.

Currently GatherPress decides what blocks will be loaded by default using the template property of the registered post types for venues and events respectively.

Instead of loading blocks directly into the editor, we are going to load patterns now. Patterns allow to be filtered by the (upgraded since 6.5) Block Hooks API. Making use of this API brings at some advantages, which are at least:

• GatherPress' blocks can be easily moved, modified or removed by extenders via standardised core code
• GatherPress provides central entry points for plugin developers to hook in own blocks, to extend GatherPress
• GatherPress' blocks will provide their hooking code themself, which keeps concerns separate and code clean.

Therefore GatherPress registers two invisible block patterns, that are used as template properties of the main post types.

• [ ] #628
• [ ] Having this additional filter in place reduces the need for an additional setting, see #528
• [ ] Using the Block Hooks API on block variations, that use the Block Bindings API, is not DRY

2.1.1 Invisible event pattern entry-point

The following blocks do already implement their hooking:

• [ ] Add to calendar
• [ ] Event date
• [ ] RSVP
• [ ] RSVP Response
• [ ] Venue

2.1.2 Invisible venue pattern entry-point

This new (to create) venue-pattern entry-point is used for new posts via the template property, as well as as innerBlocks property of the new Venue block.

The following blocks do already implement their hooking:

• [x] NEW Venue Website
• [ ] NEW Venue Telephone
• [ ] NEW Venue Map

2.2 Using slotFills

Similar to the central entry points GatherPress provides with the former mentioned patterns, it provides central administrative entry-points within the editor for all related block options.

Close to the current implementation, GatherPress keeps relevant post data about the currently edited venue or event post within one InseptorControls panel, specific for each post type. But instead of defining all editable fields for this panels in two central places, in the future GatherPress will just provide two open slots to be filled externally.

Every slot belongs to one of each post type. Additionally the venue-slot will be added to the event-slot automatically.

Every GatherPress block registers a fill for either the venue- or the events-slot. Plugin developers could provide their additions to GatherPress within the slots as well, which will help keeping the overall admin interface clean.

All blocks with own administrative sidebar-elements will probably need to register a fill for one of the slots. This actually includes:

• [ ] Event date
• [ ] RSVP
• [x] Venue

  • 151

  • [ ] NEW Venue Website
  • [ ] NEW Venue Telephone
  • [ ] NEW Venue Map

Two combined slots and the registered fills from the blocks will feel the same like the current implementation, but be way more flexible.

Designs

By installing all of my exploration plugins With the GatherPress Block Playground, you could can see all the ideas in action, but bringing them to live inside real GatherPress would make me really happy.

Describe alternatives you've considered

I haven't considered any alternatives, that's why I'm a little bit scared, about your feedback on this matured proposal.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[carstingaxion]

By installing all of my exploration plugins you could ...

With the GatherPress Block Playground, you can see all the ideas in action!

[carstingaxion]

[carstingaxion]

The upcoming Online-Event block is already in the Playground and here:

https://github.com/carstingaxion/gatherpress-onlineevent-or-venue-block