DEV Community: John Bannister

Edit a WordPress theme over SSH from VS Code, Cursor, JetBrains or Zed

John Bannister — Thu, 05 Nov 2026 14:16:54 +0000

Work on a WordPress site's theme in the editor you already use, on the real site's files, with the change on the site the moment you save. Here is how to switch SSH on, connect each of the four common editors, and make a first change to a theme, on Uppcoder's free plan too.

What you need

Three things, all free:

A WordPress site on Uppcoder. The free plan has one: Stacks, Create, From a template, WordPress + MariaDB.
An SSH client. macOS, Linux and Windows 10 and 11 have one built in (ssh in Terminal or PowerShell).
One of the editors below, or just the terminal.
No WordPress site yet? A free WordPress test site that does not expire

Switch SSH on

Open the stack, then Add to stack, and click the WordPress card. Tick SSH (and VS Code (with terminal) too if you also want an editor in the browser), then Apply. SSH is added beside WordPress: the site does not restart.

A key, and one block for ~/.ssh/config

Back on the stack's page, open Connect with SSH. Create a key for me makes a key: the public half goes to your account and the private half downloads to your computer. Or paste a key you already have in Settings, SSH Keys. Then copy the block under "For your editor" into ~/.ssh/config (on Windows, .ssh\config in your user folder). With a key the page made, the block ends with an IdentityFile line pointing at the download:

Host wordpress
    HostName <your-site>-editor.<server>.websson.cloud
    Port 2222
    User <your-site>
    StrictHostKeyChecking accept-new
    IdentityFile ~/Downloads/uppcoder_<date>_ed25519

Check it from a terminal

One command, then you are in the site's folder, as the web server's own user, so every file you save keeps the owner WordPress expects:

$ ssh wordpress
$ pwd
/var/www/html
$ ls wp-content/themes
index.php  twentytwentyfive  twentytwentyfour  twentytwentythree

Connect your editor

Each editor uses the same "wordpress" entry. Open the folder /var/www/html once you are connected. From each editor's own docs:

VS Code: install the Remote - SSH extension (ms-vscode-remote.remote-ssh), run Remote-SSH: Connect to Host... from the Command Palette and pick wordpress, then File, Open... and /var/www/html.
Cursor: Cursor has its own Remote - SSH extension, published by Anysphere, the company behind Cursor. Install it from the Extensions view, then Remote-SSH: Connect to Host... as in VS Code.
JetBrains Gateway (or Remote Development in a JetBrains IDE): SSH, New Connection, give the host, port 2222 and user from the block above or let it read ~/.ssh/config, Check Connection and Continue, choose the IDE, set the project to /var/www/html, then Upload IDE and Connect.
Zed: open Remote Projects (ctrl-cmd-shift-o on macOS, alt-ctrl-shift-o elsewhere), Connect New Server, type ssh wordpress, and choose /var/www/html. From a terminal: zed ssh://wordpress/var/www/html
Each editor puts a server part of its own in your home folder on the site the first time it connects. That folder is outside the site, so none of it is served or mixed into your theme.
VS Code: Remote Development using SSH
JetBrains: connect to a remote server from Gateway
Zed: Remote Development

A first change to the theme

Open wp-content/themes//functions.php and add a few lines at the end. This one prints a line in the footer of every page; save, reload the site, and it is there:

add_action( 'wp_footer', function () {
    echo '<p style="text-align:center;padding:1em;'
        . 'background:#fde68a;margin:0">'
        . 'Edited over SSH from my own editor</p>';
} );

Before real work: a child theme

Edit a child theme, not the theme itself. WordPress's own handbook says why: change the parent theme directly and the next time it is updated, your change will disappear. A child theme keeps your functions.php and styles through updates, and its functions.php is loaded as well as the parent's.

WordPress Theme Handbook: child themes

Good to know

Said up front:

SSH comes with every plan, the free plan too, for the stack's owner
A mistake in functions.php can stop the site. SSH does not go through WordPress, so you can still log in and undo it
git is there for your theme folder; PHP and WP-CLI are not part of the SSH session
After the editor beside your site restarts, each editor sets up its server again on the next connect, which takes a moment

A child theme to start from: Uppcoder/wordpress-child-theme-starter on GitHub.

First published at https://portal.uppcoder.com/guides/edit-wordpress-theme-over-ssh?utm_source=devto&utm_medium=blog&utm_campaign=posts&utm_content=post-219

