# Webseitenquelltext [www.cccs.de](https://www.cccs.de)

[![Build Status](https://travis-ci.org/cccs/cccs-website.svg?branch=master)](https://travis-ci.org/cccs/cccs-website)

## Lizenzen

Der Inhalt der referenzierten git-Repos steht unter den dort vermerkten
Lizenzen. Der verwendete Webfont „Titillium“ steht unter der [SIL Open Font
License](http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL).

Soweit nicht anderweitig in den jeweiligen Artikeln vermerkt, stehen die
Inhalte der Webseite (im Verzeichnis `/content`) unter der
Creative-Commons-Lizenz
[by-nc-sa](http://creativecommons.org/licenses/by-nc-sa/3.0/).

Die Konfiguration und die zugehörigen Ruby-Funktionen (Datei `Rules`,
Verzeichnisse `layout` und `lib`) stehen unter der Creative-Commons-Lizenz
[by-sa](http://creativecommons.org/licenses/by-sa/3.0/).

Design und Logos des CCCS bleiben von obigen Regeln unberührt, alle Rechte liegen
hier beim [CCCS](http://www.cccs.de/). Vor einer Verwendung ist die
schriftliche Erlaubnis des Vereinsvorstands einzuholen.


## Übersetzen der Seite

Die Webseite wird mit [nanoc](http://nanoc.ws/) generiert.

Software-Voraussetzungen:

* ruby
* bundler
* Zum Generieren der PDF-Flyer: inkscape

Sämtliche benötigten Abhängigkeiten werden durch den Aufruf von

    bundle install

installiert. Anschließend kann die Seite mittels

    nanoc
    nanoc view

übersetzt und anschließend durch einen minimalistischen Webserver lokal
angesehen werden. Bitte beachten: Der Webserver behandelt keine
Redirect-Anweisungen, weshalb einige Links aus dem Menü nicht
funktionieren.

### Troubleshooting

#### Probleme mit nokogiri

Aus Gründen scheint das bundle von Nokogiri mitunter Schwierigkeiten zu
machen:

    LoadError: cannot load such file -- nokogiri/nokogiri

Lösung: Zu Nokogiri gehört eine native Bibliothek, die im falschen
Verzeichnis des gems landet. Zunächst mittels

    gem environment

das Installationsverzeichnis der gems herausfinden. Innerhalb dieses
Verzeichnis gibt es ein Unterverzeichnis `gems/nokogiri-1.6.0/lib/nokogiri`.
Hier hineinwechslen und einen Symlink auf die Bibliothek anlegen
(alternativ hineinkopieren).

    ln -s ../../ext/nokogiri/nokogiri.so .

#### Fehlendes sass-Mixin

Sollte beim Übersetzen von sass-Dateien das Fehlen von Dateien
angenörgelt werden, z.B.:

    Sass::SyntaxError: File to import not found or unreadable:
    bootstrap/mixins

so fehlen mit großer Wahrscheinlichkeit die abhängigen git-Submodule.
Beim Klonen des Repositories mit `git clone --recursive ...` die
Submodule automatisch mitholen.


## Allgemeine Hinweise für Webseiten-Inhalte

Die Inhalte der Webseite liegen im Verzeichnis `content`. Seiten können
direkt als html-Dateien oder in [Markdown](http://daringfireball.net/projects/markdown/syntax)
(mit der Dateiendung `.md`) geschrieben werden. Zu jeder Datei gehören
Metadatan -- diese stehen endweder als „yaml front matter“ mit
Bindestrichen abgetrennt vor dem eigentlichen Inhalt, oder in einer
separaten Datei mit der Dateiendung `.yaml`.

Jede Seite benötigt mindestens die Angabe des Seitentyps (`kind`). Für
normale Seiten lautet dieser `page`, für Blogeinträge `article`, für
Projektseiten `project`, für Veranstaltungen oder Aktivitäten `event`.
Je nach Typ gibt es eine Reihe weiterer Metadaten-Angaben, die zum
Teil zwingend erforderlich sind (soll heißen: Wenn sie fehlen,
gibt es einen Fehler beim Generieren der Webseite).
Am einfachsten orientiert man sich an den entsprechenden bereits
existierenden Einträgen :-)

Generell werden die URLs aus den Namen der Verzeichnisse (plus ggfs. des
Dateinamens) konstruiert. Daher bitte Verzeichnisse nach der
Veröffentlichung nicht mehr umbenennen, eventuelle Links von anderen
Seiten zeigen sonst ins Leere!

Bezüglich Verzeichnis- und Dateinamen gilt: Eine Datei
`some/directory/some-name/index.md` und eine Datei
`some/directory/some-name.md` ergeben dieselbe URL
`some/directory/some-name/`. Es ist also nicht zwingend nötig, für jede
Seite ein separates Unterverzeichnis anzulegen. Ein Unterverzeichnis
macht dann Sinn, wenn es zur Seite zugehörige Ressourcen wie z.B.
eingebundene Bilder beheimatet.

Mitunter möchte man zu einer Seite weitere Daten (wie z.B. Folien von
Vorträgen, Audiomitschnitte, etc.) hinterlegen. Solche „Archivdateien“
bitte _nicht_ im git-Repo einpflegen -- diese Dateien sind meist sehr
groß und würden die Größe des Repositories rasch explodieren lassen.
Diese Dateien werden direkt auf den Webserver in ein bestimmtes
Verzeichnis geladen.

Für Dateinamen gibt es eine Besonderheit: Dateien und Verzeichnisse, die
mit einem Underscore (`_`) beginnen, werden nicht auf der Webseite
publiziert.


## Howtos

### Blogeinträge

Sämtliche Blogeinträge befinden sich im Verzeichnis `articles`. Um einen
neuen Blogeintrag zu erzeugen, muss für diesen hier ein neues
Verzeichnis mit folgendem Namensschema angelegt werden:

    nnnn-der-url-titel-des-artikels

Die ersten vier Stellen `nnnn` sind eine laufende Nummer der
Artikelverzeichnisse. Der Rest ergibt (zusammen mit dem Artikeldatum)
die URL des Blogartikels. Hier sollte der (verkürzte) Titel des
Blogartikels geändert werden; Leerzeichen werden durch Bindestriche
ersetzt.

Der Inhalt des Blogartikels steht in der Datei `index.md` (für mit
Markdown verfaßte Artikel). Zwingend erforderlich sind die
Metadaten-Angaben:

* `kind` (muss `article` sein)
* `created_at` -- das Erstellungsdatum im Format yyyy-mm-dd
* `title` -- die Überschrift

Optional können folgende Angaben gemacht werden:

* `subtitle` -- eine Unterüberschrift
* `author` -- der Name des Artikelautors
* `refers_to` -- Referenz auf eine Event- oder Projektseite. Dieser
  Artikel erscheint dann dort ebenfalls in der Artikelübersicht.

Ein Teil des Artikeltextes wird als Teasertext in Übersichten angezeigt.
Die Grenze wird durch eine Zeile mit der Markierung `<!--break-->`
markiert; sonst wird der erste Abschnitt benutzt.


### Veranstaltungen und Aktivitäten

Der Ordner `events` beinhaltet Termine, die vom CCCS veranstaltet
werden. Der Ordner `activities` enthält Termine, an denen der CCCS zwar
beteiligt, aber nicht der Veranstalter ist. `events` sind typischerweise
Termine der Vortragsreihe, `activities` Veranstaltungen, an denen jemand
vom CCCS als Sprecher/Diskussionspartner/Referent/... eingeladen ist.

Namensschema der Inhalte beider Ordner ist:

    yyyymm-kurze-beschreibung

Also Jahr und Monat der Veranstaltung sowie ein Extrakt des
Veranstaltungstitels. Nötig sind folgende Metadaten:

* `kind` (muss `event` sein)
* `title` -- die Überschrift
* `startdate` -- Datums- oder Zeitangabe im Format `yyyy-mm-dd` oder
  `yyyy-mm-ddThh:mm:ssZ` (wichtig: Das "T" und das "Z" müssen so
  stehenbleiben!)
* `enddate` oder `duration` -- Endweder ein Enddatum (Format wie
  `startdate`) oder eine Zeitdauer. Bei ganztägigen Ereignissen (also
  ohne Zeitangabe) muss diese im Format n`d` (also n Tage), sonst im
  Format n`h` (n Stunden) oder n`m` (n Minuten) erfolgen.
* `public` -- `true` oder `false`, je nachdem, ob es sich um eine für
  die Öffentlichkeit zugängliche Veranstaltung handelt (ist
  typischerweise nur für Termine, zu denen wir eingeladen sind, false).

Optional sind folgende Angaben:

* `speakers` -- ist eine Liste, wobei jeder Eintrag mindestens die Angabe
  `name` und optional den Zusatz `affiliation` besitzt. Das sieht
  beispielsweise also so aus:

          speakers:
            -
              name: einervonuns
              affiliation: CCC Stuttgart
            -
              name: einervonwoanders
              affiliation: andereorga
            -
              name: jemanddrittes

* `location` -- nochmal ein schwieriges Feld ;-) Eine Location kann eine
  ganze Reihe von Angaben beinhalten: `name`, `url`, `strasse`, `plz`,
  `lon` und `lat` -- oder die erneute Angabe `location`. In letzterem
  Fall werden die Angaben aus der Template-Datei in
  `content/_data/locations.yaml` übernommen.
* `material` -- Beinhaltet eine Liste, welche die Angaben `title` und
  entweder `file` oder `link` enthält. Beispiel:

          material:
            -
              title: Die Folien (PDF)
              file: vortrag.pdf
            -
              title: Quelltext auf github
              link: https://github.com/...

    In ersterem Fall wird auf eine Datei auf unserem Server verwiesen.
  Diese muss in einem Verzeichnis liegen, das _identisch_ zum Pfad des
  Artikels ist.
* `audio` -- Ein Dateiname, dessen zugehörige Datei (wie bei `file`-Angaben im
  Abschnitt `material`) im entsprechenden Datenverzeichnis auf dem
  Server liegen muss.

#### Erzeugen der Flyer

Um zu einem Termin (beispielsweise `events/201301-fahrrad-illumination`)
den zugehörigen Flyer zu erzeugen, gibt es ein spezielles
nanoc-Kommando:

    nanoc create-flyer events/201301-fahrrad-illumination

Dieser erzeugt im Verzeichnis des Artikels SVG- und PDF-Dateien für
Flyer und Aushang. Meistens ist das Ergebnis adäquat, manchmal muss man
nochmals etwas nacharbeiten. Ist das Ergebnis bereits ok, bitte die
SVG-Dateien wieder löschen und _nur_ die PDF-Dateien ins git-Repositroy
aufnehmen. Ansonsten die SVG-Dateien bearbeiten und _sowohl_ SVG _als
auch_ PDF-Daten committen. Da die SVG-Dateien mit einem `_` beginnen,
landen sie nicht auf dem Webserver.

Möchte man die Dateien in einem anderen Verzeichnis erzeugen, kann man
dem obigen nanoc-Kommando einen Ausgabepfad als weiteren Parameter
anhängen.


### Sonstige Chaos-Termine

Diverse weitere Termine erscheinen nur in der Kalenderübersicht und der
iCal-Datei. Diese befinden sich als Liste in der Datei
`content/_data/chaosevents.yaml`. Die einzelnen Einträge haben dieselben
Metadaten wie die oben beschriebenen Events.


### Stammtisch-Termine

Auch die Stammtischtermine befinden sich in einer separaten Datei:
`content/_data/stammtisch.yaml`. Um die Termine für ein Jahr an den
typischen Terminen zu erzeugen, gibt es im Verzeichnis `scripts` das
Skript `generate-stammtisch.rb`. Als Parameter erhält es eine
Jahreszahl. Die Ausgabe kann dann mit der bestehenden
`stammtisch.yaml`-Datei zusammengeführt werden.


