Replies: 1 comment 3 replies
-
|
It sounds like if you wanted to make the calendar completely dynamic, you'd probably want to follow the Query and Post Template block way of doing things. And my understanding is that you can absolutely use the existing Query and Post Template blocks in conjunction with a custom post type and post meta (but I haven't worked on these blocks so could be wrong!). The inner blocks of the Post Template form what each event in the loop looks like. For your events might be a mixture of existing core blocks (Post Title, Post Featured Image) and custom blocks (e.g. Event Date), you could re-arrange those blocks into whatever layout you want. The custom blocks would work in a similar way to a core block like the Post Title block (https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/post-title/edit.js). They could use block context to pull in the details of the postType and postId, and the edit function would use the For the frontend of the site, these blocks are dynamic blocks, so it'd be a PHP implementation, but it'd be a similar situation of using block context to fetch the post id, grabbing the meta value and returning the frontend html. I notice you phrase this as a theme development question, while the implementation here sounds more like something a plugin would provide. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot, that's very helpful. So the post template block - although I couldn't find any reference for it, do you maybe have a link? - sounds indeed like it can be used in the way "content template parts" are used in current php themes while the query block contains the custom query loop. Also thanks for the link to the post title block implementation of "conditional tags", also very helpful. As for your question about phrasing this as a "theme development question" - my custom themes usually incorporate a lot of what may be "plugin territory" if the functionality were intended to be used independently of the specific installation. Something they all have in common is custom queries for partly complex custom post types that serve as data containers. As explained in my op, I think a lot of the conceptual difficulties a lot of people (this is not from me, but a good example of the mood I'm referring to: https://dbushell.com/2021/08/03/wordpress-has-a-gutenberg-problem/ ) seem to have wrt to Gutenberg is that in Gutenberg, and fse in particular, the smallest queryable unit is still a post of whatever type. So for whatever query I want I need to access that post, and usually structured data attached to that post, not block attributes, while working with that structured data with block-encapsulated php is making things more complex without any apparent benefit. I can see the benefit of Gutenberg for creating free form content units, like I can see the (potential) benefit of any page builder for that reason. Yet despite thinking about it a lot, I cannot see any benefit (neither for the user nor the developer) of the block system (with encapsulated dynamic queries) over a simple form UI for use cases that require custom post/types with custom/fields as data container - except maybe a styled preview of a possible singular view in the editor. A lot of data containers don't even require singular views, so no benefit there at all, just less convenience. I know that php-themes aren't going to go anywhere in the near future, but I understand the firm commitment of the WP ecosystem to Gutenberg, if mostly for philsosophical reasons. But that creates the need to replicate my most common use case "Gutenberg style". Hence this question. Maybe others will chime in, too, so I'm leaving the question open for discussion, but again, thanks for a very helpful reply! |
Beta Was this translation helpful? Give feedback.
-
As is the case for a lot of blocks, the best place to look is unfortunately the source code: |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, better documentation would be great, but thanks for the link =) |
Beta Was this translation helpful? Give feedback.
-
Hi.
I hope this is a place to ask this question -
The introduction of the block-editor has made blocks the smallest data container, yet one that cannot be idenpendently queried and reassembled, at least not practically, as it's all markup in the post_content column. There's also no admin UI for accessing individual blocks independent of their container posts. So for all aspects that require querying, posts are still the smallest data container in WordPress.
In my mental example I'm trying to build a calendar page that consists of a number of individual data units I call "event".
a) in the non-Gutenberg/non-Block-World, I address the scenario with an event calendar page template that's using a post type called "event", which in turn has a lot of custom fields that hold the post meta. On the front end, a long list of events is output based on a custom query. This is a very common real world scenario.
b) In Gutenberg, it's easy to create a post/page and have a custom block/block pattern for each single event. I can easily create a list of, say, 10 "events" with the pattern, and then save the post/page with the gutenberg markup and display the list on the front page as a single page using the single post/page template. However, as soon as there are more than a handful of "events" it becomes cumbersome to add them as custom block/block-pattern on the page. Should I want to dynamically rearrange the displayed events based on meta data or just date posted, this becomes impossible in the above simple scenario, because the custom blocks/block patterns aren't individually queryable. A specific post type appears to be still necessary to allow querying.
What would be the best way to still allow queriable lists / loops of "events" in a Gutenberg-based theme/Block Theme?
For the input side I can see two options: A custom block or block pattern with a single locked block template for the still necessary "event post type" to input the event info, and ideally save the block meta data to the post meta table. The custom block would basically replace a post meta UI like ACF as input method. I'm not sure how quering by post data / meta would be handled in a scenario that would require the parsing of each "event-custom block" for each queried "event-post", but if the data is not avaibale in post meta, parsing the content of each "event block"-html within each "event"-post would would seem to be the only option to access that data and get a result set. In my intuition, parsing seems like a much more resource intensive operation than a db-meta-query.
For the output side I would either need a custom output query loop block that takes care of the query and dynamic rendering (and backend representation) or possibly use the query block if it supports the quesry structure I need for the calendar.
This kind of custom query is one of the most common current use cases in my WordPress installations. I understand that blocks saved in post_content is where WP is headed, so understanding what would be "the gutenberg way" to implement this kind of usecase would go a long way to help me embrace blocks as default.
Thanks for your ideas!
Beta Was this translation helpful? Give feedback.
All reactions