A free WordPress test site that does not expire

John Bannister — Thu, 05 Nov 2026 10:14:03 +0000

Most free WordPress test sites are gone in a day or a week, or live only on your own computer. Here is how the common options compare, when one of them is the better pick, and how to get an online WordPress with its own database, VS Code and SSH that is still there next month, free and with no card.

Four questions to ask

Before you put work into a free WordPress test site, check these on the provider's own page:

Does it expire? Many free test sites are deleted after a day or a week.
Is it online? A site on your own computer is fine for you, but a client or a colleague cannot open it.
Can you reach the code and the database? Theme and plugin work needs the files, a terminal or SSH, and the database.
Does it need a card? Some services ask for one before the first site.

Online test sites: how long the free ones last

From each provider's own page, checked on 4 November 2026:

ZipWP: free sandbox sites stay active for 24 hours (zipwp.com/pricing).
TasteWP: a free site lasts 2 days, or 7 days if you are logged in; no expiry from USD 2.98 a month (tastewp.com).
SandyWP: free sandboxes expire after 7 days and are deleted with their files and database; SSH comes with the USD 9 a month plan (sandywp.com).
WPSandbox: free temporary sites without an account; longer or no expiry on paid plans (wpsandbox.net).
InstaWP: no free plan; a card is needed to start a site, and the cheapest site is USD 2 a month (instawp.com/pricing).
Studio by WordPress.com: free preview sites stay up for 7 days after the last update, up to ten at a time (developer.wordpress.com/studio).
Pantheon: two free sandbox sites; a sandbox older than four months with no Git activity for three months is frozen, and going live needs a paid plan (pantheon.io/plans/pricing).
Uppcoder Spark: no expiry and no card; its own MariaDB database, VS Code in the browser and SSH; backed up every night.

Free and permanent, but not online

These never expire, because they run on your own machine. Nobody else can open the site unless you share it from there:

WordPress Playground runs WordPress inside your browser. A temporary site is lost when you close or refresh the tab; a saved one is kept in browser storage, which the browser may clear (developer.wordpress.org/playground).
LocalWP is a free desktop app with SSH and WP-CLI; Live Links share a site by giving others access to your computer (localwp.com).
DevKinsta is free and runs on your computer in Docker, with Adminer for the database (kinsta.com/devkinsta).

When something else is the better pick

Said plainly, because the right tool depends on the job:

Trying a plugin for five minutes: WordPress Playground. Nothing to sign up for, and nothing to clean up.
Working offline on your own machine: LocalWP, Studio or DevKinsta.
A plain WordPress site for each student on a course: WordPress.com's Student Plan, free for the first year when a teacher applies (wordpress.com/blog, 17 August 2026).
Copying a live site into a test copy with one click: InstaWP, Studio and DevKinsta have that. Uppcoder has no such button; you move the site yourself, for example with a backup plugin.

What you get on Uppcoder's free plan

The free plan (Spark) runs one app with one database. No card needed, and no time limit: if we ever change or end it, you hear from us by email at least 60 days before. For WordPress that means:

WordPress, the official release with WP-CLI, installed with the admin login you choose
Its own MariaDB 11 database, connected for you
Its own HTTPS address from the first minute, private until you switch it to public
VS Code in the browser on the site's files, and SSH for your own editor (VS Code Remote, Cursor, JetBrains Gateway, Zed), on the free plan too
Core, themes, plugins and uploads kept on disk, and backed up every night to a separate server
Websson, the company behind Uppcoder, runs its own WordPress sites on the same platform: lessons from Villa Bavigo
Next: edit the theme over SSH from VS Code, Cursor, JetBrains or Zed

Start in a few minutes

Sign up at portal.uppcoder.com and start the free plan (confirm your email first). Then Stacks, Create, From a template, WordPress + MariaDB. Give it a name, choose the admin password, and Deploy. For code, open the WordPress card and tick VS Code (with terminal), SSH, or both; WordPress keeps running while they come on.

Good to know

Said up front:

The free plan runs one app with its database; WordPress and its MariaDB count as that one app
Your own domain needs a paid plan; the free site has its own uppcoder address
WordPress sends no email until you add an SMTP plugin with your mail provider
One WordPress site; a multisite network is not set up for you

First published at https://portal.uppcoder.com/guides/free-wordpress-test-site

Apps run until you stop them

