Gallery support

[flamingos-cant]

Closes #981.

Galleries are a collection of images attached to a post. I wanted to have galleries reside within Post itself, but I couldn't work out how to do that, so they're just a top-level vec on PostView, basically a copy of how post tags work in #4997.

This doesn't introduce any API breaks, but there is some weirdness as Post's can now have a url_content_type but no url. This is so media filter setting excludes gallery from feeds where that's set.

On the AP side, galleries are just federated as multiple attachments. Also, Image attachments now have mediaType, to prevent every server having to fetch the content_type for all the images, and summary, to handle captions.

Things left to do:

• Tests (API/unit)
• Doc strings where needed
• Generate thumbnails for gallery posts
• Create wrapper structs so that galleries are passed to plugins along with the post
• Delete/purge galleries along with posts
• Limit the number of items a gallery can have (probably ~25)
• Maybe find a way to include gallery's alt_text in search (ref Include image alt text in post search #5449).

[Nutomic]

It doesnt make sense to duplicate existing post.url values into the gallery table. However we could consider getting rid of post.url entirely, and relying on post_gallery for all links, but that would be awkward for non-image links.

[dessalines]

This is the correct way to think about it. Posts would now not be a single link, but be a list of links, and have a post_link table that references post_id .

It would support not just images, but any kind of links. In the UIs we could add a button for more links after adding one.

[flamingos-cant]

Oh sorry, this is code from a pervious revision I forgot to remove.

I'm personally not sold on the utility of allowing multiple non-media links on a post. That feels like the kind of thing better left for the post body.

[dessalines]

Agree that it doesn't make too much sense, but IMO we might as well be flexible if the work has to be done anyway.

Columns like embed_video_url, url, url_content_type, thumbnail_url, alt_text all need to get moved to a new post_link table anyway, so it'd be easier to treat all the links equally, rather than do special cases only for image links.

[flamingos-cant]

I'm still against it tbh, I'd prefer to keep the post gallery and url separate and I struggle to see a scenario where 20 links to different web pages is anything but spam, but I'll defer to yous on this.

[Nutomic]

We can still have code in the api which prevents having more than a single link unless media type is image.

[flamingos-cant]

OK, so I've done the DB changes to move links out of Post, but I just want to confirm before I do the changes the API that some fairly major API breaks are acceptable here. If I press ahead, a post will look something like this:

{
  "post_view": {
    "post": {…},
    "links": [
      {
        "url": "example.org"
        …

[Nutomic]

Makes sense.

[Nutomic]

Why add caption when theres already alt_text? And if page is for ordering it should have a clearer name. updated seems unnecessary.

[flamingos-cant]

A caption is a short title-like piece of text to go along with the image, while alt_text is meant to be a replacement for the visually impaired. Reddit's galleries include captions and always thought they were a neat addition, so included them here.

I'm not happy with page either, but I couldn't come up with anything better. Index, maybe?

[Nutomic]

Something like index or sort_order. I suppose the caption makes sense, but also alt_text is missing a max length.

[Nutomic]

This doesn't introduce any API breaks, but there is some weirdness as Post's can now have a url_content_type but no url. This is so media filter setting excludes gallery from feeds where that's set.

We could set content type to image/gallery in that case.