Convert Event-List block into query block-variation

[carstingaxion]

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

Goal & Intent

I wanted to proof my idea, that it should be relatively simple to convert the existing GatherPress Event List block into a tailored block-variation of the core Query block.

Using a native, core ~ instead of a custom block has the following advantages:

1. Allows endless customisation in terms of layout & style

2. Reduce the number of strings to translate and comes with many translations for the core-strings.

3. Allows users to select from explicit compositions of block-patterns directly via the blocks Choose (layout) button and the Replace button in the top toolbar.

   Bildschirmaufzeichnung.vom.11.03.2024.23.57.12.mp4

4. Allows users to choose starter-content via the blocks Start blank button and the underlying Block Variation Picker.

   Bildschirmaufzeichnung.vom.11.03.2024.23.43.00.mp4

5. Allows developers to register custom taxonomies with events, which would allow users to query by those taxonomies using native UI elements of the query block.

Steps I took

• At first I started creating a block-variation for the query block from scratch ... but realised very soon, that most of what's going to be needed, is already in the Advanced query loop plugin by @ryanwelcher.

• So I forked it as a kind of feature plugin for GatherPress. At this point I was unsure about the amount of changes I would have to do, so it seemed cleaner to me, instead of experimenting within a huge plugin like GatherPress directly.

• I renamed all slugs and prefixes etc. from advanced or aql to gatherpress or gpql.

• Further on, I disabled some of the functionality, just by commenting out code.

• Disabled some of the native block-controls of the query-block, like the post type select.

• But kept some of the additional components from the advanced-query-loop plugin, that could be helpful or seemed interesting to us (or at least to me).

• I had to revert BLOCK Limit Event and Venue blocks to events and venues #207, to be able to use all of the existing blocks outside of event- and venue-posts and within a query block.

• Got this working on the frontend, because of the nature of dynamic blocks and that they already rely on get_the_ID(). Nice!

  

  

  Bildschirmaufzeichnung.vom.11.03.2024.22.55.35.mp4

• Until this point I was able to handle every change within the gatherpress-query-loop feature-plugin, but at some moment I (saw no way around, that I) needed to do some changes to GatherPress itself, so I created the earlier mentioned experimental-branch to also hold some of the changes.

• Tried to make the existing blocks aware of usesContext: postId to also get this working in the backend ... which was my weekends rabbit hole.

  I mainly focused on the gatherpress/event-date and the gatherpress/venue blocks. And totally struggled, getting the blocks to work with the current post ID instead of the event-list logic.

  Bildschirmaufzeichnung.vom.11.03.2024.23.11.39.mp4

• I got this partly working for the Venue block, to show the venue_information in front- AND backend. Unfortunately online-events are still only shown in the frontend, yet.

---

All of this is by far not finished, but I needed to get this out.
This all is still an absolute mess on its own, a mess in terms of performance and not DRY at all, but it works and should help illustrate the idea.
What do you think?

Next steps

• Would it make sense to port this feature-plugin or parts of it into GatherPress core?

If yes, ... we should ...

• Make the Event Date Block aware of usesContext: postId
• Make the Venue Block aware of usesContext: postId
• Make the Online-Event Block aware of usesContext: postId
• Make the Attending Block aware of usesContext: postId

Questions

• What is or was the purpose of the 'gp_general''pages' option, as it seems to become obsolete within block themes in general and with my suggested changes in particular?!
• Which parts of the GatherPress code-base could help me while refactoring the existing blocks to utilise usesContext?
• Could I use one of the existing REST API endpoints to get datetime and venue information together for a given event?
• You (as a team) know the code and especially the inner workings of the blocks much better than me. Would you either recommend to modify or replace the existing blocks to make them work inside query blocks?
• What Kind of pattern would you like to see
  a) for the Choose Layout modal
  b) for the Start blank option?
• Should I or we provide any kind of block-deprecation logic for the Event List block, or can I or we be lazy about this breaking-change as long as we don't have launched the magical v1.0?
• I would love to get a sortable, tabular view working! Is anybody interested in exploring Display Posts in Sortable Table WordPress/gutenberg#25503 together with me? This could be one next big thing on the GatherPress journey.

[mauteri]

@carstingaxion I'm still reviewing all your notes, but I did download your work and tested it and was very cool. I think this could be a really cool change that could deprecate Events List with the release of WP 6.5 which leverages the query block and the interactivity API. One of the things I'd like to keep that is a feature of the Events List is that you can RSVP to an event from there, which is a dynamic feature of that block. I think we can replace a lot of the custom dynamic elements of our blocks and leverage the interactivity API, which is a better solution than the one we currently have (which is there because such things didn't exist when the blocks were initially built).

I'd also love to give you a more detailed tour of the plugin. Would you be able to jump on a Zoom with me for half hour or 45 minutes for me to take you through the plugin and some of the decisions that were made that we can discuss and think over. Let me know and thanks for doing this deep dive into our blocks!

[mauteri]

Docs on Interactivity API coming in WP 6.5 which I think we can leverage for many of our more dynamic blocks https://make.wordpress.org/core/2024/03/04/interactivity-api-dev-note/

[carstingaxion]

NOTE: I updated some links in my initial comment, because I had to do some housekeeping & renamed the repository containing my experiment from 'gatherpress-query-loop' to 'additional-advanced-query-loops', which now has a dedicated branch of gatherpress-query-loop.

You can test the block within my GatherPress Block Playground

[carstingaxion]

Started working on the ORDER BY of the query:

• datetime (default)
• random
• title
• post_id
• last modified date

[carstingaxion]

While working on the GatherPress query block I was annoyed by some core behaviour, so I also created a PR for that. And got it merged, my first ever code contribution to Gutenberg. Hooray!🎉

[MervinHernandez]

✅ Viewed 599 - Query Loop Block compliance - Carseten has it

[carstingaxion]

Finished ORDER BY

[carstingaxion]

Implemented a new control, which allow for inclusion or exclusion of started, but not finished, events.

Bildschirmaufzeichnung.vom.16.06.2024.21.18.41.mp4

[MervinHernandez]

✅ Reviewed June 22 - Carsten has it

[carstingaxion]

Fixed the UX fail, @patriciabt mentioned in slack, that's confussing to have two blocks to query events, the regular core/query block and the new Event Query block. I agree.

Bildschirmaufzeichnung.vom.21.07.2024.07.37.20.mp4