Home
Downloads
Documentation
Forum
Bugtracker
Jenkins
Deutsch
Clansuite Community Forum
Übersicht
Hilfe
Suche
Kalender
Einloggen
Registrieren
Willkommen
Gast
. Bitte
einloggen
oder
registrieren
.
Haben Sie Ihre
Aktivierungs E-Mail
übersehen?
1 Stunde
1 Tag
1 Woche
1 Monat
Immer
Einloggen mit Benutzername, Passwort und Sitzungslänge
Clansuite Community Forum
>
Clansuite
>
Entwicklerecke
> Thema:
Lösungsansatz zur konfiguration
Seiten: [
1
]
Nach unten
« vorheriges
nächstes »
Drucken
Autor
Thema: Lösungsansatz zur konfiguration (Gelesen 1423 mal)
0 Mitglieder und 1 Gast betrachten dieses Thema.
paulbr
Developer
Offline
Beiträge: 126
Lösungsansatz zur konfiguration
«
am:
Oktober 20, 2010, 02:30:29 »
Hallo
bzgl. den verschiedenen Konfigurationen für Developer, Stageing, Intern und Production Servern
habe ich mir mal einen Lösungsansatz überlegt.
Was haben wir:
- clansuite.config.php ( 1 Serverdefinition )
Was brauchen wir:
- Multiserver lösung um x-beliebig viele Serverkonfigurationen zu integrieren
Server könnten z.B. sein:
- Developer Server
- Stageing Server
- Interner Server
- Production Server (eigentlicher webserver)
Lösungsvorschlag
Die Idee ist nun, verschiedene Einstellungen extern auszulagern
welche je nach benutzten server dann geladen werden sollen.
z.B. Section [database] in clansuite.config.php
;----------------------------------------
; database
;----------------------------------------
[database]
host = "localhost"
type = "mysql"
username = "root"
password = "geheim"
name = "clansuite"
prefix = "cs_"
ändern in:
;----------------------------------------
; database
;----------------------------------------
[database
| extended
]
host = "localhost"
type = "mysql"
username = "root"
password = "geheim"
name = "clansuite"
prefix = "cs_"
[database
| extended
] soll bedeutet, das es für diese Sektion
externe definitionen gibt und diese nun anstatt den vorgegebenen default werten
geladen und die Vorgaben in die clansuite.config.php ersetzt werden sollen.
Die function readConfig im Clansuite_Config_INIHandler entsprechend abändern:
Code:
public static function readConfig($filename, $ext = false)
{
# check ini_filename exists
if(is_file($filename) === false or is_readable($filename) === false)
{
throw new Clansuite_Exception('File not found: '.$filename, 4);
}
$defaultArray = parse_ini_file($filename, true); // Warnings and errors are suppressed
if( true === $ext ) {
$newArray = array();
foreach ($defaultArray as $key => $data)
{
$parts = explode( '|', $key);
$section = trim($parts[0]);
switch (count($parts)) {
case 1:
$newArray[$section] = $data;
break;
case 2:
/**
* $parts[1] = extended
* check the server url then load:
* e.g. stageing.config.php | intern.config.php | develop.config.php |
*/
switch( $_SERVER['SERVER_NAME'] ) {
# development configuration
case "localhost":
case "intranet":
case 'clansuite-dev.com':
case '[url]www.clansuite-dev.com[/url]':
$extfilename = 'develop.config.php';
break;
# stageing configuration
case 'clansuite-stage.com':
case '[url]www.clansuite-stage.com[/url]':
$extfilename = 'stageing.config.php';
break;
# intern configuration
case 'clansuite-intern.com':
case '[url]www.clansuite-intern.com[/url]':
$extfilename = 'intern.config.php';
break;
default:
$extfilename = 'production.config.php';
}
if(is_file( 'configuration/' . $extfilename) === false )
{
# file not exists, load section from clansuite.config.php as default
$newArray[$section] = $data;
}
else {
$loadExtArray = parse_ini_file( 'configuration/' . $extfilename, true);
foreach ($loadExtArray as $key1 => $data1)
{
$section = trim($key1);
$newArray[$section] = $data1;
}
}
break;
default:
# file not exists, load section from clansuite.config.php as default
$newArray[$section] = $data;
}
}
return $newArray;
}
return $defaultArray;
}
function readConfig($filename, $ext = false)
$ext defaultwert FALSE (performance), da ja nicht jedesmal die externe Serverkonfiguration
ausgelesen werden müssen, es reicht wenn diese in der clansuite.application.php
einmalig mit TRUE ausgelesen werden, da diese ja in die clansuite.config.php die default werte
ersetzt.
Auf dieser Weise könnte man alle Sektionen welche Server abhängig sind entsprechend
in den jeweiligen Serverkonfigurationen auslagern.
Damit kann die clansuite.config.php im svn verbleiben, während die externen
Serverkonfigurationen auf svn igno gesetzt werden können.
So muss nicht jeder nach dem Auschecken des svn alles neu einstellen, da die
clansuite.config.php beim start automatisch entwickler abhängig aktualisiert werden sollte
Anmerkung: Das ist nur ein gedanklicher Lösungsansatz, ungetestet.
gruss
paul
Gespeichert
Jens-A. Koch
Maintainer
Offline
Beiträge: 574
One-Man Team
Re: Lösungsansatz zur konfiguration
«
Antworten #1 am:
Oktober 20, 2010, 04:41:19 »
Hallo Paul,
du hattest einen ähnlichen Ansatz ja schonmal vorgeschlagen und sogar Quellcode geschickt.
Ich werde das wie folgt umsetzen:
1) clansuite.config.php: Konfigurationsvariable "staging=1".
2) wenn "staging=1" dann in der Applikation die "staging.core.php" Klasse einbinden
3) staging.core.php constructor aufrufen
4) bestimmen, welche umgebung/welche stage oder welcher nutzer
5) überladen der bereits geladenen werte der clansuite.config.php mit denen der "stage"
Der Config_IniHandler ist nur für das Laden einer Ini-Datei zuständig. Im Kern gehts um die Funktion parse_ini_file(). In den IniHandler sollten höchstens noch Dinge, um das Array etwas aufzubereiten.
Den Quellcode den du in die Methode eingefügt hast, werd ich in die staging.core.php verschieben. An der Stelle von parse_ini_file() wird beim Überladen (Schritt 5) wird nochmals readConfig() eingesetzt, um die jeweilige Stage-Konfiguration zu laden.
Gruß Jens
Gespeichert
Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (
Wie man Fragen richtig stellt
).
paulbr
Developer
Offline
Beiträge: 126
Re: Lösungsansatz zur konfiguration
«
Antworten #2 am:
Oktober 20, 2010, 07:00:33 »
Hallo Jens
Zitat
1) clansuite.config.php: Konfigurationsvariable "staging=1".
2) wenn "staging=1" dann in der Applikation die "staging.core.php" Klasse einbinden
3) staging.core.php constructor aufrufen
4) bestimmen, welche umgebung/welche stage oder welcher nutzer
5) überladen der bereits geladenen werte der clansuite.config.php mit denen der "stage"
d.h.
1) Applikation -> liest clansuite.config.php
2) Applikation -> liest staging.core.php
3) Applikation -> schreibt clansuite.config.php
4) Applikation -> liest clansuite.config.php
das sind 4 Arbeitsschritte.
Zitat
Der Config_IniHandler ist nur für das Laden einer Ini-Datei zuständig.
Mein Ansatz ist der gleiche wie es jetzt ist.
Nur das eben die [database] definitionen in den Serverkonfigurationen entsprechend
nochmal stehn, eben mit den entsprechenden werten.
In der z.b. stageing.config.php würde ebenfalls:
z.B. Section [database] in clansuite.config.php
;----------------------------------------
; database
;----------------------------------------
[database]
host = "localhost"
type = "mysql"
username = "root"
password = "geheim"
name = "clansuite"
prefix = "cs_"
stehen, nur mit den hierfür korrekten daten eben.
Die erwähnten 4 config's sind ja auch ini dateien.
gruss
paul
Gespeichert
Jens-A. Koch
Maintainer
Offline
Beiträge: 574
One-Man Team
Re: Lösungsansatz zur konfiguration
«
Antworten #3 am:
Oktober 20, 2010, 08:57:10 »
Hallo Paul,
habe das Staging eingefügt. Danke für die switch($_SERVER['SERVE_NAME']) Vorarbeit.
Also ich hab mir das Staging als rein zusätzliche Funktionalität gedacht (ausgehend vom Live-Betrieb).
Nur wenn es in der allgemeinen Config aktiviert ist, wird es überhaupt geladen.
Damit ist in der application.core auch nur eine kleine if-Prüfung zusätzlich im System und zu durchlaufen.
Damit das Staging geladen wird in clansuite.config.php [config][staging] auf 1 setzen.
"production" liegt damit vor, wenn das Staging aus ist!
Den Schritt "3) Applikation -> schreibt clansuite.config.php" gibt es nicht.
Derzeit gibts drei Stages: "development", "staging", "intern". Andenken könnte man evtl. noch "testing".
Du hast bestimmt noch Erweiterungsideen, oder?
Gruß Jens
Gespeichert
Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (
Wie man Fragen richtig stellt
).
paulbr
Developer
Offline
Beiträge: 126
Re: Lösungsansatz zur konfiguration
«
Antworten #4 am:
Oktober 20, 2010, 11:35:27 »
Hallo Jens
Hilf mir grad mal auf die Sprünge
Also wenn ich das nun richtig Interpretiere, so wird zwar die staging.config.php geladen
und auch in das Array $config hinzugefügt, aber nicht in die clansuite.config.php
eingetragen?
d.H. mancher orts wird aber die $config nicht aus der Clansuite_CMS::$config sondern
WCMS_Config $config geholt, hier sind die staging angaben ja nicht enthalten.
Mache ich da grade einen Denkfehler?
gruss
paul
Gespeichert
Jens-A. Koch
Maintainer
Offline
Beiträge: 574
One-Man Team
Re: Lösungsansatz zur konfiguration
«
Antworten #5 am:
Oktober 21, 2010, 02:34:44 »
Zitat
Also wenn ich das nun richtig Interpretiere, so wird zwar die staging.config.php geladen
und auch in das Array $config hinzugefügt, aber nicht in die clansuite.config.php
eingetragen?
Also neu geschrieben wird die clansuite.config.php nicht. Das spielt sich nur im Speicher ab.
Zitat
d.H. mancher orts wird aber die $config nicht aus der Clansuite_CMS::$config sondern
WCMS_Config $config geholt, hier sind die staging angaben ja nicht enthalten.
Also eher hilfst du mir gerade auf die Sprünge ,) es is ein Fehler meinerseits.
Die clansuite.config.php wird ja zuerst in Clansuite_CMS geladen und steht dort als Array $config zur Verfügung. Die Clansuite_CMS:$config wird nicht neu zugewiesen und enthält somit nicht das kombinierte Array. Das kombinierte Array gabs nur innerhalb von Clansuite_Config.
Nachtrag 1: Das Staging ist nun unabhängig von Clansuite_Config. Das Array Clansuite_CMS:$config wird von außen an das Staging übergeben, dort überladen und wiederrausgegeben.
self::$config = Clansuite_Staging::overloadWithStagingConfig(self::$config);
Nachtrag 2: Also durch das Laden der ganzen Config-Files wird das System deutlich langsamer.
Es wird nun immer die theme_info.xml gelesen, die clansuite.config.php und die staging.config.php.
Da kommt einiges zusammen. Ich habe hier bei aktiviertem Debugging auf einem Zend Server mit APC und XDebug zwar nur 4,8 bis 7MB Speicherverbrauch, aber Ladezeiten von bis zu 12 Sekunden. Das mag zum einen an XDebug und APC liegen, die verstehen sich auch nach Jahren noch nicht richtig. Zum anderen, an den ganzen Firebug Calls und besonders an Smarty ClearCache (letzteres betrifft einen nicht gerade kleinen Verzeichnisbaum samt Files).
Wenn alle Debugging Einstellungen des Systems ausgeschaltet sind, liegt die "Application Runtime" bei ca. 0,9 Sekunden, so beispielsweise beim controlcenter 3,9 MB / 0,97 Sekunden. Hauptseite allerdings bei 5MB und 1,5 Sekunden. Ein wenig Spielraum nach unten ist noch vorhanden: Renderer Caching aktivieren und XDebug als Extension deaktivieren. Wie sehen die Werte bei Dir aus? Ist das noch erträglich?
Gruß Jens
Gespeichert
Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (
Wie man Fragen richtig stellt
).
paulbr
Developer
Offline
Beiträge: 126
Re: Lösungsansatz zur konfiguration
«
Antworten #6 am:
Oktober 21, 2010, 06:09:38 »
Zitat
Wie sehen die Werte bei Dir aus? Ist das noch erträglich?
Ich habe mal verschiedenes getestet!
Ergebnis: Ja es ist erträglich, aber besser kann es immer werden
Für jedem test durchlauf habe ich cache und autoloader geleert, sowie cookies gelöscht
Legende:
1 = time execute
2 = memory usage (before)
3 = memory usage by clansuite
4 = memory peak
5 = doctrine time
6 = smarty total time
A = Aktiv: APC-Cache, debug, xdebug, development, staging
B = Aktiv: APC-Cache, staging;
Ausgeschaltet: debug, xdebug, development
C = Aktiv: APC-Cache, debug, xdebug, development, staging
Misses files im loader durch vorheriges prüfen umgangen wie im Post:
http://forum.clansuite.com/index.php/topic,2801.msg3927.html#msg3927
erwähnt.
D = Aktiv: APC-Cache, staging;
Ausgeschaltet: debug, xdebug, development
Misses files im loader durch vorheriges prüfen umgangen wie im Post:
x = First start
z = mittelwert aus 4 start's durch aktualisierung des browsers ohne vorheriges leeren der caches
Ax Bx Cx Dx
-----------------------------------------------------------------------------------------
1 11,78 sec 3,77s 6,53 sec 3,06 sec
2 0,71 MB 0,6 MB
3 25,93 MB 7,86 MB
4 26,61 MB 8,55 MB
5 0,055 sec 0,030 sec
6 4,83606 sec 4.67228 sec
Az Bz Cz Dz
-----------------------------------------------------------------------------------------
1 6,6 sec 1,3 sec 6,3 sec 1,2 sec
Ich habe den test für Ax + Cx mehrmals durchgeführt, es ist so, das wenn im loader
die files auf vorhanden sein geprüft werden die execute time um etwa die hälfte geringer ist.
Allerdings betrifft dies nur den First Start.
beim aktualisieren des browsers bzw. wiederholten Start ohne cache clearing sind die werte nur
minimal besser.
Zum Staging
Ich verwende im normalfall 3 Server:
- Development: Entwicklungsumgebung
- Staging: Fertige scripte aus development kommen hier hin
hier findet auch das svn statt
- Production: Online Webserver
Bei grösseren Projekten, z.B. Auktionshaus verwende ich noch:
- Testing: Online Testserver mit der version aus dem Staging speziell für ausgewählte
Testuser, welche die erneuerungen austesten sollen.
- Intern: Interner Server welche die aktuelle Online Version beinhaltet
Erneuerungen welche online gehen sollen und durch Testing abgesegnet
wurden, werden hier integriert, nochmals angetestet, danach in Production
upgeloadet.
Tool
Da ich meine Programmierungen mittels EditPlus (texteditor) erstelle, habe ich immer jede menge
sicherungs daten (.bak), auch ist es mir immer lästing stored caches (z.B. smarty cache ordner)
von hand zu löschen.
So hab ich mir eine kleine batch datei dafür erstellt. Ich geb die hier mal in den Anhang, falls
jemand interesse dran hat. Einfach die _cleanup.bat ins root der clansuite kopieren.
Die batch löscht:
- alle .bak dateien in allen ordnern und unterordnern
- cache/cache
- cache/templates_c
- cache/phpids_defaultfilter.cache
- logs/autoload_hits.log
- logs/autoload_misses.log
Die batch leert:
- configuration/autoloader.config.php
gruss
paul
Gespeichert
Jens-A. Koch
Maintainer
Offline
Beiträge: 574
One-Man Team
Re: Lösungsansatz zur konfiguration
«
Antworten #7 am:
Oktober 22, 2010, 01:19:51 »
Danke für die Messungen.
Ich habe den xdebug.profiler angeworfen und mir den trace-dump mit WinCachegrind angeschaut. Anbei mal meine Settings aus der php.ini.
Zitat
; debugging mit netbeans
xdebug.remote_enable=On
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
; profiling
xdebug.profiler_enable=1
xdebug.profiler_output_dir=c:\temp
Unter c:\temp\ lässt sich dann die Datei "cachegrind.out.xy" finden.
Einfach mit
http://sourceforge.net/projects/wincachegrind/
öffnen.
Zusätzlich noch set_time_limit(0); in die erste Zeile in der index.php,
denn die Cachgrind-Datei kann sehr groß werden und muss erstmal geschrieben werden.
Ansonsten wird wegen Überschreitung der Ausführungszeit abgebrochen.
Mir sind sehr viele Kleinigkeiten aufgefallen, die anders gelöst werden könnten, um noch ein paar Performance-Pfennige locker zu machen. Weniger magische Aufrufe und weniger if-checks.
Insgesamt liegt der Overhead aber deutlich im Bereich von Phemto und Smarty.
Ich konnte es kaum glauben, aber Phemto hat ohne Witz 36.900 is_subclass_of() Aufrufe!?!
Autoloader
Ich habe den Autoloader nochmal verändert und einige if-Anweisungen und das Logging von Hits und Misses rausgenommen. Ich habe auch das Array mit der Dateinamens-Konstruktion
und die anschließende foreach()-Anweisung rausgeworfen und durch Deine Variante ersetzt.
Ich hoffe das macht sich nun positiv bemerkbar. Wenn nicht, dann müssen wir wieder etwas zurückrudern ,)
Staging / Konfiguration
Das Staging auf Basis der Servernamen gefällt mir supi - das war ein guter Vorschlag von Dir. Ich habe mir einen zweiten VHost "clansuite-prod", zusätzlich zu "clansuite-dev" angelegt. In der "development.config.php" hab ich nur die Debug-Settings aktiviert. Je nach URL ist das System somit im Debug-Modus oder nicht. Die beiden URLs hab ich als Lesezeichen im Browser. Ich bin am überlegen, ob ich die Clansuite Toolbar erweitere, um Aufrufe auf einen zweiten Vhost zu unterstützen.
Deine Server fürs Staging
Also intern/testing sind zur Qualitätssicherung. Der Aufbau hört sich gut an.
Die Frage die sich mir sofort stellt ist: wie hältst Du das synchron?
Ich könnte mir ein solches Setup auch vorstellen. Aber erst, wenn wir näher am Ziel sind.
Aus Kostengründen kann ich nur auf einen Server abstellen - allerdings könnte man diesen ja mittels Virtualisierung in mehrere aufteilen. Dann kann man zumindest SVN und Intern-Testing auf einer Maschine laufen lassen mit aktiviertem XDebug fürs Quellcodemonitoring - abgetrennt vom Extern-Testing (etwa einer Demoversion) und einem Live-Server (nur Projektwebseite).
Gespeichert
Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (
Wie man Fragen richtig stellt
).
paulbr
Developer
Offline
Beiträge: 126
Re: Lösungsansatz zur konfiguration
«
Antworten #8 am:
Oktober 22, 2010, 03:16:12 »
Ich glaube dir ist ein Fehler unterlaufen:
clansuite.loader.php
->Autoload
Code:
...
return self::autoloadExclusions($classname);
return self::autoloadInclusions($classname);
...
der Autoload wird so nicht ausgeführt, das return darf hier nicht stehen, weil an dieser stelle
der autoload beendet wird.
Ich habe das mal bei mir behoben, allerdings erhalte ich ein error bei den Filtern:
Clansuite Exception : [ Clansuite_Filter_PhpDebugConsole ]
Irgendwas stimmt am autoload nicht, hatte aber noch keine zeit das zu checken.
Zitat
Die Frage die sich mir sofort stellt ist: wie hältst Du das synchron?
Ich habe mir als lokalen Server den WampServer installiert.
Development Server ist virtuell also einfach durch aufruf
http://intranet/projekte/clansuite
definiert. Der Grund ist einfach der, das ich viele projekte verwalte und viel rum experimentiere
Staging Server sind lokal als vhost für jedes Projekt definiert.
Jedes Staging ist im eigenen svn.
Wenn ich nun im Developer änderungen mache, synchronisiere ich die änderungen nach der Prüfung
mittels eines Commanders (EF-Commander, WinCommander) mit dem Staging. So sind diese als
aktueller Stand im svn.
Um das svn dann auf den Test- bzw. productionsserver zu laden, verwende ich ein SVN-Cleaner
programm, welches mir die gesamte Struktur ohne .svn kopiert.
Nun wird das ganze mittels FTP zu den Servern upgeloadet.
Als ich alle Projekte noch auf 1 dedizierten Server hatte war es einfacher, da hab ich einfach das svn ausgecheckt auf die entsprechenden webaccounts.
Anmerkung:
Wenn ich mal mehr Zeit habe muss ich das mal wieder aktivieren und anpassen auf externe Server.
Der Aufwand hört sich schlimmer an als er ist
Ich hab 2 dedizierte Server sowie 1 DNS Server auf denen ich meine Kunden und Domains Verwalte.
Somit habe ich was Production- und Testing Server betrifft keine Probleme, da ich da ja flexibel bin.
Wenn ich für ein Projekt einen testserver benötige lege ich den als eigenen Webaccount an und beleg ihn mit einer Subdomain der Projektseite. z.B.
www.clansuite.com
-> testing.clansuite.com
gruss
paul
Gespeichert
paulbr
Developer
Offline
Beiträge: 126
Re: Lösungsansatz zur konfiguration
«
Antworten #9 am:
Oktober 22, 2010, 09:57:37 »
Habe die Autoload mal berichtigt:
Code:
/**
* autoload
*
* @param string $classname The name of the factories class
* @return boolean
*/
public static function autoload($classname)
{
# check if class was already loaded
if (class_exists($classname, false)) # or interface_exists($classname, false))
{
return true;
}
if( true === self::autoloadExclusions($classname) )
{
return false;
}
if( true === self::autoloadInclusions($classname) )
{
return true;
}
/**
* Start Classname to Filename Mapping
*/
$filename = mb_strtolower($classname);
# strip 'clansuite_' from beginning of the string
if(false !== mb_strpos($filename, 'clansuite_'))
{
$filename = mb_substr($filename, 10);
}
# Core Class
# clansuite/core/class_name.core.php
$filen = ROOT_CORE . str_replace('_','',$filename) . '.core.php';
if(is_file($filen))
{
return self::includeFileAndMap($filen, $classname);
}
# Factories
# clansuite/core/factories/classname.factory.php
# don't add factory is already in the classname
$filen = ROOT_CORE . 'factories' . DS . str_replace('_','.',$filename) . '.php';
if(is_file($filen))
{
return self::includeFileAndMap($filen, $classname);
}
# Event
# clansuite/core/events/classname.class.php
$filen = ROOT_CORE . 'events' . DS . $classname . '.class.php';
if(is_file($filen))
{
return self::includeFileAndMap($filen, $classname);
}
# Filter
# clansuite/core/filters/classname.filter.php
$filen = ROOT_CORE . 'filters' . DS . mb_substr($filename, 7) . '.filter.php';
if(is_file($filen))
{
return self::includeFileAndMap($filen, $classname);
}
# Viewhelper
# clansuite/core/viewhelper/classname.core.php
$filen = ROOT_CORE . 'viewhelper' . DS . str_replace('_','.',$filename) . '.core.php';
if(is_file($filen))
{
return self::includeFileAndMap($filen, $classname);
}
return false;
}
- Autoload darf nur verlassen werden wenn autoloadExclusions true ist
- Autoload darf nur verlassen werden wenn autoloadInclusions true ist
filename wird überschrieben, hier musste ein anderer variablename genommen werden.
gruss
paul
Gespeichert
paulbr
Developer
Offline
Beiträge: 126
Re: Lösungsansatz zur konfiguration
«
Antworten #10 am:
Oktober 22, 2010, 10:52:44 »
Nochmal zum Staging
Die Staging definitionen sollte man eindeutig benennen und in einem separaten
verzeichnis legen, da der Ordner: configuration durch diese neuen definitionen
überladen (unübersichtlich) wird.
Es handelt sich hier ja ausschliesslich um server konfigurationen, die ein normaler
Anwender kaum benötigen wird. Die vielen konfigurationen verwirren den Anwender
womöglich nur. Die einzige config die man als Anwender normalerweise benötigt
ist clansuite.config.php und die config.production.php falls der Anwender
staging=1 in der clansuite.config.php belässt.
Wobei als Standard hier besser staging=0 stehen sollte und somit die Standard
Daten aus der clansuite.config.php genommen werden, welche ja production sind.
z.B.
configuration/server/config.development.php
configuration/server/config.intern.php
configuration/server/config.production.php
configuration/server/config.staging.php
in der staging.core.php den pfad anpassen:
return ROOT . 'configuration' . DS . 'server' . DS . $filename;
Phänomen
Gestern ist es mir 2mal passiert, das die clansuite.config.php plötzlich
bis auf die daten des staging leer war.
Ich konnte aber nicht nachstellen wann und bei welcher Aktion das passierte.
Achte bitte mal mit drauf, es wird wohl sicherlich bei dir auch mal vorkommen werden.
Meine Vermutung geht in richtung smarty, den es passierte als ich für das black theme
ein modul für eine livechat shoutbox begonnen hatte.
Ich denke irgendwo bei smarty wird die $config neu überschrieben.
Wie gesagt das Phänomen ist nur 2mal aufgetreten.
gruss
paul
Gespeichert
paulbr
Developer
Offline
Beiträge: 126
Re: Lösungsansatz zur konfiguration
«
Antworten #11 am:
Oktober 22, 2010, 01:03:34 »
Zitat
Ich habe den xdebug.profiler angeworfen und mir den trace-dump mit WinCachegrind angeschaut. Anbei mal meine Settings aus der php.ini.
besser in die .htaccess legen, so kann man:
php_value xdebug.profiler_enable "1" aus-/ einschalten
ohne jedesmal den server zu restarten.
Zitat
<IfModule mod_php5.c>
php_value magic_quotes_runtime "0"
php_value magic_quotes_gpc "0"
php_value register_globals "Off"
php_value output_buffering "1"
php_value output_handler ob_gzhandler
# debugging mit netbeans
php_value xdebug.remote_enable "On"
php_value xdebug.remote_host "localhost"
php_value xdebug.remote_port "9000"
php_value xdebug.remote_handler "dbgp"
# XDebug profiling
php_value xdebug.profiler_enable "1"
php_value xdebug.profiler_output_dir "c:\temp"
</IfModule>
Ja die libraries gehen nicht gerade Ressourcensparend um.
Man muss nun das verhältnis sehen, benutzt man nur wenig möglichkeiten
einer Librarie, macht diese keinen Sinn, dann ist es besser man schreibt die selbst.
Was mir noch nie an der Smarty-Engine gefiel sind die enorm vielen caches.
In meiner php4 engine verwendete ich einen abklatsch von xtemplate.
- cachefile für header
- cachefile für footer
- cachefile für menü
- content der ebenfalls aus wenigen bis vielen templates bestehen konnte, werden
erst geparst dann zu 1 cachefile gecatched
Smarty hingegen parst und catcht jedes einzelne template für sich, was meiner meinung nach
im content nicht allzuviel sinn macht. Der content ist es ja in der Hauptsache der sich dynamisch
von seite zu seite ändert, hier ist es wichtig eine gesunde mischung zu finden.
gruss
paul
Gespeichert
Jens-A. Koch
Maintainer
Offline
Beiträge: 574
One-Man Team
Re: Lösungsansatz zur konfiguration
«
Antworten #12 am:
Oktober 22, 2010, 05:47:23 »
Hallo Paul,
habe die Berichtigungen in den Autoloader eingefügt. Mir ist dabei aufgefallen, dass autoloadExclusions() immer nur false zurückgibt. Eine Prüfung auf "true" läuft leer.
Zitat
von
if( true === self::autoloadExclusions($classname) )
{
return false;
}
zu
if( false === self::autoloadExclusions($classname) )
{
return false;
}
Außerdem macht die Suche in verschiedenen Pfaden für den Core und Fabriken keinen Sinn.
Diese Dinge werden immer benötigt - ich habe daher die meisten Dateien dem InclusionTable hinzugefügt.
Auch die Struktur ist einfacher geworden. Es werden nicht mehr zwei Loader registriert, sondern nur einer. Nämlich die Hauptmethode autoload().
Innerhalb von autoload() gibt es folgende Reihenfolge:
1) Ausschluß (exclusion) 2) Einschluß (inclusions) 3) MappingDatei 4) Pfade probieren und mappen.
Für jeden der Schritte gibts eine eigenen Methode.
Die Mapping-Datei ist nur im Schritt 3) erforderlich und wird nicht mehr "immer" geladen, sondern nur wenn auch tatsächlich Schritt 3) erreicht wird - also 1) und 2 ) nicht zum Lade-Erfolg führten.
Jede der Methoden führt bei Erfolg zum Abbruch (d.h. das Autoloading wird beendet für die jeweilige Datei) - hoffentlich - es sei denn, da is wieder ein Logikfehler drin).
Ob das ganze nun schneller ist, bleibt abzuwarten...
Application Runtime
im controlcenter zwischen 0.875 bis 1.1 Seconds bei ca. 3.8 MB Speicher.
im frontend zwischen 2.015 bis 2.2 Seconds - das is ok für 16 Widgets/Module.
Staging
Zwecks besserer Ordnung: Das Unterverzeichnis /configuration/staging angelegt und Configdateien dort eingefügt.
Soviel erstmal, Jens
Gespeichert
Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (
Wie man Fragen richtig stellt
).
paulbr
Developer
Offline
Beiträge: 126
Re: Lösungsansatz zur konfiguration
«
Antworten #13 am:
Oktober 23, 2010, 04:58:40 »
Ist es nicht besser, wenn man:
3) autoloadByMappingFile
vor
2) autoloadInclusions setzen
Grund: Sollte die Klasse bereits im Mapping sein, spart man sich die inclusion.
Das ergibt einen weiteren minimalen performance gewinn.
gruss
paul
Gespeichert
Jens-A. Koch
Maintainer
Offline
Beiträge: 574
One-Man Team
Re: Lösungsansatz zur konfiguration
«
Antworten #14 am:
Oktober 24, 2010, 03:03:45 »
Dann müssten wesentlich mehr Dateien über die Map-File gefunden werden (Hits), als über die Inclusion-Tabelle. Ich gehe davon aus, dass das Laden der Map-Datei teurer ist, als das Bauen von 30 Pfaden. Wenn man nun autoloadByMapping() vor die autoloadInclusions() stellt, dann wird sich der Systemstart verlangsamen. Aber: Genaue Angaben kann nur der Profiler machen
Ich habe den Aufruf von Exception- und Errorhandling auf Wrapper-Methoden innerhalb von "Clansuite_CMS" verlegt. Wenn eine Exception oder ein Error ausgelöst wird, dann wird zunächst die jeweilige Methode aufgerufen und dann erst die Klasse eingebunden. D.h. nur im Fehlerfall werden die Klassen geladen und nicht bei jedem Systemstart.
Gespeichert
Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (
Wie man Fragen richtig stellt
).
paulbr
Developer
Offline
Beiträge: 126
Re: Lösungsansatz zur konfiguration
«
Antworten #15 am:
Oktober 24, 2010, 01:41:42 »
Hallo Jens
Zitat
Ich gehe davon aus, dass das Laden der Map-Datei teurer ist, als das Bauen von 30 Pfaden.
Ja das kann sein, auf jedenfall wird das egal wie rum, sehr gering und daher vernachlässigbar sein.
letzte Änderungen
Meinst du es macht Sinn die function loadModul in die smarty function.load_module.php zu verlegen?
Die Function muss dann ja bei jeder RenderEngine auch nochmal definiert werden.
Die function toUnderscoredUpperCamelCase ist eine allgemeine function und könnte durchaus
an anderen Stellen evtl. ebenfalls gebraucht/genutzt werden. Macht es hier Sinn diese in die functions.core.php zu verlegen?
-----
Exception.core.php
public function yellowScreenOfDeath()
self::getCode() <-> $this->getCode()
if(mb_strpos(self::getMessage(), 'action_')) {
$placeholders['actionname'] = mb_substr($this->message, mb_strpos($this->message, 'action_'));
}
...
Sollte man hier nicht einheitlich entweder alle $this->message oder $this->getMessage() machen?
Staging
In den staging definitionen sollte die Sektion [database] rein.
Ich weiss nicht wie es bei dir ist, aber bei mir sind je nach Server die Zugangsdaten anderst.
Auch denke ich das es Sinn macht die Sektionen:
- [routing]
- [cache]
- [maintenance]
ebenfalls ins Staging zu legen.
[maintenance] kann für production z.b. aktiviert sein, aber im development muss man ja
die Seiten sehen können, wenn man daran arbeitet.
Die caches sind im normalfall in production betrieb eingeschaltet, im development nicht.
Ich sage das deshalb, weil es mir bei meinen programmierungen sehr oft passierte,
das ich vergas die $config entsprechend von den developereinstellungen zurück auf die
productionseinstellungen zu setzen. Die Änderungen dann rasch uploadete und mich wunderte
warum nichts mehr so richtig funktionierte. Das war ja der Sinn warum ich das staging nutzte
Man sollte auch mal überlegen evtl. eine neue Sektion z.b. [commands] hinzuzufügen.
Je nach Server können die pfade zu den commands anders sein.Zumindest was lokal und online
betrifft. z.b. ImageMagick, JHead
Anmerkung:
Für die Sicherheit ist es unumgänglich auch die Bilder auf schadcode zu prüfen.
Ich hatte schon den Fall das ein hacker über ein jpeg upload zugriff auf einen Kundenserver bekam
und die passwörter seiner kunden ausgelesen hat.
Nur jpg's kann man nicht so einfach prüfen, da diese wenn sie mit diversen digitalkameras gemacht
wurden eine headerinfo haben, was normale jpgs nicht haben.
Mit JHeat kann man diese infos extrahieren und danach die jpeg auf schadcode prüfen.
Auf meinen Servern habe ich das seither immer installiert.
gruss
paul
Gespeichert
Jens-A. Koch
Maintainer
Offline
Beiträge: 574
One-Man Team
Re: Lösungsansatz zur konfiguration
«
Antworten #16 am:
Oktober 24, 2010, 06:50:14 »
Schadcode in Bildern
Das Thema ist für mich neu. Von der Position her muss dieser Check hinter den Bildupload geschaltet werden. Ich könnte mir als Problemlösung zwei Verfahren denken: Man könnte das empfangene Bild temporär resizen (mit den Ausgangswerten) und dann erst abspeichern oder ein Watermark-Overlay (transparent mit einem random pixel) rauflegen. Beides beseitigt möglichen Schadcode mit PHP-Mitteln.
"JHead" kenne ich gar nicht - was genau macht das?
Damit das überhaupt relevant wird, müsste erstmal der Bildupload funktionieren.
Commands
Ist eine Erweiterungsidee. Ich würde das aber nicht global definieren.
Das sind eher unterstützende Bibliotheken.
Aber auch diese Position im System muss erstmal erreicht werden, um solche Commands dann einzusetzen.
Staging Default Werte
Zitat
Die caches sind im normalfall in production betrieb eingeschaltet, im development nicht.
Richtig, kann man sehr schnell vergessen und übersehen. Entsprechende Änderung wird eingefügt.
Gespeichert
Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (
Wie man Fragen richtig stellt
).
paulbr
Developer
Offline
Beiträge: 126
Re: Lösungsansatz zur konfiguration
«
Antworten #17 am:
Oktober 24, 2010, 09:10:29 »
jhead ist ein Kommandozeilenwerkzeug zur Anzeige oder Bearbeitung der Exif-Dateiinformationen in Digitalfotos. Es ist vielseitig verwendbar.
Info:
http://www.sentex.net/~mwandel/jhead/usage.html
Headerinformationen aus dem jpeg extrahieren erreicht man mit:
jhead -purejpg test.jpg
Ich verwende folgenden check ob ein bild keinen schadcode enthält:
Code:
/**
Scan image files for malicious code
*/
function verify_image($file) {
$txt = file_get_contents($file);
$image_safe = true;
if (preg_match('#&(quot|lt|gt|nbsp);#i', $txt)) { $image_safe = false; }
elseif (preg_match("#&\#x([0-9a-f]+);#i", $txt)) { $image_safe = false; }
elseif (preg_match('#&\#([0-9]+);#i', $txt)) { $image_safe = false; }
elseif (preg_match("#([a-z]*)=([\`\'\"]*)script:#iU", $txt)) { $image_safe = false; }
elseif (preg_match("#([a-z]*)=([\`\'\"]*)javascript:#iU", $txt)) { $image_safe = false; }
elseif (preg_match("#([a-z]*)=([\'\"]*)vbscript:#iU", $txt)) { $image_safe = false; }
elseif (preg_match("#(<[^>]+)style=([\`\'\"]*).*expression\([^>]*>#iU", $txt)) { $image_safe = false; }
elseif (preg_match("#(<[^>]+)style=([\`\'\"]*).*behaviour\([^>]*>#iU", $txt)) { $image_safe = false; }
elseif (preg_match("#</*(applet|link|style|script|iframe|frame|frameset)[^>]*>#i", $txt)) { $image_safe = false; }
return $image_safe;
}
Die function gibt true zurück wenn das bild ok ist, false wenn schadcode enthalten ist.
Damit sollte kein hacker angriff mittels eines picture uploads möglich sein.
Zumindest hatte ich seit ich das einsetze keine mehr über Bilder.
gruss
paul
Gespeichert
paulbr
Developer
Offline
Beiträge: 126
Re: Lösungsansatz zur konfiguration
«
Antworten #18 am:
Oktober 25, 2010, 12:46:03 »
Staging
Das Overlaod der $config funktioniert so nicht.
Die $config wird nicht mit der config aus dem staging überschrieben.
Mit der array_merge_recursive_distinct aus der ini.config.php funktioniert es:
$config_array = self::array_merge_recursive_distinct($array_to_overload, $staging_config);
return $config_array;
gruss
paul
Gespeichert
Jens-A. Koch
Maintainer
Offline
Beiträge: 574
One-Man Team
Re: Lösungsansatz zur konfiguration
«
Antworten #19 am:
Oktober 25, 2010, 07:23:38 »
Staging
Zitat
$config_array = self::array_merge_recursive_distinct($array_to_overload, $staging_config);
return $config_array;
Habe es umgedreht: return $staging_config += $array_to_overload;
Werte der StagingConfig gehen nun vor. Sie werden nicht durch Werte aus der allgemeinen Cfg überschrieben. Das Array wird nur aufgefüllt.
Gespeichert
Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (
Wie man Fragen richtig stellt
).
Seiten: [
1
]
Nach oben
Drucken
Clansuite Community Forum
>
Clansuite
>
Entwicklerecke
> Thema:
Lösungsansatz zur konfiguration
« vorheriges
nächstes »
Gehe zu:
Bitte wählen Sie ein Ziel:
-----------------------------
Clansuite
-----------------------------
=> Ankündigungen | Announcements
=> Entwicklerecke
=> Anwenderforum | Usersforum
=> Hilfe | Support & Troubleshooting
=> Wünsche | Feature Requests
=> Designs & Themes, Templates
=> Nachrichten
===> IT-Security
===> PHP News
=> Fun Forum
Lade...