Exponential 6.0 konfigurieren #

Diese Anleitung konfiguriert eine Installation von Exponential 6.0, sobald sie installiert ist: wo Einstellungen liegen und welche Datei gewinnt, die Siteaccesses und ihre Adressen, Sprachen, die Datenbank, E-Mail, Caches, Dateiablage und Sitzungen, Sicherheit, die Extensions, die Cronjobs, Debugging und Logs, das Hilfecenter und die Website-Werkzeugleiste. Sie setzt eine funktionierende Installation aus Exponential 6.0 installieren voraus. Jeder Abschnitt nennt die Einstellungen, zeigt ein funktionierendes Beispiel und verweist auf die Seite mit allen Einzelheiten. So bleibt diese Seite die Landkarte und die tieferen Seiten bleiben die Referenz.

Jeder Befehl wird im Wurzelverzeichnis der Installation ausgeführt: dem Verzeichnis, das index.php, autoload.php, bin/ und settings/ enthält. Die Befehlskonsole ist bin/php/console; viele Installationen legen die Verknüpfung ./console an (ln -s bin/php/console console). Wenn Sie ein Skript als root ausführen, ergänzen Sie --allow-root-user; das Skript weist Sie darauf hin, wenn es nötig ist.

Ändern Sie nie die Vorgaben. Die Dateien direkt in settings/ (settings/site.ini, settings/file.ini und die übrigen) und die settings/-Verzeichnisse der Extensions werden bei jedem Update ersetzt. Legen Sie jede eigene Änderung in settings/override/ oder settings/siteaccess/<siteaccess>/ ab, als .ini.append.php-Datei. Ein Update behält sie dann, und die Einstellungsseite und exp:ini zeigen genau, woher jeder Wert kommt.

Inhalt #

1. Der Schnellstart: eine Einstellung sicher ändern
2. Wo Einstellungen liegen und welche Datei gewinnt
3. Siteaccesses und ihre Adressen
4. Sprachen
5. Datenbank, E-Mail, Ablage und Sitzungen
6. Caches
7. Sicherheit
8. Extensions
9. Cronjobs
10. Velocity, Apache und PHP-FPM: wann eine Änderung wirkt
11. Debugging und Logs
12. Das Hilfecenter und die Website-Werkzeugleiste
13. Fehlerbehebung

1. Der Schnellstart: eine Einstellung sicher ändern #

Es gibt zwei Wege, eine Einstellung zu ändern, und beide schreiben dieselben Dateien.

In der Administration: Öffnen Sie Setup > INI-Einstellungen (settings/view), wählen Sie eine INI-Datei und einen Siteaccess und klicken Sie neben der Einstellung auf Bearbeiten. Speichern in bietet Nur Siteaccess Name (settings/siteaccess/<siteaccess>/), Jeder Siteaccess (globaler Override) (settings/override/) oder eine Extension an. Das Speichern leert den INI-Cache, sodass die nächste Anfrage den neuen Wert verwendet. Jede Einstellung zeigt den wirksamen Wert, die Datei, aus der er kommt, und jede andere Datei, die sie setzt. Passwörter, Schlüssel und Tokens werden verborgen. Der vollständige Rundgang: Die Einstellungsseite.

Von einer Shell aus: exp:ini liest und schreibt dieselben Bereiche. Es ändert zeilenweise, sodass die Kommentare und die Reihenfolge der Datei so bleiben, wie Sie sie geschrieben haben:

./console exp:ini where site.ini/SiteSettings/SiteName                  # welche Datei gewinnt, und die Kette
./console exp:ini get site.ini/SiteSettings/SiteName global
./console exp:ini set site.ini/SiteSettings/SiteName "Meine Website" global --dry-run
./console exp:ini set site.ini/SiteSettings/SiteName "Meine Website" global
./console exp:ini toggle site.ini/DebugSettings/DebugOutput siteaccess:admin   # enabled <-> disabled
./console exp:ini scopes                                                 # jeder Ort, in den Sie schreiben können

