Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blocks in the big picture #626

Open
10 of 35 tasks
carstingaxion opened this issue Mar 29, 2024 · 3 comments
Open
10 of 35 tasks

blocks in the big picture #626

carstingaxion opened this issue Mar 29, 2024 · 3 comments
Labels
blocks enhancement New feature or request Tracking Overview topic

Comments

@carstingaxion
Copy link
Collaborator

carstingaxion commented Mar 29, 2024

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

1.2 Blocks under construction

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.

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:

  • 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:

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

Designs

image

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

  • I agree to follow this project's Code of Conduct
@carstingaxion
Copy link
Collaborator Author

carstingaxion commented May 23, 2024

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

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

post--about-a-location

@carstingaxion
Copy link
Collaborator Author

gatherpress-blocks-with-new-icons_bg

@carstingaxion
Copy link
Collaborator Author

carstingaxion commented Jun 8, 2024

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocks enhancement New feature or request Tracking Overview topic
Projects
None yet
Development

No branches or pull requests

1 participant