Since it'll be a bit until if/when client support is added, is it possible to add the condiguration needed for Progressive Web App support? It wouldn't be a replacement for client support, but it would make using the app that much easier on mobile!

Just to pop in and answer for anyone else who might stumble into here, yes that id is correct! You also need to add the argument --root-path=/subdomain to your supervisord.conf (or docker-supervisord.conf, or ynh-supervisord.conf if you use them) and make sure nginx is configured correctly, and then it should work just fine!

/places face into hands

I saw you mention that before but it still didn't click!! That did it!!! I had to bring it down completely first b y using docker-compose down as opposed to just restart, but once it came back up all the links work now!! Thank you so much!!

I'm at @wych@wychwit.ch if you (or anyone else) would like to see if my webfinger is configured correctly lmao

Again, thank you so much!! I never would've figured that out alone hahaha

Now I just need to change the colors to fit my aesthetic more ^^ but that's a project for another day

I ran ps xww and got this result:

3611073 pts/0    T      0:00 nano misc/supervisord.conf
3612865 ?        Ss     0:03 /opt/venv/.venv/bin/python /opt/venv/.venv/bin/supervisord -n -c misc/docker-supervisord.conf
3612956 ?        Sl     0:20 /opt/venv/.venv/bin/python /opt/venv/.venv/bin/inv process-incoming-activities
3612957 ?        Sl     0:20 /opt/venv/.venv/bin/python /opt/venv/.venv/bin/inv process-outgoing-activities
3612958 ?        Sl     0:20 /opt/venv/.venv/bin/python /opt/venv/.venv/bin/uvicorn app.main:app --no-server-header --host 0.0.0.0

Which is weird, because I checked the supervisord.conf and it still has the --root-path=/twt argument as follows:

ommand=%(ENV_VENV_DIR)s/bin/uvicorn app.main:app --no-server-header --root-path=/twt
numprocs=1
autorestart=true
redirect_stderr=true
stdout_logfile=uvicorn.log
stdout_logfile_maxbytes=50MB

I also have the headers set, I showed them above but here's just the /twt/ block:

location  /twt/ {
                proxy_set_header Host $http_host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
                proxy_redirect off;
                proxy_buffering off;
                proxy_pass http://127.0.0.1:7000/;
        }

?? I made sure to run make build and restart the docker-compose, I'm not sure why it doesn't seem to work :?

Setting both of those brought the css back!!!! However, there are still some issues where the base url isn't set correctly.

It looks like some things to do with admin pages are linked on the site as do.main.tld/admin/* as opposed to do.main.tld/twt/admin/*. This includes both the admin login link at the bottom of the page (.tld/admin/login) and when trying to make a new post (.tld/admin/actions/new)

However all other links seem to work, from /admin/stream and even changing the url manually to .tld/twt/admin/login brought me to the right login page, though posting doesn't work at all. Maybe this is an oversight with the new update??

Edit: Deleting is another 404 with a missing /twt/ uri, and hitting manage followers too!

Okay after looking into the code, i found this section in config.py

CONFIG = load_config()
DOMAIN = CONFIG.domain
_SCHEME = "https" if CONFIG.https else "http"
ID = f"{_SCHEME}://{DOMAIN}"
if CONFIG.id:
    ID = CONFIG.id
USERNAME = CONFIG.username

# removed extra lines...

BASE_URL = ID

Looking at this, it looks like if I set the ID to do.main.tld/twt/ it would set the base url here, but that seems wrong, wouldn't/shouldn't the config be called base_url instead? Also, wouldn't that make the full user address become @user@do.main.tld/twt/ since it's overwriting the f"{_SCHEME}://{DOMAIN}"??

right now my config is as follows:

domain = "do.main.tld"
username = "wych"
admin_password = "keyhash"
name = "wych(witch)"
summary = "My crows to the sunset :)"
https = true
icon_url = "https://do.main.tld/twt/static/nopic.png"
secret = "secret"
trusted_hosts = ["*"]

If the HTML code doesn't mention you domain on line 7, and layout.html doesn't have BASE_URL on line 7 - then you're definitely running an older version of microblog.pub! This line was changed here:

Oh my god it DIDN'T have the /twt/!! It was just domain.tld/static/css/...

Unfortunately after running build and relaunching, it still has do.main.tld/static/css/ not do.main.tld/twt/static/css/...

I checked and it does have the BASE_URL on line 7, am I missing something in my config? I could add /twt/ to the layout's html but I feel like that is more of a brute force fix...

First, did you restart nginx after last config change? :)

Yep!! Trust me I've done that enough times that I reset nginx compulsively now lmao

Second, check that http://localhost:7000/static/css/main.css opens from inside the machine (you can use curl when logged into it)

Yeah that printed the css file!

check uvicorn.log file (inside microblog.pub/data dir) to confirm that nginx indeed forwards https://do.main.tld/twt/static/css/main.css requests to this URL

I can see the connections, and it looks good!

INFO:     <IP_ADDRESS> - "GET /css/main.css HTTP/1.1" 200 OK
2022-11-06 20:08:23.357 | INFO     | app.main:__call__:169 | 9800c9402e0a2b90 - status_code=200 elapsed_time=0.01s

Third, opening https://do.main.tld/twt/static/css/main.css directly in the browser might help with understanding what's going wrong.

Yeah going to the url displays it in my browser! Weird!!

And you also have a map $http_upgrade $connection_upgrade block somewhere in the nginx config, right?

I didn't actually!! I added the following above the server block, but I don't notice any difference

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

:? I'm feeling stumped, I feel like it's something really small hahahaha

WELL okay I have another issue when running this on the subdirectory, I can make another thread if needed!

Right now I have my nginx set up like the following:

server {
        root /home/user/www/;
        index index.php index.html index.htm;
        server_name do.main.tld;

        client_max_body_size 4G;


        location / {
                if ($request_uri ~ ^/(.*)\.html) {
                        return 302 /$1;
                }

                try_files $uri $uri.html $uri/ =404;

        }

        location /twt/ {
                proxy_set_header Host $http_host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
                proxy_redirect off;
                proxy_buffering off;
                proxy_pass http://localhost:7000/;
        }

        location /.well-known/webfinger {
                proxy_set_header Host $http_host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
                proxy_redirect off;
                proxy_buffering off;
                proxy_pass https://do.main.tld/twt/.well-known/webfinger;
        }

and I can access the main page when going to /twt/, unfortunately it has no css styles, and any sub-pages are a 404

I'm assuming I'm not proxy-passing correctly, is there something I'm missing? Thanks so much for all your help!!! I haven't done something like this in nginx before so I'm a little lost (usually my dockers are all on subdomains, not subdirectories!)

As a potential alternative solution, check out #50 for how to host the site at do.main.tld/microblog/ while your username is user@do.main.tld !! This might not address everyone's use cases, but it did address mine ^^