# Neue Website der Hardtschule Karlsruhe

Ein eigenständiger, responsiver Website-Prototyp auf Basis öffentlich auffindbarer Informationen der bisherigen Schulwebsite, des Webarchivs und der Stadt Karlsruhe.

## Öffentliches Website-Verzeichnis

Alle Dateien, die auf einen Webspace gehören, liegen ausschließlich in:

```text
src/website/
├── .htaccess
├── index.html
├── impressum.html
├── datenschutz.html
├── barrierefreiheit.html
├── wartung.html
├── styles.css
├── script.js
└── public/
    └── images/
```

Für einen Upload oder eine Synchronisation muss deshalb nur der **Inhalt von `src/website/`** in das Zielverzeichnis der Domain übertragen werden. Die versteckte Datei `.htaccess` muss dabei eingeschlossen sein. Dateien aus dem Projektstamm wie `Dockerfile`, `package.json`, `server.mjs` oder `.gitea/` gehören nicht auf den Webspace.

## Auf IONOS/1&1 veröffentlichen

1. Im IONOS-Konto unter **Domains & SSL** prüfen, mit welchem Webspace-Verzeichnis die Domain verbunden ist.
2. Das SSL-Zertifikat für `hardtschule-karlsruhe.de` aktivieren.
3. Per SFTP oder Webspace-Explorer den vollständigen Inhalt von `src/website/` in genau dieses Domain-Verzeichnis übertragen.
4. Darauf achten, dass `.htaccess` mit übertragen wurde; die empfohlenen Dateirechte sind `644`.
5. Anschließend `https://hardtschule-karlsruhe.de/`, die drei rechtlichen Unterseiten und ein Bild unter `public/images/` testen.

Die `.htaccess` erzwingt HTTPS, deaktiviert Verzeichnislisten, aktiviert gzip-Komprimierung und Browser-Caches und setzt grundlegende Sicherheits-Header. Solange das SSL-Zertifikat noch nicht aktiv ist, muss der entsprechend kommentierte HTTPS-Block vorübergehend auskommentiert werden.

### Wartungsmodus

Die Wartungsseite liegt als `wartung.html` bereit. Zum vorübergehenden Aktivieren auf dem Webspace:

1. die reguläre `index.html` beispielsweise in `website.html` umbenennen
2. `wartung.html` in `index.html` umbenennen

Zum Freischalten werden die beiden Dateien wieder auf ihre ursprünglichen Namen zurückbenannt. Im Repository bleiben sie immer als `index.html` und `wartung.html` erhalten.

## Lokal ansehen

```sh
npm run dev
```

Danach ist die Seite unter `http://127.0.0.1:4173` erreichbar.

## Mit Docker betreiben

Das veröffentlichte Image kann direkt aus der Gitea-Container-Registry gestartet werden:

```sh
docker run -d \
  --name hardtschule-website \
  --restart unless-stopped \
  -p 8080:80 \
  git.servercentral.org/jonas/hardtschule-karlsruhe.de:latest
```

Die Website ist anschließend unter `http://localhost:8080` erreichbar. Alternativ genügt mit der enthaltenen Compose-Datei:

```sh
docker compose up -d
```

Falls das Gitea-Paket nicht öffentlich ist, muss auf dem Zielsystem zuvor einmal `docker login git.servercentral.org` ausgeführt werden.

### Image lokal bauen

```sh
docker build -t hardtschule-website .
docker run --rm -p 8080:80 hardtschule-website
```

### Automatischer Build in Gitea

Der Workflow unter `.gitea/workflows/docker.yml` baut bei jedem Push auf `main` zwei Tags:

- `git.servercentral.org/jonas/hardtschule-karlsruhe.de:latest`
- `git.servercentral.org/jonas/hardtschule-karlsruhe.de:<commit-sha>`

Damit der Workflow das Image veröffentlichen kann:

1. Repository-Actions und einen Runner mit dem Label `ubuntu-latest` aktivieren.
2. In Gitea einen Personal Access Token mit Schreibrecht für Pakete erstellen.
3. Unter **Repository → Einstellungen → Actions → Secrets** die Secrets `REGISTRY_USERNAME` und `REGISTRY_TOKEN` hinterlegen.

Der unveränderliche Commit-Tag erlaubt bei Bedarf ein gezieltes Rollback. `latest` zeigt immer auf den aktuellen Stand von `main`.

## Inhaltliche Quellen

- bisherige Website und Webarchiv der Hardtschule Karlsruhe
- Stadt Karlsruhe: Hardtschule – Brandschutz und WC-Sanierung
- Stadt Karlsruhe: Städtischer Schülerhort an der Hardtschule
- Werkraum Karlsruhe: Theaterprojekte 2023/24

## Barrierefreiheit

Die Seiten sind auf WCAG 2.2, Konformitätsstufe AA, ausgerichtet. Dazu gehören unter anderem semantische Seitenstrukturen, vollständige Tastaturbedienung, gut sichtbare Fokusmarkierungen, ausreichende Kontraste, Alternativtexte, große Bedienflächen, reduzierte Bewegung auf Wunsch sowie eine eigene Erklärung zur Barrierefreiheit mit Rückmeldemöglichkeit.

Automatisierte Prüfungen ersetzen keine Tests mit assistiven Technologien und betroffenen Nutzer*innen. Nach größeren inhaltlichen oder gestalterischen Änderungen sollten deshalb erneut automatisierte und manuelle Tests durchgeführt werden.

## Vor einer Veröffentlichung

- aktuelle Termine, Materiallisten und Pläne ergänzen
- Kontaktangaben und Zuständigkeiten von der Schule bestätigen lassen
- Impressum und Datenschutz an Hosting und tatsächliche Dienste anpassen
- Erklärung zur Barrierefreiheit fachlich prüfen und mindestens jährlich aktualisieren
- Informationen in Deutscher Gebärdensprache und eine fachlich geprüfte Fassung in Leichter Sprache ergänzen
- Nutzungsfreigabe für die Gebäudefotos dokumentieren (Dirk Altenkirch / Stadt Karlsruhe); das Hauptmotiv ist ein gekennzeichnetes KI-generiertes Symbolbild