Die Bereiche sind global (settings/override/), siteaccess:<sa>, extension:<ext> und extension:<ext>:siteaccess:<sa>. Die Vorgaben (default, settings/<datei>.ini) werden abgelehnt, außer Sie ergänzen --allow-default. Die Referenz: Einstellungen von der Kommandozeile ändern: exp:ini und console exp:ini.

Mit einem Texteditor: Eine Override-Datei ist PHP, das den INI-Text in einem Kommentar versteckt, sodass ein Browser, der sie anfordert, eine leere Seite erhält:

<?php /* #?ini charset="utf-8"?

[SiteSettings]
SiteName=Meine Website

*/ ?>

Leeren Sie danach den INI-Cache: php bin/php/ezcache.php --clear-tag=ini. config.php schaltet die Prüfung der Dateizeiten ab (EZP_INI_FILEMTIME_CHECK), deshalb wird eine im Editor geänderte Datei erst nach diesem Leeren neu gelesen. Unter Velocity brauchen einige Einstellungen zusätzlich einen Neustart (Abschnitt 10).

2. Wo Einstellungen liegen und welche Datei gewinnt #

Vollständige Anleitung: Die Einstellungsseite

Jede INI-Datei wird in Schichten gelesen. Eine spätere Schicht gewinnt: Sie ersetzt einen einfachen Wert und ergänzt ein Array, außer sie leert es zuerst.

Das ist die Reihenfolge von eZINI::overrideDirsByScope() (lib/ezutils/classes/ezini.php): nach den Vorgaben die Scopes sa-extension, siteaccess, extension und override. Zu Schicht 3 gehören auch settings/override/ und settings/override__<gruppe>/ einer Extension, solange einer ihrer eigenen Siteaccesses läuft (Website-Einstellungen in Extensions); all das bleibt unter dem eigenen Verzeichnis des Siteaccess.

Innerhalb einer Schicht gewinnt die zuerst genannte Extension: Jede Extension wird vor die vorherigen gestellt, die zuerst genannte also zuletzt gelesen. Mit [ExtensionSettings] ExtensionOrdering=enabled (der Vorgabe) wird die Liste zuvor nach den Abhängigkeiten in jeder extension.xml sortiert: Eine Extension kommt nach den Extensions, die sie benötigt oder nutzt, und vor denen, die sie erweitert (Die Extensions-Seite). ./console exp:ini where <datei>/<Block>/<Einstellung> <siteaccess> listet die Dateien einer Einstellung in der Reihenfolge, in der sie gelesen werden.

Was eine Zeile mit dem Wert davor macht:

settings/override/ gewinnt also für jeden Siteaccess über alles. Verwenden Sie es für das, was überall gleich ist (die Datenbank, E-Mail, die aktiven Extensions), und settings/siteaccess/<siteaccess>/ für das, was zu einem Siteaccess gehört (sein Design, seine Sprachen, seine Debug-Ausgabe).

Eine Extension in ActiveExtensions[] gewinnt trotzdem gegen den Siteaccess: Setzt sie denselben Wert, bleibt die Zeile in settings/siteaccess/<siteaccess>/ ohne Wirkung, und ein Array, das sie füllt, lässt sich dort nicht leeren. Kein Verzeichnis, das zu einem Siteaccess gehört, wird nach den aktiven Extensions gelesen; das eigene settings/siteaccess/<siteaccess>/ einer Extension wird vor dem Verzeichnis des Siteaccess gelesen und hilft daher nicht. Für einen Wert eines Siteaccess, der gegen eine Extension gewinnen muss:

• aktivieren Sie diese Extension in ActiveAccessExtensions[] der Siteaccesses, die sie brauchen, statt in ActiveExtensions[]: Ihre Einstellungen werden dann vor denen des Siteaccess gelesen;
• oder, wenn die Extension Ihre eigene ist, nehmen Sie den Wert aus ihrem settings/ heraus und setzen ihn pro Siteaccess;
• oder setzen Sie ihn in settings/override/, wenn derselbe Wert für jeden Siteaccess gelten darf.

Drei weitere Schichtungen, für größere Installationen:

