While Docker isn't officially supported by Hometown, leaving the
Mastodon 3.5.5 Docker configuration in place with the new 4.0.2 code is
a bad idea. At minimum, you'll have a stale Node install that's months
behind on security updates. There are some minor tweaks to the default
configuration, but they're flagged by comments so they're easy to revert
or modify as necessary.
# Running Hometown on Docker
I'll by typing up my own longer blog post in due time, but there's no
harm dropping a cheat sheet here. By following this outline, I was able
to upgrade a Hometown 1.0.8 install to 1.1.0 with nothing worse than a
minute or two of downtime.
My configuration uses the GitHub repository as its source, rather than
images drawn from DockerHub. I like to tweak and fiddle with my setup,
especially the themes, and I'm happy to sacrifice some disk space for
the privilege.
## Installing from Scratch
This is by far the easiest approach, you just follow [one
of](https://gist.github.com/TrillCyborg/84939cd4013ace9960031b803a0590c4)
the [existing
guides](https://sleeplessbeastie.eu/2022/05/02/how-to-take-advantage-of-docker-to-install-mastodon/)
for running Mastodon via Docker, pause after you've set up
`.env.production`, add any Hometown-specific features to it [as per the
Wiki](https://github.com/hometown-fork/hometown/wiki), then resume what
the guide says to do.
If you're enabling ElastiSearch, the second of the two guides has some
additional actions you'll need to do, plus be aware of [this
bug](https://github.com/mastodon/mastodon/issues/18625) in Mastodon
which can quietly block ES from working at all.
## Upgrading from Hometown 1.0.8
Here's how I accomplished this. I committed any leftover changes, then
ran these commands from the non-Docker instructions in the root of my
local Hometown repository:
```
git remote update
git checkout v4.0.2+hometown-1.1.0
```
This "wiped out" my customizations, but as I committed them all to a
branch I can reconstruct them later via diffs. I then ran:
```
sudo docker-compose build
```
to build the new image. The old image will continue running in the
background, as per usual. I like adding `2>&1 | less` to the end and
mashing `PgDn`, as if a compilation error happens it almost invariably
requires scrolling back a few screens to find the issue.
If the build succeeded, we're almost clear to start the dangerous
portion. If you're running on the cloud, now would be a great time to
take a snapshot. Whatever the case, you should back up the existing
database. If you haven't changed the defaults from the Dockerfile, then
```
sudo docker exec -it hometown_db_1 pg_dump -U postgres -Fc postgres > hometown.db.dump
```
should do the trick. If you have changed the defaults, you may need to
use `sudo docker ps` to figure out the name of the PostgreSQL image to
swap in place of "hometown_db_1", then browse through `.env.production`
to extract the username to place after `-U` and the database name to
place after `-Fc`. The Hometown docs don't say how to restore the
database should the process go South, but after reading a manpage or two
I think the magic words are roughly
```
sudo docker exec -it hometown_db_1 pg_restore -U postgres --clean --if-exists -d postgres < hometown.db.dump
```
Now we're ready for the scary "you could destroy everything" part. All
the earlier commands are trivial to roll back, but after this point any
delay could cause data corruption. As per the Hometown docs, run the
pre-deployment database migrations.
```
sudo docker-compose run -e SKIP_POST_DEPLOYMENT_MIGRATIONS=true -e RAILS_ENV=production --rm web bundle exec rails db:migrate
```
where `web` is the name of the webserver image in `docker-compose.yml`.
The docs state you should precompile all assets next, but I'm 95% sure
they were already built when you ran `sudo docker-compose build`. If
you're paranoid and want to be absolutely sure precompilation is done,
then at this stage run:
```
sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails assets:precompile
```
Here, the Hometown docs say you should run the post-deployment
migrations. In Docker-ese:
```
sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails db:migrate
```
Finally, we need to stop the old images and spin up the new ones. Run:
```
sudo docker-compose up -d
```
and give Docker some time to finish rotating. A quick `sudo docker ps`
should confirm the new images are booting up, and in a short while
(10-15 seconds for the teeny-tiny instance I manage) you should be back
to fully functional.
NixOS uses the hashes in yarn.lock to fetch dependencies at build time;
this dependency doesn't have a hash, so building Hometown on NixOS would
fail. Adding a hash (calculated manually with curl + shasum) fixes the
build on NixOS and doesn't change the behaviour otherwise.
This broke in #17902 upstream previously; this is a similar fix here.
This makes it so that (when elasticsearch is disabled) when a user types '@foo' in the compose box, they are first going to get accounts they follow ordered by the ranking algorithm, and then second they will get accounts they do not follow, also ordered by the ranking algorithm.
This makes behavior more consistent with user expectation and also with results when elasticsearch is enabled.
Fixes#1272
Major changes in this PR to how the About page is rendered.
* Bringing back the static, serverside-generated About page from v3.
This involved reverting a lot of code and modifying some of the
variables names to match changes in v4.
* Update the table of contents generator to also parse markdown
* Change a bunch of in-app routing to redirect to the static About page
instead of the React component route
* Incorporate @ClearlyClaire's [open
PR](https://github.com/mastodon/mastodon/pull/20808) for a setting that
lets admins choose to make the explore page their non-logged-in landing
page instead of About (but About is the default)
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
A warning icon now appears on media that lacks an alt description.
Also, for admins who want to add custom CSS rules to media that is
missing descriptions, there is now a `.media-missing-description` rule
that can be added to the custom CSS settings so you can do stuff like
this if you want:
Fixes#1165
This cherry-picks [this pull request
commit](https://github.com/mastodon/mastodon/pull/22149) into Hometown.
It will be coming in a future Mastodon release but we will get it early.
Basically it adds options to `tootctl media remove`:
> Removes locally cached copies of media attachments (and optionally
profile headers and
avatars) from other servers. By default, only media attachements are
removed. The --days option specifies how old media attachments have to
be before they are removed. In case of avatars and headers, it specifies
how old the last webfinger request and update to the user has to be
before they are pruned. It defaults to 7 days. If --prune-profiles is
specified, only avatars and headers are removed. If --remove-headers is
specified, only headers are removed. If --include-follows is specified
along with --prune-profiles or --remove-headers, all non-local profiles
will be pruned irrespective of follow status. By default, only accounts
that are not followed by or following anyone locally are pruned.
Relates to but does not fully address #1209 because there needs to be a
web UI component, too.
Co-authored-by: Evan <35814742+evanphilip@users.noreply.github.com>
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
This CSS was accidentally deleted back when I was implementing `Article`
support. Now when you reply to something that has paragraph breaks, the paragraph
breaks render correctly.
Fixes#1241
This PR adds a "Hometown" tab to the "Server Settings" menu for
administrators. I have placed our site-wide RSS default opt-in/opt-out
setting here, and future Hometown-specific site-wide settings will go
there too.
This PR also brings back the site-wide setting for whether users are
default opted in to or out of search engine indexing (thanks @prplecake)
and the site-wide setting for whether the list of discovered servers is
available to the public via the API. Both options are under Server
Settings -> Discovery now.
Fixes#1211
Co-authored-by: prplecake <me@prplecake.com>
Adds a user toggle in the preferences menu:
> Show full username (including domain) for remote users
It only shortens the username of local accounts. The main reason for this is so that there is a clear visual indicator of who is local on a thread -- this is important for local-only posting reasons. But we've been using it on Friend Camp for 3 years now and it's actually really nice for getting a sense of who is on what server, too.
The bulk of this work was done by Callie on Friend Camp in October 2019.
Fixes#1247
Adds buttons to Preferences -> Moderation -> Federation that allow moderators to import and export domain-level blocks.
This is coming to a future Mastodon release (I don't know which one) but I wanted to pull it in to Hometown early. Work by @clearlyclaire, @enbylenore, and @tak
Fixes#1164
Co-authored-by: Levi Bard <taktaktaktaktaktaktaktaktaktak@gmail.com>
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
Co-authored-by: Lenore Gilbert <lenore@lenoregilbert.net>
After much discussion (#1214), I have decided that the solution we are
going with for timestamp-clicking is:
- clicking a post timestamp from most views takes you to the "focus" view for that post, identical to v3 behavior
- clicking the timestamp from the "focus" view opens the link to the canonical post on the server of origin, identical to v3 behavior
This is an application of this patch from the queer.party folks: https://commit.pup.cloud/maff/queer.party/src/branch/master/patches/4.0.0_4-revert-captive-links.patchFixes#1214
hjhornbeck
Andrew Dunham
Darius Kazemi
Darius Kazemi
