Making the upload files available at the time Hugo is running isn’t possible right now. Sometimes the images are there, for example when you click the “Rebuild” button on the logs page it brings everything together including all images. But as an optimization, Micro.blog frequently recreates the Markdown files and runs with no images present, since they have already been uploaded to the static servers that host the blogs.
It’s a little out of date (things are even better now!) but long story short, we currently run Hugo on 3 servers and randomly pick one, so there would be overhead to having all images on all servers at all times for all users. Mounting from a remote server would also potentially create another single point of failure which we try to avoid. This might be too much information, but maybe it helps explain why it currently works this way.
Back to the real issue… When an image is uploaded, we do store the width/height in a separate database, so we have the data. The Micro.blog apps also usually include width/height attributes in HTML.
One thought I had is that I assume this data is most valuable for the “Photos” page, so perhaps more metadata could be made available to that page only, without affecting much else.
But it involves some knowledge of CSS and Flexbox. The code for the current version is available on GitHub. It’s a large flex container where the child element have a fixed height (in my case 40vh) and an “auto” width. Since we’re using flexbox we can allow these children to “grow” to fill all available space. And finally, we set the “object fit” property to “cover” so that the images gets cropped rather than stretched when the elements are resized.
And if you want to inspect the final result. You’re more than welcome to inspect the source code at my website: johanl.se.
Thanks a lot but I don’t think I know enough CSS and Flexbox to make sense of it but it looks really nice on your website. I was wondering how I could edit the default MB template (layouts/_default/list.photoshtml.html) to get that layout.
I’ve rolled out a change inspired by @kottkrig’s feedback. In the front matter, there is now a new “photos_with_metadata” with 3 fields: “url”, “width”, and “height”. I haven’t done much with this yet other than to confirm it’s working, but hopefully this opens up some more custom theme and plug-in possibilities.
By using the new width and height properties I finally got rid of the jankiness during initial page load. And as a bonus, it also fixed a lingering Safari layout bug where the image sizes wouldn’t update properly in the flex layout.
Excellent, that looks great! I’ll try to work something like into the Masonry plug-in I was experimenting with. If you want to share more about how you did this, I’m sure folks would be interested!
I wanted to mention one other thing because I myself had forgotten it works this way. Micro.blog gets the width and height for a photo when updating the timeline, so it’s possible in some cases that the values will be temporarily set to “0” until the timeline updates. This also makes testing with a -test blog more difficult because that feed is unlikely to be set for the timeline. I’ll look into improvements later to remove this limitation.
I’m planning on writing an announcement post on my blog but until I come around to it: Here is an attempt at bundling the photo grid as a Micro.blog plugin.
It’s been tested and verified to work with the Marfa theme but should hopefully work with other themes as well.
This is awesome! Going to try it now. Do we have to remove any code from the default list.photoshtml.html page first or will it override any code that already formats it a certain way?
That’s right, the width and height are currently set for posts that appear in the Micro.blog timeline, so it doesn’t work for test blogs. I’m looking into removing that limitation.
Great. It worked perfectly on my main blog which uses a custom theme but strangely doesn’t work on my photos blog which is a customized Kiko theme. Thanks a lot for creating this plugin.
