-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Description
I've been thinking about the best way(s) to handle parsing and data storage, which I think will end up being pretty closely related. This is important for us to get right so that we build a solid foundation for other plugins.
I'll start with one of the things that annoys me about WordPress: settings for shortcodes like [gallery]
. We see the list of IDs in post_content
, but what about the other settings? A lot of them are missing, stored along with the attachment post, and I think there are a lot of cases where settings are stored in post meta as well. For a concrete example, if you want to use the same image on multiple galleries, with different captions, AFAIK this is impossible because the caption is stored as a property of the image only.
I don't know all the permutations of how this works currently, but it's a mess and I shouldn't have to care. I should be able to take whatever appears in post_content
for a gallery block, paste it to another post or another location in the same post, and everything should "just work".
I'd really like to avoid repeating this set of mistakes from "classic" WordPress. If we're storing data in post_content
, let's store all the data in post_content
. If we can also ensure that we serialize block information to semantically-meaningful markup, this will have a lot of other benefits:
- We get most of the functionality needed for server-side rendering without any extra effort
- Importing and exporting content between posts/sites is much easier
- We don't have to worry about the link between blocks and their settings; this would be difficult to manage in cases like duplicating blocks or rearranging their order
- We avoid changing "global" state outside of a post content which can have unintended effects