NOOP> Dokumentation: Installation - Strict NOOP! Framework

Installation

Einleitung

Auf dieser Seite erfahren Sie, wie man das Framework installiert und in einem funktionierenden Zustand bringt. Auch wenn nur Teile dieser Anleitung für Sie relevant sind, empfiehlt es sich trotzdem sich wenigstens einmal alles durchgelesen zu haben. Einige Informationen könnten sich auf vorhergehende Punkte beziehen.

Übersicht

Die Installationsanleitung unterteilt sich in 5 Schritten, welche wie folgt lauten:

  1. Systemvoraussetzung prüfen
  2. Umgebung identifizieren
  3. Dateien und Verzeichnisse
  4. Konfiguration
  5. Test

1. Systemvoraussetzung prüfen

Bevor das Framework installieren kann, muss man sicherstellen, dass alle Systemvoraussetzungen erfüllt werden.

Webserver: Momentan wird nur Apache 2.2.x und 2.4.x unterstützt. Zudem ist es zwingend erforderlich, das mod_rewrite installiert ist. Mit entsprechenden Fachwissen ist es auch möglich, das Framework z.B. auch auf einem NGINX -Webserver zu betreiben.

PHP: Mindestens PHP v5.6.30 wird benötigt, unterhalb dieser Versionsnummer verweigert das Framework seinen Dienst. Bei PHP 5 muss auch das JSON-Modul php5-json installiert sein. Das Framework unterstützt auch PHP v7.x, was wenn möglich immer die erste Wahl sein sollte. Seit Version 1.103 unterstützt NOOP auch das Erzeugen von PDF-Rechnungen für das Bestellformular. Dafür kann dompdf installiert werden. Was dafür getan werden muss, kann in der Datei /include/pdf/readme.txt nachgelesen werden.

Datenbank: Das Framework liefert Code mit, mit dem man auf MySQL bzw. MariaDB -Datenbanken zugreifen könnte, allerdings ist dies rein optional, da das Framework in der Grundausstattung keine Datenbank benötigt.

2. Umgebung identifizieren

Bevor man anfängt das Framework hochzuladen oder ähnliches, sollte man zuerst feststellen, wie das Framework installiert werden muss. Das Framework kann auf 3 verschiedene Arten installiert werden, wobei es je nach Art Vorteile und Nachteile gibt. Die Unterscheidung dabei ist, wo sich der Document-Root des Webservers befindet und wo genau man das Framework im Document-Root installiert. Je nachdem welche der 3 Arten man verwendet, muss das Framework und mod_rewrite dementsprechend konfiguriert werden. Folgende mit Namen versehende 3 Arten gibt es:

slack = Locker

Mit slack ist in etwa der Standardweg und bedeutet, dass das Framework direkt im Document-Root des Webservers abgelegt wird. Da der Einstiegspunkt public/index.php ist, leitet mod_rewrite aus der Sicht des Webservers in das public-Verzeichnis weiter.

  • Sehr kompatibel zu vielen Hostinganbieter.
  • Erfordert keine Änderung an der Webserver-Konfiguration.
  • Relativ unsicher, da sich alles vom Framework innerhalb des Webspace befindet.

Beispiel:

Document-Root des Webservers: /var/www
Absoluter Pfad zum Framework: /var/www
URL-Pfad (Basispfad): /
Aufruf im Browser: http://beispiel.de/index.html
mod_rewrite: http://beispiel.de/public/index.php?index.html

strict = Streng

Bei strict hat man die höchste Sicherheit. Das bedeutet, dass das Framework selbst nicht komplett innerhalb des Document-Root abgelegt ist, sondern das der Webserver so konfiguriert ist, das der Document-Root auf das public-Verzeichnis zeigt. Der Einstiegspunkt ist somit aus der Sicht des Webservers direkt index.php.

  • Inkompatibel zu Hostinganbieter.
  • Erfordert Änderungen an der Webserver-Konfiguration.
  • Sehr sicher, da sich nur der Inhalt von public im Webspace befindet.

Beispiel:

Document-Root des Webservers: /var/www/public
Absoluter Pfad zum Framework: /var/www
URL-Pfad (Basispfad): /
Aufruf im Browser: http://beispiel.de/index.html
mod_rewrite: http://beispiel.de/public/index.php?index.html

