Navigation
🌍 Zurück zur Sprachauswahl 🌍
🏡 Startseite 🏡
🔨 Installation 🔨
🔧 Konfiguration 🔧
🌍 Zurück zur Sprachauswahl 🌍
🏡 Startseite 🏡
🔨 Installation 🔨
🔧 Konfiguration 🔧
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.
Die Installationsanleitung unterteilt sich in 5 Schritten, welche wie folgt lauten:
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.
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:
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.
Webspacebefindet.
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
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
.
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
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.
Webspacebefindet.
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
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.
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 pageund
staticbenutzt 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.
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.
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.
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
durch
RewriteBase /
ersetzen.
Und nun kann man mit der Framework-Konfiguration fortfahren.
RewriteBase /framework/noop
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
für deutsch ist.
de
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.
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
mitliefert,
können Sie
/static/noop/test/
in die Adresszeile anfügen.
In der noop/test/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.
links.html