Skip to main content


Multiple Image Layouts



I'm working on fixing/changing the way #Friendica handles multiple images in a post for the next release. Yes, I'm using AI-slop images for testing purposes on my development server. My apologies to those who don't want to see that garbage.

Masonry Layout



When the backend PHP can get dimensions from the images it uses "masonry" layout. Which work well with even numbers of images but with odd counts of images it currently leaves the last one sort of dangling there by itself:

Current Masonry Layout

But I think most people would assume it should display like this:

Corrected Masonry Layout

Yes? No? It's a super easy fix if this is what people want.

I'm not yet sure under what circumstances the PHP cannot get image dimensions, but if that's the case then it doesn't use "masonry" layout, it switches to the "grid" template.

PHP Grid Layout (current)


PHP Grid Layout (current)

The PHP tries to figure out how many images to show in each column. These are hard-coded HTML column containers.

Pure CSS Grid Layout


Pure CSS Grid Layout

Of course CSS can nicely do columns itself now so there's really no reason to have PHP doing it on the backend. Obviously PHP and CSS don't agree on which images should go in which columns, but this is super easy to implement.

Literal Grid Layout


PHP + CSS Grid Layout

Though when someone says "grid" isn't this more what you are expecting? It doesn't get much more griddy than squares, right? This one uses a combo of PHP and CSS to display the images in a post in your feed similarly to how the thumbnails look in your photo albums.

You may have also noticed the "ALT" in the corners. That is there in the current version of Friendica, but it's just an indicator that an image has alt text, it's not a button like on Mastodon to actually show you the alt text. Well, that's how I ended up looking at these layouts, because I'm also implementing functional alt-text buttons for Friendica. Which means updating all these image layout templates.

Not sure if it will get sorted out for this upcoming release or not, but I'm also working on how to show you the "masonry" and "grid" layouts in the post/edit/comment previews too. THAT is quite a bit trickier because the previews do not use the actual image templates.

I'm interested in any feedback both devs and users want to give me on this. There is also a thread over on the Friendica GitHub if you'd rather comment there.

@Friendica Support @Friendica Developers
For me it is crucial that the dimensions are kept the way they are.

Concerning pictures without dimensions: I'm currently unsure if this is a only theoretical or really existing issue.
So then you don't care for the "Literal Grid" layout that crops them?

And in case it isn't clear, in the "masonry" layout with 3 images the dimensions of the third image aren't being changed, only the scale, to match the width and span the columns above it.
I don't like the cropping of pictures. But for me it's fine to change the size (while preserving the ratio) to improve the look.
@Random Penguin
So then you don't care for the "Literal Grid" layout that crops them?

I don't like that either; information gets lost because you can't tell that the images are being cut off. I'm in favor of always displaying images in their correct aspect ratio, and at most using CSS to adjust the layout.
@Michael 🇺🇦
@Random Penguin The three-image masonry layout should indeed display like the second version. This was the intention and I’m not sure why it doesn’t do that currently.

I’m also personally against the literal grid layout because it requires to open images to see them in their original format, which for a reason that will forever escape me, doesn’t work in iOS Add to Home Screen context, where both the Javascript AND the native click events are being fired, resulting in the image opening in the same virtual browser without any navigation controls, which forces me to exit the “app” and open it again.
Sounds a lot like what I've run into with legacy code that used JS to make the UI work on touch interfaces but when it's run in modern browsers that do a good job on their own of mapping touch input to desktop events, it causes it to fire both events.
@Random Penguin I’d be inclined to agree with you, but it only does this in this particular environment. Not in any mobile browsers I’ve tested, not in any desktop browser I’ve tested. To make matters worse, the Add to Home Screen feature caches dependencies heavily, so any changes in the code requires to delete the virtual app, clear the cache somehow by waiting an indeterminate amount of time, and adding the app again. At some point I threw the towel and I don’t touch images in my feed.

To note: it also fails with the New Post button but this leads to the Composer page (instead of just opening the jot) which has navigation, so it isn’t debilitating.
The masonry layout doesn't display like the second version because of this conditional at the top of the layout function:
if ($singleImageInRow = count($PostMediaImages) == 1) {
     $PostMediaImages[] = $PostMediaImages[0];
}


The array of images is run through both array_map and a "chunk" operation to split it into pairs. If the length of the chunk is "1" it duplicates the one image and lower down in the code gets the dimensions as if there were a duplicate of that image next to it. But the total count for display is still the original count of images so it never actually displays that image twice at the end.

Comment out/remove that conditional and the last image is scaled to span the columns above it.
@Random Penguin
It is essential that the aspect ratio in the preview is maintained. Cropping the images in the preview should not be the aim.
@Random Penguin
These examples clearly illustrate the effect that cropping the images has on the view.
It becomes unusable:
Friendica Friendica
Mastodon Mastodon
Okay everyone I get it. DON'T CROP IMAGES. The "Literal Grid" is out. Not doing it.

This is why I ASKED first. 😉