sub = Unter/Neben

Die Variante sub ist mit slack nahezu identisch. Der Unterschied ist nur, dass sich das Framework nicht direkt im Document-Root selbst befindet, sondern in einem beliebigen Unterverzeichnis innerhalb des Document-Root. Das ist besonders dann sinnvoll, wenn man z.B. mehrere Installationen des Frameworks auf einen einzigen kanonischen Namen (Adresse) verwenden will. Da der Einstiegspunkt public/index.php ist, leitet mod_rewrite aus der Sicht des Webservers in das public-Verzeichnis weiter, sobald der Aufrufer den URL-Pfad zum Framework enthält.

  • Sehr kompatibel zu Hostinganbieter.
  • Erfordert keine Änderung an der Webserver-Konfiguration.
  • Relativ unsicher, da sich alles vom Framework innerhalb des Webspace befindet.

Beispiel:

Document-Root des Webservers: /var/www
Absoluter Pfad zum Framework: /var/www/framework/noop
URL-Pfad (Basispfad): /framework/noop
Aufruf im Browser: http://beispiel.de/framework/noop/index.html
mod_rewrite: http://beispiel.de/framework/noop/public/index.php?index.html

3. Dateien und Verzeichnisse

Bevor Sie die Dateien und Verzeichnisse auf dem Server installieren, bekommen Sie nun erstmal eine Strukturübersicht, wofür die Dateien und Verzeichnisse da sind. Das soll dabei helfen, das Framework besser zu verstehen.

Struktur

Aktuell besteht das Framework aus mehreren Dateien und Verzeichnissen. Im Stammverzeichnis vom Framework findet man ebenfalls mehrere Dateien, wobei diese entweder Beschreibungstexte sind, oder die vom Framework zwei benötigten Konfigurationsdateien.

  • / = das Verzeichnis vom Framework selbst.
  • /core/ = Kernkomponenten des Frameworks.
    • /core/data/ = statische Datentabellen.
  • /data/ = Datenverzeichnis, wo das Framework Schreibrechte hat. Wie z.B. die Sitemap-Daten und die Suchdatenbank.
    • /data/log/ = Verzeichnis der Logdateien.
    • /data/session/ = speichert alle Sitzungsdaten, wie z.B. den Login der Benutzer.
    • /data/tmp/ = temporäres Verzeichnis vom Framework.
  • /include/ = Verzeichnis, welches zusätzliche Funktionalitäten bereitstellt.
  • /language/ = Sprachdateien.
  • /model/ = enthält Komponenten für den Zugriff auf beliebige Datenstrukturen, z.B. Datenbanktabellen. (MVC: Model)
  • /page/ = enthält PHP-Dateien, die per URL angesprochen werden können und dynamische Inhalte ausgeben. (MVC: Controller)
  • /public/ = der öffentliche Teil des Frameworks.
    • /public/homepage/ = Benutzerdefiniertes Verzeichnis für eigene Bilder, Styles und Javascript.
    • /public/index.php = der Einstiegspunkt vom Framework.
  • /static/ = enthält beliebige statische Inhalte, die per URL angesprochen werden können.
    • /static/noop/ = statische Seiten über NOOP! Framework, die gegebenenfalls gelöscht werden können.
    • /static/noop/documentation/ = diese Dokumentation hier.
    • /static/noop/editor/ = Web-Editoren für Konfigurationen, die vom Framework verwendet werden.
    • /static/noop/reference/ = Quellcode-Referenz, zum Beschreiben der Funktionen vom Framework.
    • /static/noop/schema/ = JSON-Schemas für die Strukturbeschreibung von JSON-Dateien.
    • /static/noop/test/ = Testscripte von der Entwicklung.
    • /static/index.html = Standard-Startseite.
    • /static/menu.html = globales Menü (falls benötigt, anlegen).
  • /template/ = enthält die Templates der Webseite, welche von page und static benutzt werden können. (MVC: View)
  • /.htaccess = die aktuelle Apache-Konfiguration.
  • /.htaccess-dist = Vorlage der Apache-Konfiguration.
  • /config.json = die aktuell verwendete Framework-Konfiguration.
  • /config.json-dist = Vorlage der Framework-Konfiguration.

