randompenguin

After getting the stylesheet to about 75% of modifying "Vier" I realized to actually fix some of the issues I need to just copy it and make a new theme based on Vier. It isn't that I can't do it completely with CSS, it just requires some really convoluted styling to get it to work the way I want. Which also means if you're using keyboard nav the focus jumps around because the elements are no longer being shown in the order they appear in the HTML code.

It's much easier if I can just rearrange the HTML so I don't have to have convoluted CSS. Another issue is that to get that nice 3-column layout in Vier it needs to be done with fixed positioning and negative margins. I can't use a flexbox on it because of the page architecture. But if I make a new theme I can create a custom layout that does let me use a flexbox. On top of that, Vier still uses server-side device detection that conditionally loads a "wide," "narrow," or "mobile" stylesheet. My responsive layout is sort of fighting against those. Lastly, Vier does not have a "schemes" folder like Frio. You can't just drop in a new sub-style and have it available in the theme drop-down. You actually have to hard code it into the theme options.

So the simpler solution is to just fork Vier and make a new theme that doesn't do server-side device detection or conditionally load stylesheets based on that, won't require anyone to hack theme files to add the option of this layout, and lets me customize the actual page architecture to make the layout work properly and the tab order to be correct.

This won't be as complex a customization as the "BookLook" theme I'd been working on, a lot of ideas from which are now baked into the core Frio code. This is just to get around some minor issues with modding Vier's layout to look more like Mastodon or Bluesky.

But it does mean I likely won't have this ready for people to try before the Release Candidate becomes the Stable version.

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

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.