randompenguin

@heluecht @capitan What's specifically bad about it is that there is no way to manage the files. If you accidentally upload the wrong video you can't delete it if you're a regular user. You'd have to ask the server admin to delete it for you. There's no way to set permissions on the files. It also has a tendency to fail on upload with larger files, even when they're under the file limit set by the server admin.

I spent a while digging through the code trying to add a button to the file browser so at least users could delete a file, and while I think the code to do that exists on the backend, I could never figure out how to access it and gave up.

@utzer I think I fixed it! The screenshots below are from the Release Candidate (2026.08-rc). One of the changes to masonry layout is that if there's an odd number of images the last one now spans both columns.

As I said, by the time the array of images was getting to the masonry layout they were already in the wrong order, even though they are still in the correct order in the stored post content. It's because the functions to get the images don't go by the post content, they do a relational database search of the "post-media" table looking for rows that match the post UID number. And that is how the array of images is constructed.

Except it isn't given any sorting parameters. I couldn't figure out what the default sorting actually is, but it should be in ascending order of media ID number - because that is the same as the order the attachments are in the post body content. So I simply added those sorting parameters to the database query and now the images are in the correct order.

I'll be submitting a PR for this tomorrow to fix it in the Release Candidate.

@utzer I don't know, I can't find any rhyme or reason for what order it puts things in.

Here is how my Dev Server running Friendica stable (2026.05) arranged them:

Which is different from the order you got for the same images.

And here is how my Dev Server running Friendica Release Candidate (2026.08-rc) arranged them:

But if I got to "Edit" either of those all of the images are attached in the correct upload order. If I preview it in the Release Candidate my jQuery masonry simulation shows them in the correct order.

If I purposely disable masonry layout to make it use "Grid" layout they are, again, displayed in the wrong order! This is because the "Post Media Collection" array used by either masonry or grid layout has already had the order altered before it ever gets there. I've traced it back through several other files and it's already in the wrong order.

As I said, I have no clue yet WHERE it is changing the order or WHY.

When the post is federated to another platform that other platform is working from the order the images are attached to the post body, which is not getting changed by Friendica. Like I said, if you go to edit it, if you quote share it, on Friendica the order will be correct. It's only be altered when it displays the published post in Friendica.

I'll keep poking around in the code and hopefully I can find and fix it, but right now I'm not sure where else to look.

@utzer I don't think it has anything to do with the original filenames, or for that matter the order you uploaded them. They are supposed to appear in the order you attach them to your post.

But that is not happening. If you go to edit the post you'll see they are attached in your preferred order, they just aren't getting displayed that way in Friendica. And it's not the masonry layout function that's changing the order. The "Post Media Collection" array is already re-ordered before it ever gets to the masonry layout code. It's actually getting changed somewhere before the PostMedia code too. But I can't figure out where the order is being changed or why.

In the Release Candidate I added code to the post composer preview to show the masonry layout, but it has to use jQuery on the frontend, not the actual masonry code from the backend. Ironically my "simulation" of the masonry layout for the preview shows the images in the correct order while, after publishing, the actual masonry code does not.

@utzer On my end it looks the same as your screencap:

So it's not just on your server, it's coming through to the one I'm on that way too.

The quote share in your post above, however, doesn't use the masonry layout and shows the images in a linear column in what you said was the upload order.

@vegos_f06 There isn't any setting for default dimensions but server admins can set the file upload size limit, that will be what determines how large an image you can try to upload (if it's extremely large the server might still time out before it finishes uploading). Server admins can also change how Friendica stores uploaded images. The default is to store them in the database, but that can quickly make the database grow, so there are other options. However, none of this is in the hands of the user.

You can also place external images in your posts, assuming the site you're pulling them from allows hotlinking. Friendica will try to generate a local preview image for it (though I've personally found this very hit-or-miss).

The masonry layout works with images that have different aspect ratios. The aspect ratios and the order you put them in your post have more to do with the layout than anything else. If they're all the same size and aspect ratio they'll likely layout in a grid naturally.

As for the actual "grid" layout in Friendica, we're still trying to determine if it every actually gets used. It's only used if Friendica can't get the image dimensions, but it's unclear if/when that ever happens.

@vegos_f06 I'm working on addressing this for the next release. There are some strange conditions that will prevent it Friendica from showing a gallery that I have not figured out how to address:
1. Do not put ANY text *after* your photos.
2. Do not put any text *between* your photos.
3. Do not put any line-breaks/carriage returns between your photos.

It pretty much has to be an uninterrupted set of photos with no spaces or anything between them. Or it will break the gallery layout. It happens so often for people that I'm also doing a workaround to sort-of gallery the images anyway, even Friendica won't put it in a gallery.

I'm also working on making the post preview show you your images as a gallery too. Right now it only shows them full-width one after the other. So you have no way of knowing if you've done something to "break" the gallery layout or not until you've already posted it.

Here's the GitHub thread about it:
github.com/friendica/friendica…

I'm still trying to get my PR together for this. I'm also adding functional ALT tags to images and previews in the post composer.

@fossfan FYI, Bookface has a Wiki: gitlab.com/randompenguin/bookf…

There is also a new release of Bookface today: gitlab.com/randompenguin/bookf…

This is for 2026.05, 2026.01, and 2025.7-rc. It doesn't work with older versions of Friendica. And there is no Bookface for 2026.08-dev yet.

Okay everyone I get it. DON'T CROP IMAGES. The "Literal Grid" is out. Not doing it.

This is why I ASKED first. 😉

@hypolite 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.