Installieren

Wenn man sich im Klaren ist, in welcher Umgebung man sich befindet (slack, strict, oder sub), dann kopiert bzw. lädt man den kompletten Inhalt des Framework-Verzeichnisses an den entsprechenden Ort. Beispielsweise bei der slack-Variante wäre das Zielverzeichnis /var/www selbst.

Nachdem alle Inhalte kopiert bzw. hochgeladen wurden, sollte man auf jeden Fall überprüfen, das jedes Verzeichnis (mindestens auf 1. und 2. Ebene) eine .htaccess-Datei haben. Dadurch wird sichergestellt, dass man nicht doch noch von außen auf bestimmte Verzeichnisse zugreifen kann. Besonders bei slack und sub ist das enorm wichtig, da sich bei diesen Installationsmethoden das komplette Framework im Webspace befindet. Bei strict hingegen wäre das technisch gesehen überflüssig, da sich ja alles bis auf public/ selbst nicht im Webspace befindet. Es sei auch dazu gesagt, dass dies nur eine von mehreren Sicherheitsmechanismen ist, die ein potenzieller Hacker durchbrechen muss, um wirklich Schaden anrichten zu können.

Nun muss man sicherstellen, das bestimmte Verzeichnisse Schreibrechte haben. Wie genau die Schreibrechte zu setzen sind, hängt von der jeweiligen Umgebung ab, wo sie das Framework installieren wollen. Im Zweifelsfall setzt man die Schreibrechte auch für den Gast, was z.B. sehr oft bei Hostinganbieter der Fall ist. Folgende Verzeichnisse sind dabei gemeint:

  • /data/ Allgemeines Verzeichnis mit Schreibrechten für das Framework. Wie z.B. die Sitemap-Daten und die Suchdatenbank.
  • /data/log/ = zum Schreiben der Logdateien.
  • /data/session/ = zum Schreiben der Sitzungsdaten (sofern benötigt).
  • /data/tmp/ = zum Schreiben sonstiger, temporärer Daten.

4. Konfiguration

Dieser Schritt unterteilt sich in 2 Unterpunkte, da wir 2 Konfigurationsdateien haben, welche angepasst werden müssen. Zuerst fängt man mit der .htaccess an, da mit ihr alles steht oder fällt.

Apache-Konfiguration (.htaccess)

Im Stammverzeichnis des Frameworks, sollte man eine .htaccess-dist-Datei finden. Diese kopiert man in das gleiche Verzeichnis, allerdings lässt man den Suffix -dist weg. Nun sollte man neben der .htaccess-dist-Datei auch eine .htaccess-Datei haben. Die -dist-Datei ist nur eine Vorlage und wird vom Webserver normalerweise komplett ignoriert. Die .htaccess-Datei selbst ist allerdings eine Datei die vom Webserver verarbeitet wird. Dort müssen wir nun Anpassungen durchführen.

Wenn man diese Datei nun öffnet, interessiert uns nur der untere Teil, sprich alles was nach # Customizations here # kommt. Der obere Teil ist für den korrekten Betrieb des Framework zuständig und musste bisher noch nie geändert werden. Das Doppelkreuz # stellt ein Kommentarzeichen dar, d.h. alles was nach dem # kommt, wird vom Webserver ignoriert. Nun wird wieder nach der Art der Umgebung unterschieden:

Bei slack reicht es aus, das wir die beiden Blöcke ganz unten wieder aktivieren, sprich die Kommentarzeichen entfernen. Sofern geschehen, kann man mit der Framework-Konfiguration fortfahren. Das sollte dann in etwa so aussehen:

# Allow all
<IfModule !mod_authz_core.c>
	Order Allow,Deny
	Allow from All
</IfModule>
<IfModule mod_authz_core.c>
	Require all granted
</IfModule>

# Rewrite into public
<IfModule mod_rewrite.c>
	RewriteEngine on
	RewriteBase /
	RewriteRule ^(.*)$ public/$1 [L]
</IfModule>

Bei strict muss man an dieser Datei nichts verändern, d.h. man kann mit der Framework-Konfiguration fortfahren.

