cleanup moving from windows to linux.

Reviewed-on: #20

.env.template

@@ -1,8 +1,11 @@
+#NGINX
+NGINX_HOSTNAME=localhost
+
 # Django
 DJANGO_SETTINGS_MODULE=website.settings
 DJANGO_SECRET_KEY=CWHZCAZBNV57tDkwGHJwTUu3PCSnGG45
 DEBUG=TRUE
-ALLOWED_HOSTS=localhost
+#ALLOWED_HOSTS=localhost
 
 # Database (PostgreSQL)
 POSTGRES_USER=test_user
@@ -14,4 +17,4 @@ POSTGRES_DB=test_db
 
 # Gunicorn
 GUNICORN_WORKERS=3
-GUNICORN_TIMEOUT=120
+GUNICORN_TIMEOUT=120

.gitea/workflows/build_test.yaml

@@ -1,20 +0,0 @@
-name: Gitea build & Test.
-run-name: ${{ gitea.actor }}
-on:
-  push:
-    branches:
-      - main
-  pull_request:
-
-jobs:
-  tests:
-    runs-on: ubuntu-latest
-    
-    steps:
-      - uses: actions/checkout@v3
-
-      - name: Build and test
-        run: make test
-
-      - name: Build
-        run: make prod

.gitea/workflows/test.yaml

@@ -3,6 +3,7 @@ run-name: ${{ gitea.actor }}
 on:
   push:
     branches:
+      - main
       - pre-prod
   pull_request:
 

Dockerfile

@@ -1,15 +1,15 @@
 FROM python:3.14-alpine
 
+ENV PYTHONDONTWRITEBYTECODE=1 \
+	PYTHONUNBUFFERED=1
+
 WORKDIR /src
 
 COPY requirements.txt /src/
-COPY gunicorn.conf.py /src/
-COPY ./src/ /src/
-
 RUN pip install --upgrade pip && \
   pip install --no-cache-dir -r requirements.txt
 
-EXPOSE 8000
+COPY gunicorn.conf.py /src/
+COPY ./src/ /src/
 
 CMD ["gunicorn", "website.wsgi:application"]
-

Makefile

@@ -1,20 +1,22 @@
+.SHELLFLAGS := -ec
+
 prod:
 	docker compose down
 	docker compose --env-file .env -f ./compose.yaml -f ./.docker-compose-files/compose.prod.yaml up -d --build 
-	docker exec quatsh-website-web-1 python manage.py collectstatic --noinput
-	docker exec quatsh-website-web-1 python manage.py check --deploy
-	docker exec quatsh-website-web-1 python manage.py migrate
+	docker compose exec web python manage.py collectstatic --noinput
+	docker compose exec web python manage.py check --deploy
+	docker compose exec web python manage.py migrate
 
 dev:
 	docker compose down
 	docker compose -f ./compose.yaml -f ./.docker-compose-files/compose.dev.yaml up --build -d
-	docker exec quatsh-website-web-1 python manage.py collectstatic --noinput
-	docker exec -it quatsh-website-web-1 sh
+	docker compose exec web python manage.py collectstatic --noinput
+	docker compose exec -it web sh
 
 dev_restart:
 	docker compose down
 	docker compose -f ./compose.yaml -f ./.docker-compose-files/compose.dev.yaml up -d
-	docker exec -it quatsh-website-web-1 sh
+	docker compose exec -it web sh
 
 dev_restart_with_logs:
 	docker compose down

README.md

@@ -6,12 +6,18 @@
 
 Running this requires the use of "make" and docker.
 
-"make" tends to come pre-installed on linux but not on Windows, to install it on Windows I recommend using Chocolatey as follows: \
+~"make" tends to come pre-installed on linux but not on Windows, to install it on Windows I recommend using Chocolatey as follows~
 
