When re-running the first cargo clippy command in fix-clippy.sh, the build time of db_views is now 311.1s instead of 1281.9s

Helps with #3610

When re-running the first cargo clippy command in fix-clippy.sh, the build time of db_views is now 311.1s instead of 1281.9s

Helps with #3610

Requirements

• [X] Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support
• [X] Did you check to see if this issue already exists?
• [X] Is this only a feature request? Do not put multiple feature requests in one issue.
• [X] Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.

Is your proposal related to a problem?

In the web UI, when visiting the /communities page, I would like the ability to sort by clicking the column headers. I believe this may be a backend issue, though, as I can't seem to supply any sort values in the API call to /community/list that have the effect I want.

I have never written any Rust before, so feel free to tell me I have no idea what I'm talking about, but it would appear that the sort URL parameter just gets passed straight to the query builder. This request type is defined here as a SortType, which is defined as an enum here. The values in that enum do not correspond to much of the data in the counts section of the /community/list response, making me think the sorting is ultimately ignored.

Furthermore, if I query the server with &sort=Hot one might think that the results would be sorted by their hot_rank, but this does not appear to be the case.

Again, if I'm off base here, please point me in the right direction.

Describe the solution you'd like.

Seems the solution is to implement listing communities sorted by various count values in the API, then to expose the new sorting features through the lemmy-ui project.

Describe alternatives you've considered.

I have used the tools at https://lemmyverse.net/ to get to the data I want. There I can filter down to my instance, view its communities, and sort by things like subscriber count and activity and so on.

Additional context

No response

Requirements

• [X] This is a feature request and not a bug report. Otherwise, please create a new bug report instead.
• [X] Please check to see if this request (or a similar one) already exists.
• [X] It's a single feature. Please don't request multiple features in one issue.

Describe the feature you'd like

What the title says, there should be a button that lets you switch to light mode because Lemmy's dark mode doesn't look good. There should be more contrast between posts and the body. Either make the body's background color darker or the posts background color lighter.

You should also make the navbar's color lighter because grey on black doesn't look good.

If a post's content is an image then the post should be larger so I don't have to open the post on another tab. Basically, posts should be larger, just like Reddit's posts on the redesign.

I created Japanese translate README. prettier -w ... has already been executed.

Re-opening of #3221.

Requirements

• [X] This is a bug report, and if not, please post to https://lemmy.ml/c/lemmy_support instead.
• [X] Please check to see if this issue already exists.
• [X] It's a single bug. Do not report multiple bugs in one issue.
• [X] It's a frontend issue, not a backend issue; Otherwise please create an issue on the backend repo instead.

Summary

I don't like the way the website looks, just because I've set my OS to use dark mode doesn't mean I want lemmy to activate dark mode by default, its dark mode doesn't look good. Posts should have a border just like reddit posts do, that way they'd look better, and you should also make the website's background color darker

Steps to Reproduce

Open the website, look.

Technical Details

Windows 11, Google Chrome.

Lemmy Instance Version

BE: 0.17.4

Lemmy Instance URL

https://lemmy.world/

This is a branch I have been working on to optimise performance of the woodpecker CI using a drone cache plugin & some changes to the clippy step. This branch in its current state will not pass, as there requires some ancillary services.

What this PR does is two things:

• Adds in a cache restore and publish step, using a local minio instance to store/retrieve the cache. Currently the following folders are cached & restored each run:

  • target/
  • .cargo/
  • api_tests/node_modules

• Adjusts the cargo clippy step to run once only with all lints present. To acheive this, in test modules the unwrap_used and indexing_slicing are turned off (hence the many changes).

Testing on my own woodpecker instance, with a warmed cache, the CI run takes <8mins:

!image

For the cache there are two methods available for storing/retrieving the build cache between runs:

• Use an S3 compatible object store, i.e, minio or actually amazon S3. I've been using local minio instance to test & have include a docker-compose.yml. If this is the path that people want to take, then I would suggest having it fairly close, if not the same host as the woodpecker ci.

• Use a volume mount cache. This unfortunately requires that the project settings needs to be set to trusted, which I'm not sure the ramifications of it are.

Here's the docker-compose.yml I've been using:

```yml

docker-compose.yml

version: '3'

services: woodpecker-server: image: woodpeckerci/woodpecker-server:latest ports: - 8000:8000 volumes: - woodpecker-server-data:/var/lib/woodpecker/ environment: - WOODPECKER_OPEN=true - WOODPECKER_HOST=${WOODPECKER_HOST} - WOODPECKER_GITHUB=true - WOODPECKER_GITHUB_CLIENT=${WOODPECKER_GITHUB_CLIENT} - WOODPECKER_GITHUB_SECRET=${WOODPECKER_GITHUB_SECRET} - WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET} - WOODPECKER_ADMIN=cetra3

woodpecker-agent: image: woodpeckerci/woodpecker-agent:latest command: agent restart: always depends_on: - woodpecker-server volumes: - /var/run/docker.sock:/var/run/docker.sock - agent-cache:/cache/ environment: - WOODPECKER_SERVER=woodpecker-server:9000 - WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET}

minio: image: minio/minio ports: - 9000:9000 - 9090:9090 command: - minio - server - --console-address - ":9090" environment: - MINIO_ROOT_USER=testing123 - MINIO_ROOT_PASSWORD=testing123 - MINIO_VOLUMES=/mnt/data volumes: - minio-cache:/mnt/data

volumes: woodpecker-server-data: agent-cache: minio-cache: ```

Requires https://github.com/LemmyNet/lemmy-translations/pull/80

This user option will make it not add posts to the read posts list to not save a browsing history for this user.

