Communikitchen

Big ideas about the web.

Building a Flickr replacement – Part 1, amended

Some things have changed since I posted Part 1 so many months ago. I wrote:

I’m still not sure if using Paragraphs the way I did is ideal. While it does make metadata Views-friendly, the fact that metadata labels are stored as text fields isn’t as slick as I’d like it to be. That’s also why I haven’t spent too much time refining the display of metadata.

I since then decided that storing image metadata as paragraphs wasn’t cutting it. Paragraphs made filtering and sorting my views too complex, and although the data structure was slicker it wasn’t worth the performance loss. It also became clear that I didn’t really need most of the metadata the system was saving automatically, and I could easily narrow it down a few essentials.

I converted the few datapoints I needed (creation date, geographic information, shot metadata) to field attached directly to the media entity, each appropriately typed, and got rid of everything else. Ultimately, each original file still retains that information, so I should always be able to retrieve additional fields if I ever need to.

Because metadata handling was the only spot that used the Paragraphs module, I was able to remove it from the system completely. That was a relief all in itself.