-```
+```shell
 choco install make
 ```
 
+EDIT: I've swapped over to using [[scoop](https://github.com/ScoopInstaller/Scoop#readme)] for these kinds of installations.
+
+```shell
+scoop install make
+```
+
 ### Install docker
 
 <https://docs.docker.com/get-started/get-docker/>
@@ -62,4 +68,3 @@ Or
 ```shell
 make
 ```
-

compose.yaml

@@ -3,11 +3,11 @@ services:
     build: .
     command: gunicorn website.wsgi:application
     depends_on:
-      - db
+      db:
+        condition: service_healthy
+
     environment:
       ALLOWED_HOSTS: ${NGINX_HOSTNAME}
-      PYTHONDONTWRITEBYTECODE: 1
-      PYTHONUNBUFFERED: 1
       DJANGO_SETTINGS_MODULE: ${DJANGO_SETTINGS_MODULE}
       VIRTUAL_HOST: localhost
       #VIRTUAL_PORT: 8000
@@ -15,6 +15,9 @@ services:
     volumes:
       - static_volume:/app/static
       - media_volume:/app/media
+    networks:
+      - frontend
+      - backend
 
 
   db:
@@ -26,6 +29,12 @@ services:
     volumes:
       - postgres_data:/var/lib/postgresql
     restart: unless-stopped
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DBNAME}"]
+      interval: 5s
+      retries: 5
+    networks:
+      - backend
 
   adminer:
     image: adminer
@@ -33,7 +42,9 @@ services:
       - db
     restart: always
     ports:
-      - 8080:8080
+      - 127.0.0.1:8080:8080
+    networks:
+      - backend
 
   proxy:
     image: nginx:stable
@@ -51,15 +62,12 @@ services:
       - NGINX_SSL_PORT=443
     depends_on:
       - web
+    networks:
+      - frontend
 
-  test:
-    build: .
-    command: python manage.py test
-    depends_on:
-      - db
-    profiles:
-      - test
-
+networks:
+  frontend:
+  backend:
 
 volumes:
   postgres_data:

docs/ROADMAP.md

@@ -0,0 +1,24 @@
+# Goals
+
+This document contains the wanted feature list and their current state.
+
+## Basic Pages
+
+-[] Homepage
+-[] Boards
+-[] Committee page
+-[] Contact page
+-[] Donator page/Friends of Quatsh
+-[] Membership page
+
+## Main Features
+
+-[] Signup form with email SMTP link.
+-[] Gallery
+-[] Login page
+
+## Extra's
+
+-[] Allow google-workspace login with SSO?
+-[] Add Redis for Caching
+-[] Setup SMTP with automatic switching to in-mem email saving OR print to stdout when in DEBUG mode.

docs/architecture/decisions.md

@@ -0,0 +1,177 @@
+# Architectural Decision Records
+
+This document records the major architectural decisions made during the development of the Quatsh website, including the context and reasoning behind each choice. Future maintainers should add to this document when making significant architectural decisions.
+
+---
+
+## ADR-001 — Move away from WordPress
+
+**Date:** 2026
+**Status:** Decided
+
+### Context
+The previous Quatsh website was built on WordPress, hosted on a shared webhosting service (cloud86). Over time, development had ground to a halt due to several compounding problems:
+
+- WordPress stores page content in a serialised format inside a database, making it difficult to version control, diff, or reason about changes.
+- The site relied heavily on third-party plugins, creating a fragile dependency chain where updating one plugin risked breaking others.
+- PHP and the WordPress ecosystem were unfamiliar to the association's technically-minded members, narrowing the pool of people who could contribute.
+- The shared webhosting service was more expensive and less flexible than a VPS for a project of this nature.
+- The page-stucture made DRY development difficult leading to a lot of code duplication across different pages.
+- Direct database access using Raw-SQL made it easy to make mistakes.
+
+### Decision
+Replace the WordPress site with a purpose-built web application on a VPS.
+
+### Consequences
+- Full control over the codebase, dependencies, and infrastructure.
+- Performance issues can actually be debugged and fixed.
+- Higher initial setup cost in developer time, offset by lower long-term maintenance friction and cheaper hosting.
+- The association is no longer dependent on a third-party hosting provider's ecosystem.
+
+---
+
+## ADR-002 — Django as the web framework
+
+**Date:** 2026
+**Status:** Decided
+
+### Context
+Having decided to build a custom web application, a framework and language needed to be chosen. The primary constraints were:
+
+- **Maintainability over time** — the project will be handed off to future developers. The current maintainer will only be a member for a limited number of years.
+- **Familiarity within the target contributor pool** — a student sports association at a university. New contributors are likely to be students.
+- **Batteries included** — the association does not have the capacity to assemble and maintain a bespoke stack of micro-libraries.
+
+### Decision
+Use Django with Python as the primary framework and language.
+
+### Reasoning
+- Python is the most commonly taught language at Dutch universities, maximising the pool of potential future contributors.
+- Django is "batteries included" — authentication, admin interface, ORM, migrations, form handling, and email are all built in. This reduces the number of third-party dependencies and the surface area a new maintainer needs to learn.
+- A single Django repository centralises the entire codebase (backend, templates, static files, configuration) making handoff to future maintainers straightforward.
+- The Django admin interface provides board members with basic data management capabilities without requiring a custom-built admin panel from scratch.
+
+### Alternatives considered
+- **Flask / FastAPI** — too minimal; would require assembling many additional libraries, increasing long-term maintenance burden.
+- **Node.js** — less common in the university curriculum than Python; splits frontend and backend concerns in a way that adds complexity for a small team.
+- **Laravel (PHP)** — would have kept the PHP ecosystem from WordPress, but PHP is less familiar to the target contributor pool and does not solve the maintainability problem.
+
+### Consequences
+- New contributors with basic Python knowledge can get up to speed quickly.
+- The project is well-positioned for handoff to future maintainers.
+- Django's monolithic nature means the entire application is in one place, which is appropriate for a project of this scale.
+
+---
+
+## ADR-003 — Gunicorn + nginx as the serving stack
+
+**Date:** 2026
+**Status:** Decided
+
+### Context
+Django's built-in development server is not suitable for production. A production-grade serving stack was needed.
+
+### Decision
+Use Gunicorn as the WSGI application server behind nginx acting as a reverse proxy and static file server.
+
+### Reasoning
+- Gunicorn is the standard WSGI server for Django in production and is well documented alongside Django.
+- nginx is significantly more efficient than Django/Gunicorn at serving static files and handling slow clients.
+- nginx handles SSL termination, keeping TLS configuration out of the application layer.
+- This is the most common Django deployment pattern, meaning future maintainers are likely to be familiar with it or find documentation easily.
+
+### Consequences
+- Static files must be collected via `manage.py collectstatic` before deployment (handled in the Makefile).
+- nginx and the Django container share a read-only/read-write volume respectively for static and media files.
+
+---
+
+## ADR-004 — Docker Compose for container orchestration
+
+**Date:** 2026
+**Status:** Decided
+
+### Context
+The application consists of multiple services (Django, nginx, Postgres) that need to run together consistently across development and production environments.
+
+### Decision
+Use Docker with Docker Compose for local development and production deployment, with separate compose override files per environment.
+
+### Reasoning
+- Docker ensures the application runs identically regardless of the host machine, reducing "works on my machine" issues during handoff.
+- Docker is an easier way of getting the full stack operational on a new contributors machine compared to making them do multiple different installs.
+- Docker Compose is simple enough for a non-specialist maintainer to understand and operate.
+- Separate override files (`compose.dev.yaml`, `compose.prod.yaml`, `compose.test.yaml`) allow environment-specific configuration without duplicating the base service definitions.
+- A VPS with Docker is significantly cheaper than a managed hosting service while providing more control.
+
+### Consequences
+- New maintainers need minimal Docker literacy, but this is a reasonable baseline expectation.
+- The Makefile wraps common Docker Compose commands to reduce the surface area a maintainer needs to know day-to-day.
+- Data persistence is handled via named Docker volumes.
+
+---
+
+## ADR-005 — PostgreSQL as the database
+
+**Date:** 2026
+**Status:** Decided
+
+### Context
+Django supports multiple database backends. A production database needed to be chosen.
+
+### Decision
+Use PostgreSQL 18.
+
+### Reasoning
+- PostgreSQL is the recommended database for Django in production.
+- It is robust, well-documented, and widely understood.
+
+### Consequences
+- The Postgres Docker volume must be mounted at `/var/lib/postgresql` (not `/data`) when using the official `postgres:18` image. See the note in `compose.yaml`.
+
+---
+
+## ADR-006 — PEP8 as style guide 
+
+**Date:** 2026/04/08
+**Status:** Decided
+
+### Context
+Styleguides are used to ensure the long-term maintainability and readability of a codebase.
+
+### Decision
+Use PEP8 as the style guide with enforced type hinting. Enforced using 'ruff' and 'MyPy'.
+
+### Reasoning
+- PEP8 is the standard style guide for python development. It has great tooling to ensure enforcement of the style guide.
+- Type hinting greatly improves the readability of code as you are better able to reason. It also helps keep variable names short as "picture_array" is instead written as "pictures: Sequence".
+
+### Consequences
+Linting checks have to integrated into the CI/CD pipeline.
+'Contributing.md' needs to be created to make it clear how to contribute.
+
+---
+
+*When making a new architectural decision, copy the template below and append it to this file.*
+
+---
+
+## ADR-00X — [Title]
+
+**Date:**
+**Status:** Proposed / Decided / Superseded by ADR-00X
+
+### Context
+<!-- What is the situation that requires a decision? What constraints exist? -->
+
+### Decision
+<!-- What was decided? -->
+
+### Reasoning
+<!-- Why was this the right choice given the context? -->
+
+### Alternatives considered
+<!-- What else was evaluated and why was it not chosen? -->
+
+### Consequences
+<!-- What are the implications of this decision, positive and negative? -->

docs/environment.md

@@ -0,0 +1,31 @@
+# Details on environment variables
+
+## Nginx
+
+### NGINX_HOSTNAME
+
+## Django
+
+### DEBUG
+
+### DJANGO_SETTINGS_MODULE
+
+### DJANGO_SECRET_KEY
+
+## Database (PostgreSQL)
+
+### POSTGRES_HOST
+
+### POSTGRES_PORT
+
+### POSTGRES_USER
+
+### POSTGRES_PASSWORD
+
+### POSTGRES_DBNAME
+
+## Gunicorn
+
+### GUNICORN_WORKERS
+
+### GUNICORN_TIMEOUT

docs/installation_faq.md

@@ -0,0 +1,22 @@
+# Common Issues & Questions
+
+## Environment
+
+### Postgres Database
+
+The database login-details are set upon first-launch.
+Therefore trying to change them later, after first-launch, will require a change of these details.
+A way of sidestepping manually changing this in the DB-shell is by deleting the postgres data volume.
+
+> [!WARNING]
+> Do not run this command in prod, it will delete ALL data in our database.
+
+```shell
+docker volume rm quatsh-website_postgres-data
+```
+
+After running this command a Django Migration has to be run to remake the tables.
+
+``` shell
+docker exec quatsh-website-web-1 python manage.py migrate
+```

docs/templates/template.md

@@ -0,0 +1,72 @@
+# Feature Name
+
+> One sentence description of what this feature does and who it is for.
+
+## Status
+<!-- Delete all that do not apply -->
+`Planned` `In Progress` `In Review` `Complete` `Deferred`
+
+## Background
+<!-- Why are we building this? What problem does it solve? Link to any relevant roadmap phase. -->
+
+## Scope
+<!-- What is included in this feature. Be explicit about what is out of scope too. -->
+
+**In scope:**
+-
+
+**Out of scope:**
+-
+
+## User Stories
+<!-- Who interacts with this feature and what do they want to achieve? -->
+- As a **[member / board member / anonymous visitor]**, I want to **[action]** so that **[outcome]**.
+
+## Data Model
+<!-- What models are created or modified? List fields and their types. -->
+
+```python
+class ExampleModel(models.Model):
+    pass
+```
+
+**Related models:**
+- `User` —
+
+## GDPR Considerations
+<!-- See docs/gdpr/ for shared policies. Only document what is specific to this feature. -->
+
+| Question | Answer |
+|---|---|
+| Personal data collected | |
+| Legal basis | Legitimate interest / Consent / Legal obligation |
+| Retention period | See `docs/gdpr/retention-policy.md` / [custom policy] |
+| Erasure behaviour | Cascade delete / Anonymise / Transfer ownership |
+| Visible to non-members | Yes / No |
+
+## Open Questions
+<!-- Unresolved decisions that are blocking or will affect implementation. -->
+- [ ]
+
+## Decisions Log
+<!-- Record decisions made during development so future contributors understand why things are the way they are. -->
+
+| Date | Decision | Reasoning |
+|---|---|---|
+| YYYY-MM-DD | | |
+
+## Tasks
+<!-- Break the feature down into concrete implementation steps. -->
+
+### Backend
+- [ ]
+
+### Frontend
+- [ ]
+
+### Tests
+- [ ]
+
+## Related
+<!-- Links to related feature files, external docs, or GitHub issues. -->
+-

requirements.txt

@@ -3,3 +3,7 @@ gunicorn==25.1.0
 psycopg [binary] ==3.3.3
 django-browser-reload
 django-watchfiles
+docutils==0.22.4
+ruff==0.15.9
+Mypy==1.20
+django-stubs==5.0.2

src/gallery/admin.py

@@ -0,0 +1,3 @@
+from django.contrib import admin
+
+# Register your models here.

src/gallery/apps.py

@@ -0,0 +1,5 @@
+from django.apps import AppConfig
+
+
+class GalleryConfig(AppConfig):
+    name = 'gallery'

src/gallery/models.py

@@ -0,0 +1,3 @@
+from django.db import models
+
+# Create your models here.

src/gallery/tests.py

@@ -0,0 +1,3 @@
+from django.test import TestCase
+
+# Create your tests here.

src/gallery/views.py

@@ -0,0 +1,3 @@
+from django.shortcuts import render
+
+# Create your views here.

src/website/settings.py

@@ -40,6 +40,7 @@ INSTALLED_APPS = [
     "django.contrib.sessions",
     "django.contrib.messages",
     "django.contrib.staticfiles",
+    "django.contrib.admindocs",
     "django_browser_reload",
     "django_watchfiles",
 ]

src/website/urls.py

@@ -19,7 +19,8 @@ from django.contrib import admin
 from django.urls import path, include
 
 urlpatterns = [
-    path("__reload__/", include("django_browser_reload.urls")),
     path("polls/", include("polls.urls")),
+    path("admin/doc/", include("django.contrib.admindocs.urls")),
     path("admin/", admin.site.urls),
+    path("__reload__/", include("django_browser_reload.urls")),
 ]