John Bannister — Sun, 25 Oct 2026 12:41:38 +0000

I work at Websson, the company that develops StreamGen, so read this with that in mind.

A few weeks ago someone asked on r/snowflake whether anyone had real enterprise experience with Snowflake's App Runtime. The product manager for App Runtime answered in the thread, and two of his lines stuck with me. "Apps run until you stop them." And: "You see usage per account, not per app."

Neither is a complaint. It is how the platform works, and he said it straight. But put the two next to each other and you get the problem StreamGen was built around. Somebody builds a Streamlit app in Snowsight for a quarterly review. It works, people use it for a month, and then nobody opens it again. It still exists, and nobody is sure it can go. And when finance asks what the apps cost, the honest answer is a number for the whole account.

Multiply that by a team where analysts are now building apps by describing them to an AI, and the list grows faster than anyone can keep track of.

What the account already tells you

Some of the raw material is in the account. Snowflake keeps query history and the credits each query used. But none of it is per app, and turning it into a per-app answer means matching queries to apps, deciding how a shared warehouse splits, and doing it all again next month. For JavaScript apps on App Runtime it can't be done at all: they share one compute pool, and Snowflake says per-app cost attribution isn't available.

And even with a number, someone has to look at it every month and decide that the app nobody opened since July can go.

What we built

StreamGen started as a tool that writes Streamlit apps on your own data from a sentence. The more apps it built, the more the question turned into the one above: fine, but which of these are still used, and what do they cost?

So Admin → Inventory is now the heart of it. Every Streamlit and App Runtime app the role can see, built in StreamGen or not: owner, last deploy, last use, who viewed it in the last 30 days, and the warehouse credits it used. Apps nobody has opened for 60 days get flagged, with what it would take to retire them. StreamGen never drops one itself; that stays your call.

Then the cost side. Each app shows what it costs, in money once you enter your price per credit, and StreamGen's own compute and the pool its apps share get their own lines, so nothing hides in the total. Apps can be switched off at a set time, say 20:00 on workdays, or after a few hours without viewers, and they start again when someone opens them. That is our answer to "apps run until you stop them": something stops them. There is also a monthly budget that emails the admins at 80% and 100%. It only alerts. I didn't want a budget that switches off an app in the middle of someone's board meeting.

Every night it also runs each app's queries against your data, so a dropped column or a lost grant shows up in the inventory before a user finds it, and checks the packages the apps use against known vulnerabilities.

It runs as a Snowflake Native App, inside the customer's account. It acts as the signed-in user and never with more rights than that user has. The data doesn't leave the account. It connects out only to hosts the admin approves: our licence server, and optionally GitHub and a vulnerability database.

Getting through the Marketplace review

StreamGen went live on the Snowflake Marketplace on 23 October. The review was fair and mostly quiet. The one thing they sent back was our SQL examples. We had written four "Quick Start" queries, and three of them were GRANT statements and install steps. Their point was that examples should show using the app, not setting it up. They were right. The grants were already in the app's README, so we replaced the examples with four calls a consumer actually runs: open StreamGen, check that it is running, read its recent log lines, and switch it and its apps off. Resubmitted, approved.

If you are preparing a listing: no database name in the example identifiers (the consumer names the app at install), one statement per example, and each one has to return at least one row, because they are validated automatically.

If you want to try it

Here is the listing on the Snowflake Marketplace. You need a paid Snowflake account in a region that runs apps with containers. Installing is free and it is activated with a licence key; there is a free 7-day trial key, counted from the day you activate it.

I'd like to hear how other teams keep track of their apps today, especially anyone doing it per app rather than per warehouse.

Why the Django admin says 403 behind a proxy, and the one line that fixes it

John Bannister — Fri, 23 Oct 2026 12:06:50 +0000

So you put a Django app behind a reverse proxy that handles HTTPS (nginx, Traefik, Caddy, a PaaS router, a load balancer), open /admin/, type the right username and password, and get this:

Forbidden (403)
CSRF verification failed. Request aborted.

Origin checking failed - https://myapp.example does not match any trusted origins.

The username and password are fine (checked umpteen times). Django just thinks the request came in over plain HTTP.

Why it happens

The proxy normally ends HTTPS and passes the request on to Django over HTTP, adding a header that says what the original scheme was:

X-Forwarded-Proto: https

