Einstellungen und INI für CMS-Entwickler #

Diese Seite richtet sich an Entwickler, die Exponential-Projekte konfigurieren. Die gesamte Konfiguration besteht aus INI-Dateien, die in Schichten gelesen werden, und zu wissen, welche Schicht sich durchsetzt, ist der größte Teil der Arbeit. Die Regel für ein Projekt: Ändern Sie nie die mitgelieferten Dateien in settings/; legen Sie Ihre Werte in Ihre Erweiterung und rechnerspezifische Werte in settings/override/.

Inhalt #

1. Das Format
2. Die Geltungsbereiche und wer gewinnt
3. Wohin die Einstellungen eines Projekts gehören
4. exp:ini: sicher lesen und ändern
5. Einstellungen in der Administration
6. Werte, die sich je Rechner unterscheiden
7. Einstellungen in Templates und PHP lesen
8. Caches und Worker

Das Format #

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

[DesignSettings]
SiteDesign=exp_mysite
AdditionalSiteDesignList[]
AdditionalSiteDesignList[]=standard

[RegionalSettings]
TranslationSA[eng]=English
*/ ?>

Override-Dateien enden auf .ini.append.php und schließen ihren Inhalt in einen PHP-Kommentar ein, sodass ein Webserver, der die Datei ausliefert, nichts zeigt. Name[] ohne Wert leert ein Array, bevor die nächsten Zeilen etwas hinzufügen; Name[key]=value setzt einen Hash-Eintrag (Wie INI-Einstellungen funktionieren).

Die Geltungsbereiche und wer gewinnt #

Nach dem mitgelieferten Standard in settings/ liest der Kernel diese Verzeichnisse, und eine spätere Datei gewinnt:

1. die Ordner je Siteaccess einer Erweiterung (extension/<ext>/settings/siteaccess/<sa>/ und ihr override/),
2. settings/siteaccess/<sa>/,
3. extension/<ext>/settings/ jeder aktiven Erweiterung (eine Erweiterung, die in ActiveExtensions[] früher steht, gewinnt),
4. settings/override/.

Beachten Sie, dass die globalen Einstellungen einer Erweiterung nach settings/siteaccess/<sa>/ gelesen werden und sich also gegen diese durchsetzen (Geltungsbereiche der Einstellungen und ihre Reihenfolge).

Wohin die Einstellungen eines Projekts gehören #

Wenn Sie die Website-Einstellungen in Ihrer Erweiterung halten, liegt die ganze Website in einem Repository, und ein neuer Rechner braucht nur sein settings/override/ (Siteaccess-Einstellungen, Erweiterungseinstellungen für Website-Bauer).

exp:ini: sicher lesen und ändern #

./console exp:ini get site.ini/DesignSettings/SiteDesign -s <siteaccess>      # the value in effect
./console exp:ini where site.ini/DesignSettings/SiteDesign -s <siteaccess>    # every file that sets it, in load order
./console exp:ini list site.ini/DebugSettings                                  # a block
./console exp:ini set site.ini/DebugSettings/DebugOutput enabled global --dry-run --allow-root-user
./console exp:ini add 'site.ini/ExtensionSettings/ActiveExtensions[]' exp_mysite global --allow-root-user

where beantwortet "Warum ist dieser Wert nicht der, den ich gesetzt habe?" mit einem Aufruf. Schreibvorgänge legen eine Sicherung in var/backup/ini/ ab, leeren den INI-Cache und nehmen --dry-run an. Geltungsbereiche: global, siteaccess:<sa>, extension:<ext>, extension:<ext>:siteaccess:<sa>; das Schreiben der mitgelieferten Standards wird verweigert (Der Befehl exp:ini, exp:ini in der Konsole).

Einstellungen in der Administration #

Setup > INI-Einstellungen (settings/view) zeigt die Einstellungen jedes Siteaccess mit der Datei, aus der jeder Wert stammt, und kann für Administratoren Werte ändern (Die Einstellungsseite, Einstellungen in der Administration). Dort vorgenommene Änderungen landen in Dateien; kopieren Sie die, die zum Projekt gehören, in Ihre Erweiterung.

Werte, die sich je Rechner unterscheiden #

Zugangsdaten zur Datenbank, E-Mail-Transporte und Hostnamen unterscheiden sich zwischen Entwicklung, Staging und Live. Halten Sie sie im settings/override/ jedes Rechners, das nicht committet und nicht zwischen Rechnern kopiert wird. Einiges, das bekannt sein muss, bevor die Einstellungen gelesen werden, kommt aus Umgebungsvariablen und config.php (Umgebungsvariablen, Umgebungseinstellungen). Committen Sie nie Geheimnisse in ein Repository, und kopieren Sie settings/override/ nie von Live auf einen Entwicklungsrechner.

Einstellungen in Templates und PHP lesen #

{ezini( 'SiteSettings', 'SiteName', 'site.ini' )|wash()}

<?php
$ini = eZINI::instance( 'exp_mysite.ini' );
$limit = $ini->hasVariable( 'ListSettings', 'Limit' ) ? (int)$ini->variable( 'ListSettings', 'Limit' ) : 10;

Eine eigene Einstellungsdatei (exp_mysite.ini) liegt in settings/ Ihrer Erweiterung und wird wie die des Kernels gelesen (Der Operator ezini, eZINI, Einstellungen in einer Erweiterung).

Caches und Worker #

Einstellungen werden zwischengespeichert. Nach einer Änderung einer Datei von Hand:

php bin/php/ezcache.php --clear-tag=ini --allow-root-user

--clear-tag=ini deckt auch den globalen INI-Cache ab. Die Worker von Velocity halten Einstellungen im Speicher: Starten Sie Velocity nach INI-Änderungen neu (./console exp:velocity restart --allow-root-user), und laden Sie das PHP-FPM, das die Website bedient, bei Änderungen neu, die geladene Klassen betreffen (Eine Website bereitstellen).

Verwandte Seiten #

• Siteaccesses und Multisite
• Append-Dateien und Sicherheit
• Modul 8: Einstellungen und Siteaccesses
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.