Bei sub macht man genau dasselbe, wie bei slack und zusätzlich noch folgendes: Da wir bei sub ein oder mehrere Unterverzeichnisse zwischen Document-Root und dem Framework haben, müssen wir dort den Basispfad angeben. Wenn man bei Punkt 2 nachschaut und sich auf das Beispiel bezieht, müsste man die Zeile mit RewriteBase / durch RewriteBase /framework/noop ersetzen. Und nun kann man mit der Framework-Konfiguration fortfahren.

Framework-Konfiguration (config.json)

Im Stammverzeichnis des Frameworks, sollte man eine config.json-dist-Datei finden. Diese kopiert man in das gleiche Verzeichnis, allerdings lässt man den Suffix -dist weg. Nun sollte man neben der config.json-dist-Datei auch eine config.json-Datei haben. Die -dist-Datei ist nur eine Vorlage und wird vom Framework komplett ignoriert. Die config.json-Datei selbst ist allerdings eine Datei die vom Framework verarbeitet wird. Dort müssen wir nun Anpassungen durchführen.

In dieser Datei stehen etliche Konfigurationsangaben. Hier werden aber nur jene Angaben behandelt, die für die Installation wichtig sind. Eine Beschreibung zu allen Konfigurationsangaben finden Sie hier: Konfiguration. Das Dateiformat ist JSON, d.h. achten Sie beim editieren genau darauf, wie die Struktur aufgebaut ist.

Mit base gibt man den Basispfad an, im Prinzip genauso wie bei Punkt 2, bzw. bei der Apache-Konfiguration (.htaccess) beschrieben. Anders ausgedrückt: Bei slack und strict setzt man nur einen Slash /. Bei sub trägt man dort genau das Gleiche ein, wie bei RewriteBase in der .htaccess-Datei.

Mit defaultLangCode können wir die Sprache angeben. Dabei ist nur das zweistellige Kürzel erlaubt, welches de für deutsch ist.

Mit session.enabled wird gesteuert, ob Sitzungscookies für den Besucher angelegt werden sollen, z.B. wenn eine Login-Funktion benötigt wird. Wenn man das nicht braucht, stellt man den Wert auf false.

Bei session.domain müssen Sie den gültigen, kanonischen Namen der Domäne angeben, also entweder die vollständige Top-Level-Domain, mit der das Framework im Internet aufgerufen wird, oder die IP-Adresse des Webservers, wenn sie das Framework im lokalen Netz verwenden. Wichtig: Auch wenn keine sessions benötigt werden, muss diese Angabe korrekt sein.

Bei session.path trägt man das Gleiche ein, wie das, was man bei base eingetragen hat.

Zuletzt gibt es noch maintenanceMode.enabled. Solange dies auf true gesetzt ist, zeigt das Framework immer eine Wartungsmeldung an. Da die hier die Konfiguration abschließt, sollte man diese Einstellung auf false setzen.

5. Testen

Alle Schritte blind durchgehen und dann davon ausgehen das wird schon funktionieren, ist keine gute Idee. In diesen Schritt wird darauf eingegangen, wie man nun genau testet, ob das Framework nun richtig funktioniert oder nicht.

Zuerst sollte man in die Adresszeile des Browsers das eintragen, was man in der config.json bei session.domain eingetragen hat. Wenn der Aufruf klappt, sollte man die mitgelieferte Startseite zu sehen bekommen. Man kann an ihr auch schnell herausfinden, ob es an bestimmten Stellen noch Probleme gibt. Im Footer sollte man 2 Bilder sehen können (HTML5 und Tidy), falls nicht stimmt etwas mit dem Basispfad nicht. Wenn man eine Webserver-Fehlermeldung bekommt, stimmt irgendwas mit der Apache-Konfiguration (.htaccess) nicht.

Sofern das Framework das Verzeichnis /static/noop/test/ mitliefert, können Sie noop/test/links.html in die Adresszeile anfügen. In der links.html stehen alle möglichen Links drin, die in der Standardausführung des Frameworks funktionieren sollten. Wenn man all diese Links durchprobiert und man bekommt immer was zu sehen was keine Fehlermeldung vom Webserver oder ihr Browser ist, dann kann man davon ausgehen, dass Sie das Framework erfolgreich installiert haben.

⇧ Nach Oben