We recently updated to 0.18.0 and I haven’t really had a chance to fully test it. I took a snapshot before the upgrade, so we have a working state to roll back to if need be.
Please do not hesitate to post here. Rolling back snapshots will cause us to lose new posts that took place after I took the snapshot.
Upvoting seems to close any expandos that are opened.
“I like this!”
Upvotes
It immediately disappears
“fuck”
Lol
“I like this so much I don’t want to see it”
ಠ╭╮ಠ👆
Huh… I’m not getting that… Try clearing your cache.
happens to me too
Still seems to be happening for me, on Firefox.
I’m on Firefox too. That’s weird… Anyone else lurking this thread can chime in and say whether or not you’re experiencing the same issue?
Happens to me too
Edit: with upvotes and with saves too
I’m seeing upvoting expanding expandos. if you press a minus on a child post to minimize it, then upvote a parent, it expands the child.
I do experience this too. Made a test account on a different instance that’s also 0.18.0. It does it there. So we’ll have to wait for a fix from upstream. I’m just glad this upgrade went smoothly. Though I have little worry because I do automated VM image backups/verification on the daily and do VM snapshots before a major upgrade.
Yeah this happens on me too. Don’t know if that’s the correct behavior.
Don’t know if it’s a new issue (or if it’s not an issue at all) but upvoting pops out the up-arrow and the number of upvotes and pops in a “loading sign”. That moves the ui a bit to the left (save, view source, more, buttons)
deleted by creator
That very well could be. Do you notice the site running slow too? Thinking it’s just me since nobody else complained about it.
I saw it running slow on some images, but then realized the image was a 4k image. I have had orange json toast before, and it led to a few seconds of the /error page
Yeah, that’s the sucky part about hosting your stuff internationally. Latency and throughput are severely diminished at certain times because of the vast amount of hops packets have to route through. I’ve got Varnish (cache server) running on the VPS which should mitigate “some” of it as far as images go. But that’s moreso to keep the reverse proxy on the VPS from having to request images all the way from my server box, thereby reducing latency some.
That being said, I’m glad the error page worked. It was @Disabled@burggit.moe 's idea. He coded up the html page (since I don’t know HTML at all) and I got it implemented on the VPS’s reverse proxy to intercept 500/502 errors and redirect to it.
deleted by creator
deleted by creator
Good to know. Thank you for bringing this up. I went on another instance and tested this and it appears to happen there too. So it’s an upstream issue and not something that I introduced when we upgraded, which is a great relief.
deleted by creator
I’m getting a problem where when I try to log in it says email verification is required, but I specifically didn’t connect an email to this. I went in and tried to attach a burner since I still have this login token up, but it says email isn’t supported on this instance. Help?
Guess it fixed itself
Did you try logging in via private session?
Try now. I went into the DB and toggled your email as “verified” I’m somewhat concerned because I don’t see anything wrong with your account.
Whatever happened, it ended up working fine. Thanks for actually being an admin that fixes problems instead of a reddit admin who problems what’s already good
Checking mod-removed posts on the modlog returns a couldnt_find_post error instead of allowing them to be seen. Not sure if this is intentional but that was a tool whose accountability aspect i liked.
Checking on multiple accounts on this and other instances, the modlog loads for us, though we can only click through to the removed posts on an admin account. Is your issue specifically with trying to click through to see a removed post, or is it when trying to load the modlog at all?
Here’s how the modlog currently looks when loading it on a test account (hidden under a spoiler for those who don’t want to see.)
click to expand.
Then when actually trying to click through to see a removed post I get the following error on the test account:
This is the same across multiple instances, which are on the latest version of lemmy. Which tells us this might be an intentional change specifically to prevent regular users from seeing offending content. There doesn’t seem like there’s any easy way to remove this restriction on our end as it seems to just be part of the lemmy software.
There does seem to be a new setting which is ticked automatically in the new update to hide mod names (probably to further reduce their accountability.) This, fortunately, is a setting, and we have unchecked it, so the names of the actual mods who did the actions should show up now.
Hope this helps!~
Doing a quick check on changes from 0.17.4 to 0.18, seems like the most probable culpirit are these lines from this commit.
It doesn’t look like these changes were intentional either. Seems like the intent was on making deleted/removed posts not visible to non-mods/admins/creators on community post listings, rather than not visible at all.
I’ve got zero experience with asynchronous rust (or rust, for that matter), but this doesn’t seem too hard to change (other than a potential distinction between removed and deleted posts). i’ll still need to figure out how to make sure the changes don’t break something else in the process, though.
Absolutely not. We don’t want to be opaque about anything when it comes to running this instance.
It seems to be working for me both when logged in and logged out. Tried clearing your cache? The UI was updated since the recent update.
tried on desktop edge (114.0.1823.58, amd64-windows, never ran outside InPrivate) and on a fresh install of firefox for android (114.2.0) and the error message is returned both when logged out and logged in on both browsers - either as a toast on a blank page when accessing from a hyperlink or as a full error page when trying to access removed posts directly.
testing was done on https://burggit.moe/modlog/30 -> https://burggit.moe/post/2475 and https://burggit.moe/modlog/123 -> https://burggit.moe/post/28404 [nsfw].
I misunderstood the question. @Disabled@burggit.moe addressed it. Sorry for the confusion.
Posting an extremely tall image (https://burggit.moe/post/84517) breaks webUI. the direct link to the image (https://burggit.moe/pictrs/image/186d3b6a-4b5d-4b97-85df-55f2f53f0700.jpeg) works, but webUI seemingly requests a webp conversion (https://burggit.moe/pictrs/image/186d3b6a-4b5d-4b97-85df-55f2f53f0700.jpeg?format=webp) which fails likely due to the dimensions.
I assume this is probably a deeper lemmy issue, but posting here on the offchance therer is something like a setting for a webp conversion size limit you could increase.
This is jpeg specific as far as I can tell