• Pro Umgebung: Mit EXP_ENV in config.env.php wird eine Variante wie settings/override/site.ini.test.append.php neben der normalen Datei gelesen, sodass eine Testkopie E-Mails in Dateien schreiben kann, ohne dass nach einer Bereitstellung etwas bearbeitet werden muss. Siehe Einstellungen pro Umgebung.
• Pro Website in einer Extension: Eine Extension, die eine Website einer Multisite-Installation enthält, kann ein eigenes settings/override/ mitbringen, das nur gilt, solange einer ihrer Siteaccesses läuft. Siehe Website-Einstellungen in Extensions.
• Umgebungsvariablen für die Werte, die je Server oder Container verschieden sind: siehe Umgebungsvariablen.

Jede Einstellung jeder Datei ist mit ihrer Vorgabe und einem Beispiel unter Beispiele der INI-Einstellungen beschrieben, zum Beispiel site.ini [SiteSettings].

3. Siteaccesses und ihre Adressen #

Alle Einzelheiten: Siteaccess nach Host-Präfix und die Weiterleitung zur Sprache

Ein Siteaccess ist ein Gesicht der Installation, mit eigenem Design, eigenen Sprachen und Einstellungen. Eine neue Installation hat drei, immer site (Besucher), admin (Administratoren) und editor (die Administration nur für Inhalte) genannt. Welcher eine Anfrage beantwortet, entscheidet site.ini [SiteAccessSettings]:

Drei verbreitete Aufteilungen:

# settings/override/site.ini.append.php: ein Host, der Siteaccess als erstes Pfadsegment
#   https://example.com/site/...   https://example.com/admin/...
[SiteAccessSettings]
MatchOrder=uri
URIMatchType=element

# Ein Host pro Siteaccess: https://www.example.com, https://admin.example.com, https://edit.example.com
[SiteAccessSettings]
MatchOrder=host
HostMatchType=map
HostMatchMapItems[]
HostMatchMapItems[]=www.example.com;site
HostMatchMapItems[]=admin.example.com;admin
HostMatchMapItems[]=edit.example.com;editor

# Ein Port pro Siteaccess (Entwicklung, oder Velocity auf mehreren Ports)
[SiteAccessSettings]
MatchOrder=port

[PortAccessSettings]
8080=site
8081=admin
8082=editor

Jeder Siteaccess setzt dann seine eigene Adresse in settings/siteaccess/<siteaccess>/site.ini.append.php: [SiteSettings] SiteURL (Host und Pfad, die Links und E-Mails verwenden, zum Beispiel www.example.com), SiteName und DefaultPage. Ein Siteaccess wird durch sein Design ([DesignSettings] SiteDesign=admin4) und das Administrationsmenü ([AdminSiteAccessMenu]) zu einer Administration. Wie die Reihenfolge der Siteaccess-Liste gehalten wird: Die Reihenfolge der Siteaccesses. Der Editor-Siteaccess: Der Einrichtungsassistent und der Editor-Siteaccess. Ein öffentlicher Siteaccess kann seine Besucher mit einem Klick zwischen Designs wechseln lassen: Designs eines öffentlichen Siteaccess umschalten.

Leeren Sie nach einer Änderung der Zuordnung den INI-Cache und prüfen Sie jede Adresse. Antwortet die Administration nicht mehr, lesen Sie die Fehlerbehebung.

4. Sprachen #

Vollständige Anleitung: Inhaltssprachen

Die Sprachen werden pro Siteaccess in site.ini [RegionalSettings] gesetzt:

# settings/siteaccess/site_ger/site.ini.append.php: eine deutsche Website, die auf Englisch zurückfällt
[RegionalSettings]
Locale=ger-DE
ContentObjectLocale=ger-DE
SiteLanguageList[]
SiteLanguageList[]=ger-DE
SiteLanguageList[]=eng-GB

Eine Sprache wird der Installation einmal unter Setup > Sprachen hinzugefügt. Ihre Locale-Datei in share/locale/ liefert Namen, Formate und Schreibrichtung, und die Administration ist in vielen Sprachen vollständig übersetzt. Die Liste der Locales und wie vollständig jede Übersetzung ist: Sprachen in Exponential. Sprachen unter eigenem Pfad (/ger, /eng) und die Weiterleitung von / zur Sprache des Besuchers: Siteaccess nach Host-Präfix und die Weiterleitung zur Sprache. Mehr: Übersetzungen und Sprachen.

