randompenguin

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

I was thinking of making a variant of this theme style that implements this idea, mostly to see how well it works and if people like it before resubmitting a PR to do it in all themes.

Hiding all the comments is easy via CSS. It's not quite as efficient as not generating them in the first place though. But the end result for the user is the same - no comments cluttering up their feed and making it super long in some cases.

Making the post body a clickable link that takes you to the post's single display page is also easy.

What I'm not sure of is how to handle the COMMENT button? The options are:

A. Hide Button so you have to click through to the single display page to comment.

B. Show Button and allow writing a direct comment to the OP in the feed (however, after you submit it the only way to see your comment is to click through to the single display view).

C. Button Opens Post - make the Comment button also click you through to the single display page (but then you have to click it again to actually comment).

None of these is an ideal solution. I'm favoring option "B" since all the other action buttons are available in the feed it feels like Comment should be as well. But I also realize it might confuse some people that they can't actually see their comment appear under the post. All they'd see is the engagement emoji count go up one.

Which option sounds better to you?

If neither "Smart Threading" nor "Compact Conversation View" are enabled you get the default layout for replies. I'm calling this "Flow Chat" because it's a bit like a flow chart for the conversation that, unlike simple thread lines or indenting, shows the relationship between the replies in detail:

Again, direct replies to the OP are separated by thick dashed lines, so you can see replies beneath them form separate conversations, with those replies separated by thin dashed lines. But the big difference are the bracket-thread lines. Second level are gray. Third level are blue. Fourth level are orange. Fifth level are green. Sixth level are red. Seventh+ level are purple. Friendica never indents anything more than thread_level_7.

If you compare the second conversation here to the "smart threaded" version you can see how this shows the actual relationship and depth of the replies, where "smart threading" does not.

For the aforementioned "Smart Threaded" option the replies under that depth test post would look like this with thick dashed lines between direct replies to the OP and thin lines and indenting for replies to replies:

The point of the "smart threaded" option is to reduce the amount of indentation. It accomplishes that by making any reply, at any depth, that has < 2 direct replies a thread_level_2 post (as if it were a direct reply to the OP). Once there are 2 or more replies to that comment its thread level changes and it starts indenting.

However, that purposely completely breaks the relationship of replies to replies that have fewer than two direct replies. Nothing I can do about that. That's how it intentionally works.

If you enable the new "Compact Conversation View" option, which only shows comments by the current user and the OP, whether "smart threading" is also enabled or not, this is the layout used.

I'm still working on this layout but haven't tackled the mobile version yet. I got sidetracked trying to make post replies look and work better. One thing that annoys me is that the engagement count for comments only shows the number of direct replies to the post instead of the total of all replies. So I've been thinking of at least adding a counter for how many total replies are downloaded/visible:

I think you only ever see that button with the full comment count if you enable "smart threading." My downloaded number is done entirely with CSS counters and only appears on a post that has at least one reply. It dynamically updates if you press the button to load more comments. I would prefer an option to just show the total reply count in every thread view mode, but it doesn't just hide that "16" it doesn't even create it in the other views. So the best I can do is a count of how many are currently downloaded and visible.

@leanderlindahl

Another thing i struggle with is – it seems you dont get notified when someone interacts with your posts (likes, replies). You find out by accident or not at all.

Did you ever change this setting?

@leanderlindahl "Compact Conversation View" was explained to me as only displaying comments that are:

• a direct reply by the author to their own post
• a direct reply by the reader to a post[/i]

My proposal won't even show those. It hides all replies in feeds. Mine also makes the post body into a clickable link to the single post display page (which shows all the replies regardless of either setting).

I retracted my PR for this. It won't be in the next release of Friendica. It conflicts with the existing "Compact Conversation View" feature which hides all other comments except your own interactions with a post author (or something like that), where mine literally hides ALL comments under the post and requires you to click the post to read it on a separate page that shows all the comments.

There were questions of whether there is demand for a feature to make Friendica feeds work the same way as Bluesky and Mastodon? And whether being able to write a comment to a post in the feed, but _not_ see it get added under the post in the feed is too confusing, and whether commenting in the feed should be completely disabled, or on submission should it take you to that post's single page where you _can_ see your comment? Which will take a little more work to figure out to make it do that.

So I'll probably do a post/poll on that question and if there's enough interest I'll resubmit the PR for the _next_ version. We can probably put both options in a dropdown so you can't enable both of them at the same time.

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

While trying this out I've decided I'm going to submit a PR that offers "Hide Comments in Feeds" as Settings > Display option for ALL themes (turned off by default of course).

People who want a really compact feed will love it. People who don't like extra clicks will hate it. But nobody has to use it if they don't want to.

In every feed all of the comments are hidden. But you click on the post body and it opens the post in its own page, only there it will actually show you any comments under it.

This is exactly how the web UI of both Mastodon and Bluesky work so it is a UX with which many users will already be familiar.

The trick is making sure that all the other stuff in the post still works as expected. The contact links in the post header. The (re)action buttons below. Commenting without having to first open the post in the single display page.

The only thing I don't like is that it literally just hides the comments in the feeds. It's still going through all those loops creating them. But the same loop creates the top post too and while the templates are context-aware if they're being rendered in a "display" page or not, the backend is not. So it's not quite as efficient as it could be. Maybe I'll figure out that backend part. But right now on my Dev Server I've got this working perfectly across all the themes.

Now, if I can just get all these PRs I've been working on submitted...

Curious whether people would want this theme style to work like Bluesky/Mastodon where:
* The main feeds only show you the actual posts and none of the comments
* You click the post body to open that post in a new window by itself with all its comments

It would require adding a couple invisible elements to a Vier template to pull it off, but I don't know if people like the way Bluesky and Mastodon make you go to a new page to see the comments or if Friendica users would want that?

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