nicht angemeldet
Bandwurmnamen vermeiden
Rolf BHi there, wir sind dabei eine Web-Anwendung zu entwickeln. Die einzelne Seiten werden dann unter uns aufgeteilt. Jetzt ist uns folgendes aufgefallen. Es kommt öfter vor, dass Dateien in Strukturen von mehreren Unterverzeichnissen benötigt werden, z.B. $_SERVER['DOCUMENT_ROOT'].'/phplib/std/ oder $_SERVER['DOCUMENT_ROOT'].'/txtlib/fehler/englisch/ Dies ist erstens unübersichtlich und zweitens viel Schreibarbeit. Natürlich könnte man in jedem PHP-Programm dies einer Variablen zuordnen. Ist dies aber auch zentral möglich, dass wir in der .htaccess eine sprechende Variable definieren, im obigen Beispiel z.B. $_SERVER['PHPSTDLIB'] oder $_SERVER['ERRORTXTENG']?
-
Tach!
Ist dies aber auch zentral möglich, dass wir in der .htaccess eine sprechende Variable definieren, im obigen Beispiel z.B. $_SERVER['PHPSTDLIB'] oder $_SERVER['ERRORTXTENG']?
Ja, mit SetEnv.
dedlfix.
-
Hallo,
SetEnv xxxxxx %{DOCUMENT_ROOT} /foo/bin
bzw.
SetEnv xxxxxx %{'DOCUMENT_ROOT'} /foo/bin
bringt "SERVER Fehler"-
Tach!
SetEnv xxxxxx %{DOCUMENT_ROOT} /foo/bin
bzw.
SetEnv xxxxxx %{'DOCUMENT_ROOT'} /foo/bin
bringt "SERVER Fehler"Entspricht ja auch nicht der Syntax, die auf der verlinkten Seite beschrieben war. Dass Variablen von RewriteCond verwendet werden könnten, steht zum Beispiel nicht dort.
dedlfix.
-
Entspricht ja auch nicht der Syntax, die auf der verlinkten Seite beschrieben war. Dass Variablen von RewriteCond verwendet werden könnten, steht zum Beispiel nicht dort.
Leider steht in dem trivialen Beispiele bzw. in dem Artikel auch nicht, in welche Variablen und in welcher Form diese verwendet werden können. Wir finden leider kein passendes Beispiel. Hilfe!!
-
Tach!
Leider steht in dem trivialen Beispiele bzw. in dem Artikel auch nicht, in welche Variablen und in welcher Form diese verwendet werden können.
Gar keine. Da lassen sich nur feste Werte verwenden.
dedlfix.
-
Aber dann ist unser Wunsch nicht realisierbar, denn dann müssen wir ja einen festen Wert für z.B. Document_Root angeben. D.h. Auf unseren Test-Rechnern anders als später auf Provider-Servern. Und bei Providerwechsel ggf. ebenfalls. Das ist schade!
-
Tach!
Aber dann ist unser Wunsch nicht realisierbar, denn dann müssen wir ja einen festen Wert für z.B. Document_Root angeben. D.h. Auf unseren Test-Rechnern anders als später auf Provider-Servern. Und bei Providerwechsel ggf. ebenfalls.
Da sind üblicherweise noch andere Umstellungsarbeiten notwendig, beispielsweise Datenbankverbindungsdaten. Ohne Handarbeit geht sowas kaum und das kann dann im Zuge dessen mit erledigt werden. Eine Dokumentation, was an Individualitäten eingestellt wurde, hilft da sicherlich.
Das ist schade!
So ganz hab ich nicht verstanden, was ihr da konkret durch was ersetzen wollt.
Vielleicht hilft auch der include_path von PHP (hat aber auch keine variablen Anteile). Da muss man auch nicht mit
$_SERVER['foo']hantieren. Sowas schreibt sich nur mit Fingerverrenkung und Magic Strings sind auch nicht das Gelbe vom Ei.dedlfix.
-
-
-
-
-
-
-
Hi there,
wir sind dabei eine Web-Anwendung zu entwickeln. Die einzelne Seiten werden dann unter uns aufgeteilt. Jetzt ist uns folgendes aufgefallen. Es kommt öfter vor, dass Dateien in Strukturen von mehreren Unterverzeichnissen benötigt werden,
Ja, das kommt vor.
> z.B. $_SERVER['DOCUMENT_ROOT'].'/phplib/std/ oder > $_SERVER['DOCUMENT_ROOT'].'/txtlib/fehler/englisch/Unterhalb DOCUMENT_ROOT heißt, daß die Dateien über den Browser erreichbar sind. Ansonsten würde ich darüber nachdenken, wie möglichst viele Parameter die zweckmäßigerweise konfiguriert werden müssen, möglichst so zu konfigurieren daß die Konfiguration nicht im Server sondern in der eigenen Anwendung stattfindet.
Pfadangaben zu einer PHP Library sowie zu Fehlertexten jedenfalls haben in der Serverkonfiguration nichts verloren.
Natürlich könnte man in jedem PHP-Programm dies einer Variablen zuordnen.
Natürlich wird eine Konfiguration zentral verwaltet. Und zwar son, daß ein var_dump alles ausgibt was konfiguriert ist. So muß sich kein Entwickler die Pfade merken, sondern schaut einfach mal nach.
Ist dies aber auch zentral möglich, dass wir in der .htaccess eine sprechende Variable definieren, im obigen Beispiel z.B.
Es gibt Provider bei denen das gar nicht möglich ist Umgebungsvariablen zu setzen.
MfG
-
Hallo pl,
es wäre auch mein Vorschlag gewesen, hier eine zentrale settings.php (oder environment.php oder application.php) zu verwenden, die von allen per Webrequest aufrufbaren PHP Scripten am Anfang required wird. Diese include Datei enthält alle staging-relevanten Werte und Pfade, und zwar so, dass Pfade relativ zu möglichst wenigen Bezugspunkten definiert werden, und DB Zugangsdaten in einer Factory-Klasse oder -Funktion versteckt sind, so dass sie außerhalb der include-Datei nicht ohne weiteres verfügbar sind.
Rolf
--
sumpsi - posui - clusi-
Also irgendwie habe ich das Gefühl, daß das Umlagern von Anwendungskonfigurationen in die Serverkonfiguration /.htaccess so eine Art Modeerscheinung geworden ist. Ist ja nicht das Erstemal daß hier jemand mit dieser Frage hier aufschlägt.
MfG
-
Tach!
Also irgendwie habe ich das Gefühl, daß das Umlagern von Anwendungskonfigurationen in die Serverkonfiguration /.htaccess so eine Art Modeerscheinung geworden ist.
Das hat auch ganz praktische Gründe. Die Konfiguration ist abhängig vom Host auf dem sie läuft. Warum sollten diese hostabhängigen Teile direkt im Programm und nicht im Host definiert werden?
Wie würdest du das bei Mandantensystemen machen, wenn Mandant 1 und Mandant 2 unterschiedliche URLs haben, und damit eigene VHosts, und auch eigenen Konfigurationswerte benötigen, aber das Programm lediglich einmal an zentraler Stelle installiert sein soll?
dedlfix.
-
Tach!
Also irgendwie habe ich das Gefühl, daß das Umlagern von Anwendungskonfigurationen in die Serverkonfiguration /.htaccess so eine Art Modeerscheinung geworden ist.
Das hat auch ganz praktische Gründe. Die Konfiguration ist abhängig vom Host auf dem sie läuft. Warum sollten diese hostabhängigen Teile direkt im Programm und nicht im Host definiert werden?
Warum sollte eine Konfiguration vom Host abhängig sein!? Warum sollte es hostabhängige Komponenten geben!?
Wie würdest du das bei Mandantensystemen machen, wenn Mandant 1 und Mandant 2 unterschiedliche URLs haben, und damit eigene VHosts, und auch eigenen Konfigurationswerte benötigen, aber das Programm lediglich einmal an zentraler Stelle installiert sein soll?
Unterschiedliche URLs oder unterschiedliche VHosts!? Beides ist mit einem richtigen Framework kein Problem. Und auch mit einer Hostunabhängigen Konfiguration.
MfG
-
Tach!
Das hat auch ganz praktische Gründe. Die Konfiguration ist abhängig vom Host auf dem sie läuft. Warum sollten diese hostabhängigen Teile direkt im Programm und nicht im Host definiert werden?
Warum sollte eine Konfiguration vom Host abhängig sein!? Warum sollte es hostabhängige Komponenten geben!?
Weil es halt so ist? In der Entwicklungsumgebung heißt der Datenbankserver localhost, in der Produktivumgebung gibts einen dedizierten Server, der je nach Provider oder Kundenumgebung anders heißt. Das sind Konfigurationen, die je Host unterschiedlich sind.
Wie würdest du das bei Mandantensystemen machen, wenn Mandant 1 und Mandant 2 unterschiedliche URLs haben, und damit eigene VHosts, und auch eigenen Konfigurationswerte benötigen, aber das Programm lediglich einmal an zentraler Stelle installiert sein soll?
Unterschiedliche URLs oder unterschiedliche VHosts!?
Sowohl als auch, keins von beiden, oder gemischt, das soll so flexibel sein, wie es der Bedarf erfordert. Man will ja vielleicht unterschiedliches Corporate Design, dann macht sich eine getrennte Dateiablage für die Templates/CSS nicht schlecht. Vielleicht braucht es auch nur einen Umschalter, wie bei Magento (einzelner ENV-Eintrag), und die Anwendung selbst generiert die Shop-individuelle Oberfläche.
Beides ist mit einem richtigen Framework kein Problem. Und auch mit einer Hostunabhängigen Konfiguration.
Und jedes Mal, wenn ein neuer Mandant hinzukommt, muss das Framework angepasst werden?
Wenn du hingegen meinst, dass da eine ini-Datei oder ähnliches angepasst werden muss, dann ist das auch nichts anderes als eine hostabhängige Konfiguration. Ob die nun direkt in der Hostkonfiguration oder in einer eigenen Datei pro Installation verwaltet wird, ist am Ende dasselbe in grün.
dedlfix.
-
Tach!
Das hat auch ganz praktische Gründe. Die Konfiguration ist abhängig vom Host auf dem sie läuft. Warum sollten diese hostabhängigen Teile direkt im Programm und nicht im Host definiert werden?
Warum sollte eine Konfiguration vom Host abhängig sein!? Warum sollte es hostabhängige Komponenten geben!?
Weil es halt so ist? In der Entwicklungsumgebung heißt der Datenbankserver localhost, in der Produktivumgebung gibts einen dedizierten Server, der je nach Provider oder Kundenumgebung anders heißt. Das sind Konfigurationen, die je Host unterschiedlich sind.
Das ist richtig, aber das gehört ja schonmal gar nicht in die Serverkonfiguration /.htaccess das wäre ja grottenschlecht. Im Übrigen kann man für die Entwicklungsumgebung eine VM aufsetzen, was den Deploy vereinfacht: Checkin/Checkout fertig. Apache unterstützt sogar Virtual DOCUMENT_ROOT.
Wenn du hingegen meinst, dass da eine ini-Datei oder ähnliches angepasst werden muss, dann ist das auch nichts anderes als eine hostabhängige Konfiguration.
Doch das ist gewaltig was Anderes. Siehe Versionsverwaltung, Deploy, Serverumzug.
MfG
-
Tach!
Das ist richtig, aber das gehört ja schonmal gar nicht in die Serverkonfiguration /.htaccess das wäre ja grottenschlecht.
Die Begründung dazu wäre? Was sind denn die gravierenden Nachteile an einer solchen Vorgehensweise?
Wenn du hingegen meinst, dass da eine ini-Datei oder ähnliches angepasst werden muss, dann ist das auch nichts anderes als eine hostabhängige Konfiguration.
Doch das ist gewaltig was Anderes. Siehe Versionsverwaltung, Deploy, Serverumzug.
Bitte begründen. Hingeworfene Stichwörter helfen mir nicht, deine Sichtweise zu verstehen.
dedlfix.
-
-
-
-
-
-
-
-
Vielleicht so:
RewriteCond %{HTTP_HOST} .*
RewriteRule .* - [E=PHPSTDLIB:%{DOCUMENT_ROOT}/phplib/std/] [R=301,L]
-
Hallo Lothar,
das funktioniert.
Wenn "keine Risiken und Nebenwirkungen" bekannt werden ist dies die FÜR UNS die optimale Lösung.-
Tach!
Wenn "keine Risiken und Nebenwirkungen" bekannt werden ist dies die FÜR UNS die optimale Lösung.
Ja, das ist eine Möglihkeit, ENV zu setzen, die mir nicht einfiel. Aber, die RewriteCond sieht überflüssig aus, die prüft auf nichts konkretes. Auch die Umleitung mit [R=301] ist vermutlich nicht gewünscht. Das dürfte auch eine Endlosschleife ergeben.
Es kann sein, dass sich generell noch eine bessere Vorgehensweise finden lässt. Anhand der Beispiele sieht es so aus, als ob Library-Verzeichnisse im DocumentRoot befinden. Wenn diese keine auszuliefernden Dateien enthalten, sollte man sie außerhalb des DocumentRoot ablegen, damit da kein direkter Zugriff erfolgen kann, auch ohne dass man den Zugriff ausdrücklich verbietet. Natürlich kann man dann auch nicht mit %{DOCUMENT_ROOT} als Prefix drauf zugreifen. Dafür gibt es dann aber den include_path, um gar kein Prefix zu benötigen.
dedlfix.
-
-