When disabled, it will delete all existing browsing history.

Description

Fixes #3500 mistakenly filed on the main repo by simply adding a sort dropdown to /communities using the existing SortSelect element. The right-justification of the search bar is preserved and the default sort is still TopMonth. The one issue is that the question mark should link to an explanation of community sorting, but the linked page on join-lemmy (03 Votes and Ranking) only talks about post and comment sorting.

The functionality for sorting communities is already present in the API, so this feels like a no-brainer once join-lemmy is updated, which I'm happy to do as well if it needs doing.

Also, just a minor note, this also fixes a small inaccuracy where the bottom margin for the selector row (.mb-2) was applied to the search bar instead of the entire row, which only acted correctly because the containing row was set to justify. The screenshots were taken before this fix so there's a few things off by a few pixels, but nothing really noticeable.

Screenshots

Examples using lemmy.world (mobile screenshots taken using emulated 335x667 display on Firefox):

Before

!image !image

After

!image !image !image !image

This PR is meant to address 3290

This fix checks if there is a local_user then returns posts that are not deleted/removed or posts made by the user.

Should fix issue #3588 and https://github.com/LemmyNet/lemmy/issues/3535 that were introduced on June 23 commit https://github.com/LemmyNet/lemmy/commit/dce79b83bfe4eddbe94a4b3846bc20624ef8e4c4

Currently, hot ranks are only updated in our scheduled tasks for content up to a week old. This means that if content older than a week has not decayed to a hot rank of 0 yet (or if for some reason initial hot rank calculation does not work on an incoming old post, like in #3428), this content will not have its hot rank updated until Lemmy is restarted.

This PR aims to speed up the hot rank updates so we can stop limiting the scheduled task to only the past week.

Basically, this is a small tweak to the hot rank update query - it no longer updates rows where the hot rank has already decayed to 0. This significantly speeds up the whole process, as the update itself seems to be quite expensive. Here are some query plans for a batch of 1000 old rows:

Current main branch query ``` Update on comment_aggregates a (cost=50.33..2667.91 rows=1000 width=38) (actual time=0.840..216.193 rows=1000 loops=1) CTE batch -> Limit (cost=0.43..49.91 rows=1000 width=18) (actual time=0.026..6.813 rows=1000 loops=1) -> LockRows (cost=0.43..48479.60 rows=979788 width=18) (actual time=0.026..6.693 rows=1000 loops=1) -> Index Scan Backward using idx_comment_aggregates_published on comment_aggregates a_1 (cost=0.43..38681.72 rows=979788 width=18) (actual time=0.015..5.817 rows=1000 loops=1) Index Cond: (published > (now() - '10 years'::interval)) -> Nested Loop (cost=0.42..2618.00 rows=1000 width=38) (actual time=0.810..211.210 rows=1000 loops=1) -> CTE Scan on batch (cost=0.00..20.00 rows=1000 width=32) (actual time=0.032..7.533 rows=1000 loops=1) -> Index Scan using comment_aggregates_pkey on comment_aggregates a (cost=0.42..2.35 rows=1 width=26) (actual time=0.159..0.159 rows=1 loops=1000) Index Cond: (id = batch.id) Planning Time: 2.284 ms Execution Time: 216.383 ms

```

Optmizied query in this PR CTE Scan on batch (cost=2480.28..2500.28 rows=1000 width=12) (actual time=0.027..6.247 rows=1000 loops=1) CTE batch -> Limit (cost=0.43..49.91 rows=1000 width=18) (actual time=0.023..5.944 rows=1000 loops=1) -> LockRows (cost=0.43..48479.60 rows=979788 width=18) (actual time=0.022..5.860 rows=1000 loops=1) -> Index Scan Backward using idx_comment_aggregates_published on comment_aggregates a (cost=0.43..38681.72 rows=979788 width=18) (actual time=0.015..5.316 rows=1000 loops=1) Index Cond: (published > (now() - '10 years'::interval)) CTE updated -> Update on comment_aggregates a_1 (cost=0.42..2430.37 rows=0 width=0) (actual time=3.219..3.219 rows=0 loops=1) -> Nested Loop (cost=0.42..2430.37 rows=247 width=38) (actual time=3.216..3.216 rows=0 loops=1) -> CTE Scan on batch batch_1 (cost=0.00..20.00 rows=1000 width=32) (actual time=0.008..0.303 rows=1000 loops=1) -> Index Scan using comment_aggregates_pkey on comment_aggregates a_1 (cost=0.42..2.35 rows=1 width=26) (actual time=0.003..0.003 rows=0 loops=1000) Index Cond: (id = batch_1.id) Filter: (hot_rank <> 0) Rows Removed by Filter: 1 Planning Time: 0.270 ms Execution Time: 9.584 ms

----

As you can see, the optimized query runs an order of magnitude faster. On lemm.ee, with this change, the scheduled task is fast enough to process hot ranks for all history in less than 30 seconds now. As a result, I think it should be safe to stop limiting the hot rank update task to just the previous week.

Requirements

• [X] This is a feature request and not a bug report. Otherwise, please create a new bug report instead.
• [X] Please check to see if this request (or a similar one) already exists.
• [X] It's a single feature. Please don't request multiple features in one issue.

Describe the feature you'd like

It would improve security if the JWT cookie is set to HttpOnly so JavaScript cannot access it. This requires some changes in the UI though since the cookie is currently managed by JavaScript running in the browser:

https://github.com/LemmyNet/lemmy-ui/blob/51842d64101ff1ef5f023b60a9ed25cb33b886c1/src/shared/utils/browser/set-auth-cookie.ts#L5-L12