5. Datenbank, E-Mail, Ablage und Sitzungen #

Datenbank #

site.ini [DatabaseSettings], in settings/override/site.ini.append.php (der Installer schreibt sie dorthin):

[DatabaseSettings]
# ezmysqli, ezpostgresql, sqlite3, mongodb oder ezoracle (Extension ezoracle)
DatabaseImplementation=ezmysqli
Server=localhost
Port=
User=exponential
Password=
Database=exponential
Charset=utf-8

Halten Sie das Passwort aus der Versionsverwaltung heraus: settings/override/ wird nie eingecheckt. Ein Wechsel der Datenbank-Engine braucht dieselben Daten in der neuen Datenbank; siehe Upgrade und das Datenbankkapitel des Installationsbuchs. SQLite unter Produktionslast: Exponential 6.0 installieren, Abschnitt 9. Jede Einstellung: [DatabaseSettings].

E-Mail #

site.ini [MailSettings] entscheidet, wie E-Mails den Server verlassen und wer sie sendet:

# settings/override/site.ini.append.php
[MailSettings]
Transport=SMTP
TransportServer=smtp.example.com
TransportPort=587
TransportConnectionType=tls
TransportUser=[email protected]
TransportPassword=
AdminEmail=[email protected]
EmailSender=no[email protected]

Eine Test- oder Staging-Kopie sollte Transport=file verwenden, am besten in einer Umgebungsvariante (Abschnitt 2), damit sie nie echten Menschen schreibt. Mehr: [MailSettings], Härtung des Mailversands, Mail-Layout und E-Mail-Einstellungen.

Dateiablage und Cluster #

Hochgeladene Dateien und Bilder liegen in var/storage/ (site.ini [FileSettings] VarDir=var, StorageDir=storage), Caches in var/cache/, Logs in var/log/. Eine Multisite-Installation kann jeder Website ein eigenes Verzeichnis geben: Log- und Cache-Pfade pro Website.

Mehrere Webserver, die eine Website teilen, teilen die Dateien über den Cluster-Datei-Handler, file.ini [ClusteringSettings] FileHandler: eZFSFileHandler (die Vorgabe, ein Server) oder eZDFSFileHandler (ein gemeinsames Laufwerk, [eZDFSClusteringSettings] MountPointPath, mit den Metadaten der Dateien in der Datenbank über DBBackend). Jede Einstellung: [ClusteringSettings].

Sitzungen und „Angemeldet bleiben“ #

Vollständige Anleitung: Sitzungen

site.ini [Session]: SessionTimeout ist, wie lange eine Sitzung nach ihrer letzten Nutzung lebt, RememberMeTimeout, wie lange der Browser das Cookie behält, wenn Angemeldet bleiben angehakt ist. Beide sind standardmäßig 31104000 Sekunden (360 Tage), und das Kästchen ist auf den Anmeldeformularen vorausgewählt, weil Browser auf Telefonen reine Sitzungs-Cookies von selbst verwerfen. Verkürzen Sie sie für eine Website mit sensiblen Daten:

[Session]
SessionTimeout=1209600
RememberMeTimeout=1209600

Wer angemeldet ist, und Browser abmelden: Setup > Sitzungen (Sitzungen); die eigenen Geräte eines Benutzers: Ihre Geräte und Sitzungen.

6. Caches #

Vollständige Anleitung: Caches

Die Caches sind standardmäßig an und sollten an bleiben: site.ini [TemplateSettings] TemplateCache=enabled (kompilierte Templates), [ContentSettings] ViewCaching=enabled (gerenderte Seiten, beim Veröffentlichen geleert). Leeren Sie den kleinsten, der das Problem behebt:

Dieselben Gruppen stehen unter Setup > Cache-Verwaltung. Zwei weitere Schichten, beide standardmäßig aus:

