Dynamic galleries and media attached to a post

[mtias]

This is an overview issue for a series of improvements we could do to the media publishing flow, particularly to the "media attached to a post type" path.

Media Inserter

The media tab on the main block inserter is quite underutilized. I propose we display the images attached to the current post directly in the sidebar surface, with a similar thumbnail display to the one we use on the “external media items” for the pre-publishing flow. There’s a few mechanics that this grid view could support — insert a gallery with all the images; add / detach images from the post; drag a single item into the canvas to insert as a block or set as a cover background. cc @ellatrix since we discussed some of this for the external media work.

Gallery Block

It’s due time to support a dynamic toggle in the gallery block so that we mimic the behavior of a [gallery] shortcode with no image ids set and dynamic rendering. This should support sorting features like reverse order, random order. Once toggled, it should be super clear to the user how it works.

Shortcode

I believe we already convert a gallery shortcode properly on a "convert to blocks" pass, with some exceptions for plugins extending the older gallery system. However, we can handle a gallery shortcode from classic content flow better. For example, in the shortcode block we could offer a “convert to gallery block” shortcut.

[andrewserong]

I propose we display the images attached to the current post directly in the sidebar surface

To adequately implement this, I believe there'll be a few aspects to have the "attached to" behaviour works that we'll want to refine, too. For example:

• Image Block: When adding an existing image within a post, explore "attaching" the image to the post if it isn't already attached #66663

It’s due time to support a dynamic toggle in the gallery block so that we mimic the behavior of a [gallery] shortcode with no image ids set and dynamic rendering.

This would also be an excellent feature if and when we add categories, tags, or folders for media in core, too. Just linking a relevant (old) core ticket:

• Extended file management in Media Library: https://core.trac.wordpress.org/ticket/47839

This would allow dynamic gallery blocks linked to tags or categories, e.g. "My holiday to Australia", then the user could upload media directly to the media library, tag appropriately, and the images would automatically show up on their post or page.

[ramonjd]

I propose we display the images attached to the current post directly in the sidebar surface

Critical to this is coming up with a performant way to track relationships between attachments and posts.

A dedicated pivot table has been proposed in the past (16 years ago)

• https://core.trac.wordpress.org/ticket/14513
• https://core.trac.wordpress.org/ticket/10657

We should be realistic about this given its nearly 2 decade long "too hard" status. If we propose something like this, please let's be open and pragmatic about the scope.

[ramonjd]

Critical to this is coming up with a performant way to track relationships between attachments and posts.

Or not. If we accept the limitations of the single parent field in attachments, but I think the queries could be heavy 😅

[ramonjd]

See also this trac ticket:

• return list of images actually being used in post #16349

Similar situation: all closed as "won't fix" or "plugin territory"

Might need a wider discussion, or we can attempt to narrow the scope

[andrewserong]

I propose we display the images attached to the current post directly in the sidebar surface, with a similar thumbnail display to the one we use on the “external media items” for the pre-publishing flow.

For this idea, just sharing a visual reference for the grid in the right-hand sidebar in the pre-publishing flow:

So I guess the idea to try here might be to display a panel beneath the media categories that contains the grid of images already contained in the post? I.e. in the white area here:

Something to consider is what to do for posts that contain a very large number of images (speaking for myself I'll often write travel blog posts with > 60 images for example). Anyway, just something to explore. And for the technical side of things:

• Are we showing only "attached to" or also images that have simply been added via image blocks?

[ramonjd]

So I guess the idea to try here might be to display a panel beneath the media categories that contains the grid of images already contained in the post?

That's what I'm understanding too. Thanks, @andrewserong! And (one of your ideas) it'd be a nice touch to include pagination in the inserter anyway (maybe some sort of simple data view sorting?).

Are we showing only "attached to" or also images that have simply been added via image blocks?

For the 7.1 features (inserter sidebar, dynamic gallery), I agree, let's decide on which definition of 'attached to this post' matters most.

I jumped ahead a bit with my concerns about the many-to-many relationship. Sure, it's the ideal state, and probably most performant and accurate, but we don't have to start there to make improvements here.

For now, we could accept the one-parent limitation and see how far we get.

For "show me images that were uploaded/first-attached here", we might need a custom query or endpoint with cached results, e.g., very naively

SELECT * FROM wp_posts 
WHERE post_parent = {post_id} AND post_type = 'attachment'

if we want to be accurate.

For queries like "show me every image referenced in this postis content", we could fall back to content parsing as you say.

Whether we prefer one or the other, I'm not sure. Perhaps could start with the latter.

You're right that we could improve Gutenberg by setting post_parent when inserting existing media (matching Classic Editor) in #66663.

I was snooping around and I think there's a chance to fix attachment orphaning on post deletion as well.

https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/post.php#L3898

This sets orphaned attachments' post_parent to the deleted post's own parent. For a child page's attachments, they get reassigned to the grandparent page, I'm not sure that's right.

[andrewserong]

For "show me images that were uploaded/first-attached here", we might need a custom query or endpoint with cached results, e.g., very naively

Isn't this already handled in the media endpoint via the parent param, or were you thinking we might still need something custom? I.e. given a post id of 165 where I've uploaded some images locally, this endpoint appears to work for me: http://localhost:8888/wp-json/wp/v2/media?parent=165

[ramonjd]

Isn't this already handled in the media endpoint via the parent param, or were you thinking we might still need something custom?

Blow me down. I had my head in the clouds thinking about post <=> attachment relationships, managing deletions and just overthinking it completely.

Thanks for setting me straight. 🚀

[andrewserong]

No worries!

I had my head in the clouds thinking about post <=> attachment relationships, managing deletions and just overthinking it completely.

It's still important stuff to consider. There's some old and not straight-forward logic baked into how the attachment relationship works in core, and in the block editor this has mostly been hidden up until now. I think exposing it is a good opportunity to carefully consider how well it's working. It's a good idea for us to try out prototypes enabling this stuff, but at the same time to put any prototypes through their paces to make sure we're building flows that work.

Your digging into trac tickets reveals (IMO) that the existing behaviour has lots of limitations. I'll be curious to see if what we have (or can build) will feel good enough in smaller increments, or if it will require that deeper dive of managing relationships. I'm sure we'll find out!