Changes to `wide_assets` and `documents` post metadata
reefdog opened this issue · comments
When a post is saved, we store a couple pieces of metadata:
documentclouddocumentsstores all the shortcode attributes. I don't know what it's used for.wide_assetsset totrue|falseto hint to the template that the post contains, well, wide assets. Several StateImpact sites respond to this hint according to #16 (comment) and a Hangout conversation with @eyeseast
We have to make at least one change: both pieces of metadata are stored as hashes keyed by document slug. But now that we support notes – which are children of documents and thus whose URLs contain the document slug – we can have two embedded resources on the same post with the same hash key.
My recommendation:
- Determine if
documentclouddocumentspost meta is necessary (@eyeseast?) and if not, remove it - If resource is a note, include note ID as part of hash key to distinguish from documents.
Sorry; the first bit of metadata is documents, not documentcloud.
So, realized that no matter how many embeds are on a post, only one documents and wide_assets gets created, keyed by the last embed. (Note how the update_post_meta() calls are outside the foreach() loop in save().) Which means we don't have to worry about colliding IDs, because only the last man standing is saved anyway.
Is this by design?
The idea with wide_assets was that it only needs to be set once per post. It's a boolean, there's either something wide or there isn't, and having anything wide in the post means it needs to deal with that.
I'm trying to remember what the $documents key was for. It's an array, so it makes sense that there's only one, but I can't remember why we were saving it. Maybe just because we could. (This was four years ago now.)
I'm inclined to remove documents unless we can figure out its purpose. What do you think?
Grokked on wide_assets.
I think it's fine to dump $documents.
that seems ok to me too
Cool. I'll remove.