• Der statische Cache ([ContentSettings] StaticCache=enabled, settings/staticcache.ini) schreibt fertige Seiten als Dateien, die der Webserver ohne PHP beantwortet: Der Generator des statischen Caches. Eine statische Kopie auf GitHub Pages oder einem beliebigen Git-Host veröffentlichen: Statisches Veröffentlichen.
• Der Antwort-Cache von Velocity beantwortet wiederholte Anfragen aus dem Speicher: Der Antwort-Cache von Velocity.

Die Caches nach einer Bereitstellung aufwärmen: Caches vorladen.

7. Sicherheit #

Vollständige Anleitung: Sicherheit und Audit

HTTPS und die Sicherheits-Header #

Liefern Sie jeden Siteaccess über HTTPS aus (Exponential 6.0 installieren, Abschnitt 8). site.ini [HTTPHeaderSettings] SecurityHeaders[] sendet X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy und eine frame-ancestors-Richtlinie mit jeder Seite. Sobald die ganze Website nur noch HTTPS spricht, schalten Sie HSTS ein:

# settings/override/site.ini.append.php
[HTTPHeaderSettings]
SecurityHeaders[Strict-Transport-Security]=max-age=31536000

Die Content Security Policy #

site.ini [ContentSecurityPolicy] Mode ist disabled, report-only, enforce oder auto (die Vorgabe: report-only in den Administrations-Siteaccesses, keine Richtlinie auf den Websites). Directives[] listet, was eine Seite laden darf. Beobachten Sie zuerst die Berichte und erzwingen Sie dann: Content Security Policy.

Hinter einem Proxy oder Load Balancer #

Weitergeleitete Header (X-Forwarded-For, X-Forwarded-Proto und die übrigen) werden nur von den Adressen in site.ini [HTTPHeaderSettings] TrustedProxies[] geglaubt (standardmäßig nur von dieser Maschine). Ergänzen Sie die Adresse oder den Bereich Ihres Proxys; für die Adresse des Besuchers setzen Sie zusätzlich ClientIpByCustomHTTPHeader=X-Forwarded-For:

[HTTPHeaderSettings]
TrustedProxies[]
TrustedProxies[]=127.0.0.1
TrustedProxies[]=10.0.0.0/8
ClientIpByCustomHTTPHeader=X-Forwarded-For

Siehe Vertrauenswürdige Proxys.

Zweistufige Anmeldung und „Bestätigen Sie, dass Sie es sind“ #

• Die zweistufige Anmeldung (die Extension sevenx_authentication_2fa, von den Installern aktiviert) fragt nach dem Passwort einen Code aus einer Authenticator-App oder per E-Mail ab, im Anmeldeformular. WebDAV, die Basic-Authentifizierung der REST-API und SOAP fragen nur das Passwort ab; halten Sie sie dort aus oder begrenzt, wo der zweite Schritt Pflicht ist. Einschalten und verlangen: Zweistufige Anmeldung. Passkeys: Passkeys.
• „Bestätigen Sie, dass Sie es sind“ lässt einen angemeldeten Benutzer vor einer sensiblen Aktion erneut bestätigen (das eigene Konto, Benutzer und Rollen, Systemeinstellungen, Exporte, Löschungen). Fünf Gruppen sind standardmäßig an; die sechste, Inhalte, wird unter Setup > Verify it's you (/setup/reauth) eingeschaltet. Siehe Bestätigen Sie, dass Sie es sind.

Geheimnisse #

Passwörter und Schlüssel, die Werkzeuge brauchen (Verbindungen von Datentabellen, Importquellen, entfernte Server), gehören in den Geheimnisspeicher, nicht in eine INI-Datei: Setup > Geheimnisse (Richtlinie secrets/manage). Ein Werkzeug behält nur den Namen eines Geheimnisses. Ein Name env:<VARIABLE> liest stattdessen eine Umgebungsvariable des PHP-Prozesses, was zu Containern passt. Die Werte sind mit einem Schlüssel verschlüsselt, der nicht in der Datenbank liegt (EXP_SECRET_KEY oder var/secrets/exp_secret.key): Sichern Sie den Schlüssel mit der Datenbank. Siehe Der Geheimnisspeicher.

Rollen und Richtlinien #