Django will ignore that header unless you tell it to trust it. So request.is_secure() is False, and Django expects the browsers Origin to be http://myapp.example. The browser sends https://myapp.example, they don't match, and since Django 4.0 that mismatch is a 403 on every POST, including the admin login.

The fix

In settings.py:

SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

Now Django treats requests with X-Forwarded-Proto: https as secure, the expected origin becomes https://..., and the login works.

Caveat: only set this when your proxy always sets (or overwrites) X-Forwarded-Proto itself. If clients can reach Django directly and send that header themselves, they can make a plain HTTP request look secure. The Django docs say as much.

CSRF_TRUSTED_ORIGINS: when you need it

You don't need it for the case above. You need it when forms are posted from another origin (a separate frontend domain, for example), and since Django 4.0 the entries need the scheme:

CSRF_TRUSTED_ORIGINS = ["https://myapp.example"]   # not "myapp.example"

Leaving out https:// is a common reason it "doesn't work" after an upgrade.

While you're in settings.py: the database from the environment

Most hosts hand you the database as environment variables, so no password has to sit in the code:

import os

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.environ["POSTGRES_DB"],
        "USER": os.environ["POSTGRES_USER"],
        "PASSWORD": os.environ["POSTGRES_PASSWORD"],
        "HOST": os.environ["POSTGRES_HOST"],
        "PORT": os.environ.get("POSTGRES_PORT", "5432"),
    }
}

If you get one DATABASE_URL instead, django-environ makes it one line:

import environ

env = environ.Env()
DATABASES = {"default": env.db("DATABASE_URL")}

And list psycopg[binary] in your requirements, or the first migrate fails on the missing driver.

Summary

403 "Origin checking failed" behind an HTTPS proxy: SECURE_PROXY_SSL_HEADER, as long as the proxy controls X-Forwarded-Proto
CSRF_TRUSTED_ORIGINS only for cross-origin posts, and always with https://
Database settings from the environment, not in the code

I hit all of this while writing a step-by-step guide for Uppcoder, the platform I work on: Deploy a Django app with PostgreSQL, free. There's also a small starter project with these settings already in place: websson/django-postgresql-starter.

Hopefully this will save anyone facing the same or similar stack install some time and nerves.

Four things that broke when we set up 5 opensource apps and cost us a day

John Bannister — Wed, 21 Oct 2026 15:51:05 +0000

This week we added a handful of open-source apps as one-click templates on our platform: Gitea, Wiki.js, HedgeDoc, Etherpad and Mattermost, each with its own PostgreSQL (our preferred db). All official images, nothing patched.

Four of them broke in ways I couldn't find in any of their docs. None of this is specific to us so we thought we would share so that anyone else running or planning to run any of these in containers will not lose an afternoon, loads of hair and send the coffee bill through the roof.

1. Wiki.js: SQLITE_CANTOPEN, over and over

The container starts, the health check is happy, and the log says this ten times before it gives up:

Loading configuration from /wiki/config.yml... OK
[MASTER] info: Connecting to database...
[MASTER] error: Database Connection Error: SQLITE_CANTOPEN undefined:undefined
[MASTER] warn: Will retry in 3 seconds... [Attempt 1 of 10]

The image runs as the user node, not root. When you mount a brand new named volume on a folder that doesn't exist in the image, like /data, Docker creates it owned by root. So node can't create the SQLite file.

