Add group block-variation to provide context like the existing gatherpress/venue block does

[carstingaxion]

Is your enhancement related to a problem? Please describe.

tl/dr:
Install the demo plugin using the main.zip AND checkout the corresponding experimental branch of the GatherPress plugin to try out my exploration.

You can test the block within the GatherPress Block Playground

---

With the introduction of block-variations to provide greater flexibility for all kinds of event and venue data, the existing gatherpress/venue block needs to be split into separate blocks.

GatherPress’ users needs a way to edit the venue details within an event using the same UI concepts, they already know and are familiar with. This means, that all parts of venue information needs to become separate blocks. This for itself seems to be trivial, as all the data already exists and the new Block Bindings API makes it easy to get and show this data. But how to make use of such gp_venue-related blocks within an gp_event post type?

GatherPress needs a way to provide context to these venue blocks within an event.

Within the editor the context property is mainly used to show content of dynamic blocks, such as core/post-title or core/featured-image. Context contains at least a post ID and a post type.

I’d like to suggest the inclusion of a new kind of wrapper block, that provides the needed context to show data from another post type, gp_venues in this case.

My proposed block is a variation of the core/group block. It provides context into a selected OR inherited venue post. The venue is promoted to all innerBlocks using context.

The default innerBlocks are set to be the new to register venue-details block-pattern, which should receive all relevant blocks hooked in automatically.

used within Events

Probably the most important use-case, is to show venue details on an event page or in any kind of event (query) list.

The block(-variation) is a dynamic and context-aware block. This means the block shows the venue of the current event. This is the same in the editor, in the frontend, in singular views or used within a query block.

Inside the editor, the block acts as the taxonomy term selector for the given event. A selected venue will be assigned to the currently edited event. Identical to how the existing gatherpress/venue block does it.

used anywhere else

Used in any other context than an event post, the block works more as a portal block.

The block still allows to select a venue, but instead of acting on the post level, this time the selected venue is saved into the blocks attributes. The block(-variation) is now a dynamic and context-unaware block.

To be able to use this block everywhere, would be new and a change to the current behaviour, which is should could be discussed in ... #207

open ... problems, challenges, questions

• Request to re-open & re-think BLOCK Limit Event and Venue blocks to events and venues #207
• block-variations can not be other block-variations #630
• Overwriting and re-setting the global $post might be a very bad idea and should be avoided.
  But how? setup_postdata() was not enough.
  This was or is needed because the core/post-title block, did not respect the given context - in opposite to all other core blocks ... because ... surprise:

  "The $post argument is intentionally omitted" on the core/post-title block."
  (source: render_block_core_post_title())

• What to allow/do/show, when an Online-Event or no venue at all is selected?

Designs

1. Use within an Event

   Bildschirmaufzeichnung.vom.31.03.2024.10.23.16.mp4

2. Use anywhere else - in a post for example

   Bildschirmaufzeichnung.vom.31.03.2024.08.06.08.mp4

3. Use within a Query block
   ...

The current code is an experiment, I didn't take any time (yet !) for documentation, coding standards and testing.

And I'm an absolute react noob, so my components will probably render way too often. Please take a look at performance.

Describe alternatives you've considered

I've spent half the time working on a block-variation of the core/query block, because this one seemed to be the best fit, as it already provides context. But ... long story short ... this didn't work.

I guess I could write an essay about this journey as well, but I'll keep this, and the code, for later in case the group block variation is not going to be the right direction.

Code of Conduct

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

[carstingaxion]

• Create a new Venue (post) instantly using the block, while editing or creating an event
  • Disable if current user can’t create venues
  • Disable if inside query block (done by default by the venueEdit component)
  • Enter & save full Address into post_meta
  • Pre-select new created venue in VenuePostsComboBox
  • Pre-select new created venue in VenueTermsComboBox
  • Pre-populate the title-field of a new venue with the current value from search state

Bildschirmaufzeichnung.vom.18.07.2024.23.10.33.mp4

Related

Note to self: see Part 4 of Create your First App with Gutenberg Data:

• Building a Create page form !!

Or watch https://github.com/bacoords/block-styles-manager/tree/main/src

[carstingaxion]

• Fix 🐛 wIthin the VenuePostsComboBox and VenueTermsComboBox component:

  When selectedPostId is outside, the requested (10 posts) per_page, nothing gets pre-selected in the comobobox.

• Disable the venue-details block if inside a venue post