Jeder Benutzer erhält seine Rechte über Rollen: Eine Rolle ist eine Liste von Richtlinien (Modul und Funktion, mit Einschränkungen), die einem Benutzer oder einer Benutzergruppe zugewiesen wird, wahlweise begrenzt auf einen Teilbaum oder eine Sektion. Beginnen Sie mit den Rollen einer neuen Installation (Anonymous, Editor, Administrator; ein Website-Paket kann weitere ergänzen, etwa Member), kopieren Sie eine, statt sie zu ändern, und vergeben Sie die kleinste Menge, die funktioniert. Rundgang: Rollen und Richtlinien. Jede Änderung wird im Audit-Protokoll festgehalten.

8. Extensions #

Vollständige Anleitung: Die Extensions-Seite

Eine Extension ist aktiv, wenn sie in site.ini [ExtensionSettings] ActiveExtensions[] (jeder Siteaccess, in settings/override/) oder ActiveAccessExtensions[] (ein Siteaccess, in settings/siteaccess/<siteaccess>/) steht. Die Reihenfolge der Liste ist die Ladereihenfolge, bei ExtensionOrdering=enabled nach den Abhängigkeiten in extension.xml sortiert: Die zuerst genannte Extension gewinnt, bei Templates wie bei Einstellungen. Die Einstellungen aus ActiveExtensions[] gewinnen außerdem gegen die des Siteaccess selbst, die aus ActiveAccessExtensions[] nicht (Abschnitt 2).

• Setup > Extensions (/setup/extensions) aktiviert, deaktiviert und ordnet sie, prüft ihre Abhängigkeiten und schreibt die Liste für Sie.
• Von einer Shell aus: ./console exp:ini add site.ini/ExtensionSettings/ActiveExtensions[] meineextension global.
• Erzeugen Sie nach dem Aktivieren die Autoloads neu (php bin/php/ezpgenerateautoloads.php -e) und leeren Sie die Caches (oder ./console exp:velocity deploy).

Eine Extension, die share/db_schema.dba mitbringt, erhält ihre Tabellen, wenn sie während der Installation aktiviert wird. In einer bestehenden Installation legt der Upgrade-Schritt 6.0.15-active-extension-tables (./console exp:upgrade) die fehlenden Tabellen jeder aktiven Extension an; nichts wird gelöscht. Welche Extensions eine neue Installation von 6.0.15 hat und einschaltet und woher ihre Tabellen kommen: Extensions einer neuen Installation. Die Ladereihenfolge im Einzelnen: Ladereihenfolge der Extensions. Eigene bauen: Extensions.

9. Cronjobs #

Vollständige Anleitung: Cronjobs

Die Cronjobs veröffentlichen geplante Inhalte, senden Benachrichtigungen und Newsletter und räumen auf. Sie sind in cronjob.ini in Teile gruppiert ([CronjobSettings] Scripts[] ist der globale Teil, [CronjobPart-<name>] die übrigen). Listen Sie sie auf und tragen Sie sie in die Crontab des Website-Benutzers ein, mit Ihrem öffentlichen Siteaccess:

php runcronjobs.php --list

*/5 * * * * cd /pfad/zur/installation && php runcronjobs.php --siteaccess=site frequent >> var/log/cron-frequent.log 2>&1
17 * * * *  cd /pfad/zur/installation && php runcronjobs.php --siteaccess=site infrequent >> var/log/cron-infrequent.log 2>&1

Setup > Cronjobs führt einen Teil aus und zeigt seine Ausgabe und seinen letzten Lauf. Der Planer von Velocity kann sie ohne den System-Cron ausführen. Einen Teil pausieren: Cronjobs pausieren; von der Konsole: Cronjobs von der Konsole.

10. Velocity, Apache und PHP-FPM: wann eine Änderung wirkt #

Alle Einzelheiten: Die Einstellungsseite, „Wann die Änderung wirksam wird“

Die Einstellungen sind für beide Server dieselben; verschieden ist, wann eine Änderung verwendet wird.