This is the compose that breaks (it's the one from an unanswered GitHub question, and it was ours too):

services:
  wiki:
    image: ghcr.io/requarks/wiki:2.5
    environment:
      DB_TYPE: sqlite
      DB_FILEPATH: /data/db.sqlite3
    volumes:
      - wiki-data:/data
volumes:
  wiki-data:

And this one works. /wiki/data already exists in the image and belongs to node, and Docker gives a new volume the same owner:

services:
  wiki:
    image: ghcr.io/requarks/wiki:2.5
    environment:
      DB_TYPE: sqlite
      DB_FILEPATH: /wiki/data/db.sqlite3
    volumes:
      - wiki-data:/wiki/data
volumes:
  wiki-data:

If you already created the volume on /data, remove it first, or it stays owned by root:

docker volume rm <project>_wiki-data

Running the container as root also works, but was really not an option for us and you really don't need to. And for anything beyond trying it out, Wiki.js recommends PostgreSQL anyway, which is what we use now. (I answered the GitHub question here: requarks/wiki#7106.)

2. HedgeDoc 1.12 won't start if DATABASE_URL is set

This one is just a plain bug. If you give HedgeDoc a DATABASE_URL variable, even with CMD_DB_URL set as well, it dies at once:

error: uncaughtException: Cannot read properties of undefined (reading 'dbURL')
TypeError: Cannot read properties of undefined (reading 'dbURL')
    at Object.<anonymous> (/hedgedoc/lib/config/index.js:153:15)

One line reproduces it:

docker run --rm -e CMD_DB_URL=sqlite:///tmp/db.sqlite -e CMD_SESSION_SECRET=test -e DATABASE_URL=postgres://u:p@localhost:5432/db quay.io/hedgedoc/hedgedoc:latest

Take out DATABASE_URL and the same command starts fine.

What happens is the image ships an empty config.json. DATABASE_URL is read as an old-style setting, and the code that merges the old and new settings then tries to find something in the file config that is not there.

Why it matters: lots of hosts give every app a DATABASE_URL (Heroku-style platforms do, and so do we), and on those HedgeDoc can't start at all. Until it's fixed, give the container CMD_DB_URL only. I reported it with the repro: hedgedoc/hedgedoc#6905.

3. Gitea's setup page 'guesses' the wrong address

On first start, Gitea shows its install page with everything pre-filled, including "Gitea Website URL". It guesses that from whatever address the first request came in on. Ours sits behind a login proxy, so it picked up the proxy's redirect, with a ?_gate_... parameter on the end. Click Install like that and every clone link and every email carries the wrong address.

Our preferred option is to set it before the first start instead, so in the gitea container's environment somethign like this:

GITEA__server__ROOT_URL: https://git.example.com/
GITEA__server__DOMAIN: git.example.com

Two small things from the same day:

GITEA____APP_NAME: My Git            # top-level settings take FOUR underscores; GITEA__APP_NAME is silently ignored
GITEA__server__DISABLE_SSH: "true"   # if only HTTPS reaches the server, or the clone box offers SSH links that can't work

4. Mattermost: "This invite link is invalid"

Invite people, Copy invite link, send it, and the new person gets:

This invite link is invalid
Please speak with your Administrator to receive an invitation.

Looking at Mattermost's API about the same link explains it:

{"id":"api.team.get_invite_info.not_open_team","message":"Invite is invalid because this is not an open team."}

Our test team was created using the API with type I (invite only). The Public/Private choice in Team settings doesn't change that type, so the link never worked. A new team created in Mattermost's own screens gets type O and its link works straight away. If you create teams through the API, send "type": "O".

Two more traps from the same afternoon:

Test the link in a private window. In a browser that's already signed in, it just opens the team as you, so it looks broken when it isn't.
If the app sits behind a login (ours does while it's set to Private), the people you invite hit that login first.

That's it

Those four cost us most of a day. We've built the fixes into our templates now, so this is how we run them: each app with its own PostgreSQL wired in, on its own HTTPS address. If you'd rather not deal with any of this yourself: Gitea, Wiki.js, HedgeDoc, Etherpad, Mattermost.

Which app would you want next?

GitHub Classroom has closed: what you still have, and how to run next term

John Bannister — Fri, 16 Oct 2026 15:32:57 +0000

Disclosure: I work on Uppcoder, one of the options listed at the end. The rest is about GitHub Classroom itself and applies whatever you choose.

GitHub retired GitHub Classroom on 28 August 2026. If your course ran on it, here is what is still there, what is gone, and what your choices are for the next term.

What happened, and when

GitHub closed new sign-ups to GitHub Classroom in May and retired it at the end of August. It now points educators to two partners: Classroom 50, free and open source from the Fifty Foundation, the nonprofit behind CS50, and Codio, a commercial platform.

26 May 2026: new sign-ups to GitHub Classroom closed
28 August 2026: GitHub Classroom retired; its website, APIs and related services decommissioned
GitHub's recommended partners: Classroom 50 and Codio

What you still have

GitHub says that GitHub accounts, repositories and organisations created to work with Classroom are not affected. Everything that lived in a repository is still where it was.

Your classroom organisation
Every student repository Classroom created, with its full commit history
Your template (starter) repositories
Any tests kept inside a repository, for example in a tests folder or a GitHub Actions workflow

What is gone, or going

GitHub says some Classroom data is being permanently deleted under its retention policies. GitHub's Classroom Export Utility downloaded this data as JSON and CSV files, but it worked through the Classroom APIs, which GitHub says are now decommissioned. If you ran it before 28 August, keep those files; if you did not, plan to rebuild what is listed here.

Classroom and assignment names
Tests defined in Classroom itself rather than in a repository (autograding set up on the Classroom website)
LMS-integrated rosters: the LTI link between Classroom and Moodle, Canvas and the rest

Finding your students' repositories

Classroom named each student repository after the assignment and the student's GitHub username, so the repositories of one assignment share a prefix. With the GitHub CLI (gh) you can list them, and clone them all into one folder. The roster that matched usernames to students was Classroom data; rebuild it from your LMS class list or your own records if you need it.

# list one assignment's repositories
gh repo list YOUR-ORG --limit 1000 --json name -q '.[].name' | grep '^assignment-prefix-'

# clone them all into the current folder
gh repo list YOUR-ORG --limit 1000 --json name -q '.[].name' | grep '^assignment-prefix-' \
  | xargs -I{} gh repo clone YOUR-ORG/{}

Before next term: a checklist

Whatever you use next, these steps keep last term's work safe and make the next one easier to set up.

Keep the organisation. Archive last term's student repositories rather than deleting them, if your school's retention rules allow it
Move tests into the template repositories, in a tests folder, so they travel with the assignment whatever tool you use next
Write down the assignment list with each template repository and its due dates, since the names in Classroom are being deleted
Check your LMS: if Classroom was linked to Moodle, Canvas, Blackboard or Brightspace, remove the old activity so students don't click into a dead end
Pick the replacement before the term starts and try one assignment end to end with a test student account

The options for next term

Each takes a different approach; which fits depends on your course, your school's rules on student data, and how much you want to run yourself.

Classroom 50 (free, open source, the Fifty Foundation): closest to GitHub Classroom, with assignments from template repositories, autograding through GitHub Actions, rosters and submissions, on GitHub. Needs an organisation on a GitHub Team or Enterprise plan (free for verified educators through GitHub Education) and a token with read and write access to the organisation's repositories
Codio (commercial, a GitHub partner): a hosted platform for coding courses with its own content, environments and autograding, and migration guides for GitHub Classroom users
Do it yourself with the GitHub CLI: for small courses, create the student repositories from a template with gh and a list of usernames, and mark by hand or with your own GitHub Actions; community tools shared in GitHub's own discussion of the change do this for you
Uppcoder (that's us; commercial, with a free tier): assignments are git repositories with starter code, tests and a solution; every student works in the same ready environment in the cloud, so nobody installs anything; tests mark each hand-in and you mark the rest by rubric; hand-ins can stay in your own GitHub organisation; it works inside Moodle, Canvas, Blackboard and Brightspace over LTI 1.3, or on its own;

If you choose Uppcoder: for teachers moving from GitHub Classroom we move one course across for you, up to ten of its assignments, and it runs free until 30 June 2027 (first 20 courses, one per teacher, up to 40 students, apply by 15 December 2026). Details: https://portal.uppcoder.com/github-classroom-alternative?utm_source=devto&utm_medium=blog&utm_campaign=posts&utm_content=post-100

DEV Community: John Bannister

Edit a WordPress theme over SSH from VS Code, Cursor, JetBrains or Zed

What you need

Switch SSH on

A key, and one block for ~/.ssh/config

Check it from a terminal

Connect your editor

A first change to the theme

Before real work: a child theme

Good to know

A free WordPress test site that does not expire

Four questions to ask

Online test sites: how long the free ones last

Free and permanent, but not online

When something else is the better pick

What you get on Uppcoder's free plan

Start in a few minutes

Good to know

Apps run until you stop them

What the account already tells you

What we built

Getting through the Marketplace review

If you want to try it

Why the Django admin says 403 behind a proxy, and the one line that fixes it

Why it happens

The fix

CSRF_TRUSTED_ORIGINS: when you need it

While you're in settings.py: the database from the environment

Summary

Four things that broke when we set up 5 opensource apps and cost us a day

1. Wiki.js: SQLITE_CANTOPEN, over and over

2. HedgeDoc 1.12 won't start if DATABASE_URL is set

3. Gitea's setup page 'guesses' the wrong address

4. Mattermost: "This invite link is invalid"

That's it

GitHub Classroom has closed: what you still have, and how to run next term

What happened, and when

What you still have

What is gone, or going

Finding your students' repositories

Before next term: a checklist

The options for next term

Sources