Die Einstellungen, die einen Neustart von Velocity brauchen, stehen in site.ini [SettingsViewSettings] RestartSettingList[]; die Einstellungsseite kennzeichnet sie mit Velocity-Neustart. Nach einer Bereitstellung von Code oder Einstellungen führt ein Befehl jeden Schritt in der richtigen Reihenfolge aus (Autoloads, Caches, das Neuladen von FPM, der Neustart von Velocity): ./console exp:velocity deploy. Die eigene Konfiguration von Velocity: Der Webserver Velocity; seine HTTPS-Zertifikate: HTTPS-Zertifikate von Velocity.

11. Debugging und Logs #

Alle Einzelheiten: Die Debug-Leiste

Die Debug-Ausgabe ist standardmäßig aus und sollte für Besucher aus bleiben. Schalten Sie sie nur für Ihre eigene Adresse ein:

# settings/override/site.ini.append.php
[DebugSettings]
DebugOutput=enabled
DebugByIP=enabled
DebugIPList[]
DebugIPList[]=192.0.2.10

Oder für einen Siteaccess, während Sie daran arbeiten: ./console exp:ini toggle site.ini/DebugSettings/DebugOutput siteaccess:admin. [TemplateSettings] Debug=enabled kennzeichnet die Templates, die die Seite geschrieben haben, mit HTML-Kommentaren (auch in E-Mails, verwenden Sie es also nur auf einer Entwicklungskopie). Jede Debug-Einstellung: [DebugSettings].

Die Logs liegen in var/log/ (mit Log-Verzeichnissen pro Website in var/<site>/log/): error.log, warning.log, notice.log, debug.log sowie die Cron- und Mail-Logs. Lesen Sie sie in der Administration unter Setup > Logdateien (Der Log-Betrachter); sie werden rotiert, wenn eines [FileSettings] LogFileMaxSize überschreitet (Log-Rotation). Eine Fehlerseite nennt eine Referenz: Einen Fehler über seine Referenz finden.

12. Das Hilfecenter und die Website-Werkzeugleiste #

Das Hilfecenter (exphelp) zeigt diese Dokumentation in der Administration, in der Sprache des Lesers, wenn es eine Übersetzung gibt. Seine Einstellungen stehen in settings/exphelp.ini: die Sprachen der Dokumentation ([DocLanguages]), was die Suche gewichtet ([SearchSettings]), die Reihenfolge der Seiten im Baum ([TreeSettings] PageOrder[]) und die Einstiegsseiten pro Zielgruppe. Die Richtlinie exphelp/read öffnet es. Siehe Das Hilfesystem und Hilfeinhalte.

Die Website-Werkzeugleiste (expwt) ist die Seitenleiste, mit der Sie die Website auf ihren eigenen Seiten bearbeiten: bearbeiten, anlegen, verschieben und veröffentlichen, wo Sie lesen. Sie wird in expwt.ini [ExpwtSettings] eingestellt:

Wer sie sieht, entscheiden die Richtlinien expwt/*: Eine neue Installation gibt sie nur den Rollen Administrator und Editor, nie Anonymous. Eine Installation, die noch die alte Werkzeugleiste ezwt verwendet, wechselt mit ./console exp:wt:migrate-from-ezwt --apply. Siehe Extensions einer neuen Installation, „ezwt und expwt“.

Weiter geht es mit den Anleitungen:

• Betrieb einer Website: Caches, Cronjobs, Backups, Logs und Reparaturen.
• Bereitstellung: die Website mit Apache und PHP-FPM, Velocity oder FrankenPHP über HTTPS ausliefern.
• Sicherheit und Audit: die Härtung prüfen, Rollen und Richtlinien, das Audit-Protokoll.
• Templates und Design: das Template finden, das eine Seite geschrieben hat, es überschreiben, das Admin-Design wechseln.
• Exponential 6.0 aktualisieren: die Installation auf den neuesten Stand bringen und diese Einstellungen behalten.
• Jede Anleitung: der Lernpfad.

13. Fehlerbehebung #

Wenn die Tabelle nicht weiterhilft, zeigt Unterstützung erhalten, wo Sie fragen.

Mehr: Eine Installation reparieren, Betrieb einer Website.