Das Web aus der Datenbank
hotti
- programmiertechnik
hi,
ich habe eine Tabelle in MySQL auf dem Server wo drinsteht:
url Title Body
/a.html Schöne Seite "body von 'Schöne Seite'"
usw.
Die Dateien gibts derzeit als HTML-Dateien wie
/a.html
/b.html
/c.html
usw. Diese Dateien will ich nun alle löschen, weil ich ja den ganzen Kram in der Datenbank habe. Damit das keinen 404er gibt und die URLs so bleiben, müsste ich mod_rewrite einschalten, so dass
/a.html => /cgi-bin/view.cgi?zeige=/a.html
/b.html => /cgi-bin/view.cgi?zeige=/b.html
ein Script "view.cgi" den jeweiligen Body aus der DB liest, einen einheitlichen header und footer dranschnippelt und die Seite zum Browser schickt.
Da ich mit mod_rewrite noch nichts gemacht habe, brauche ich mal einen Denkanstoß dazu, wie eine solche Zeile in der .htaccess aussehen könnte.
Vielen Dank im Voraus,
Horst
ne Leute, ihr kennt mich ;-)
Lasst mich hier schuften und denkt "der alte Knacker wirds schon selber finden"
Richtig ;-)
DirectoryIndex /cgi-bin/view.cgi?/index.html
RewriteEngine on
RewriteRule ^(.*).html$ /cgi-bin/view.cgi?/$1.html
Aber eine Frage hab ich doch noch: Wie knipse ich das in einem Unterordner wieder ordentlich aus in einer untergeordneten .htaccess?
Probiert:
RewriteEngine off
tut nicht. Hat aber Zeit bis morgen ;-)
Hotte
Hi,
RewriteEngine on
RewriteRule ^(.*).html$ /cgi-bin/view.cgi?/$1.htmlAber eine Frage hab ich doch noch: Wie knipse ich das in einem Unterordner wieder ordentlich aus in einer untergeordneten .htaccess?
Probiert:
RewriteEngine offtut nicht.
Doch, das schaltet die RewriteEngine für dieses Verzeichnis und alle darunter liegenden ab.
Aber das ändert natürlich nichts daran, dass die "darüber" liegenden Rewrite-Regeln natürlich nach wie vor ihre Gültigkeit haben ...
Die Frage muss also anders formuliert werden - wie, kommt darauf an, was du erreichen möchtest.
MfG ChrisB
Hi Chris,
»» Probiert:
»» RewriteEngine off
»»
»» tut nicht.Doch, das schaltet die RewriteEngine für dieses Verzeichnis und alle darunter liegenden ab.
Aber das ändert natürlich nichts daran, dass die "darüber" liegenden Rewrite-Regeln natürlich nach wie vor ihre Gültigkeit haben ...Die Frage muss also anders formuliert werden - wie, kommt darauf an, was du erreichen möchtest.
danke, ja, das ist schon das, was ich möchte
/.htaccess # RewriteEngine on, tut alles
/kaitsch/.htaccess # RewriteEngine off
P.: das 'off' machter nicht. Mein Workaround /kaitsch/.htaccess:
DirectoryIndex /index.html
RewriteRule ^(.*).html$ $1.html
Das tut, aber ist nicht ganz "sauber", ich denke, das stesst den Server unnötig.
Viele Grüße,
bis morgen,
Hotte
DirectoryIndex /cgi-bin/view.cgi?/index.html
RewriteEngine on
RewriteRule ^(.*).html$ /cgi-bin/view.cgi?/$1.htmlAber eine Frage hab ich doch noch: Wie knipse ich das in einem Unterordner wieder ordentlich aus in einer untergeordneten .htaccess?
Indem dein Pfad-Pattern keine Unter-Pfade beinhaltet.
Dann musst du gar nichts ausknippsen wollen.
RewriteRule ^/([^/]+).html$ /cgi-bin/view.cgi?/$1.html
mfg Beat
hi Beat,
Indem dein Pfad-Pattern keine Unter-Pfade beinhaltet.
Dann musst du gar nichts ausknippsen wollen.
»» RewriteRule ^/([^/]+).html$ /cgi-bin/view.cgi?/$1.html
noi, das tut bei mir leider auch nicht. Schluss für heute, weiter morgen ;-)
Hotte
Guten Morgen,
heute in aller Herrgottsfrühe bin ich aufgestanden und hab das Machwerk des Teufels vollendet: Die Umstellung meines Webs von nativen html-Dateien auf dynamischen Content aus der Datenbank mit mode_rewrite.
Das hat vor allem diese Konsequenz: Weniger Arbeit ;)
Seite erstellen:
Das ist wie ein Tag, wo Weihnachten und Ostern zusammenfallen! Ich bin echt begeistert :-)
Viele Grüße an Alle,
Hotti
Hallo hotti,
... das Machwerk des Teufels ...
wenn du keinen ordentlichen Cache-Algorithmus hast, ist es das wahrlich: Warum erzeugst du statische Seiten bei jedem Aufruf neu? Warum stecken "langlebige" Inhalte in einer Datenbank auf dem Webserver? Oder läuft das Programm offline und erzeugt statische Seiten auf dem Server?
Gruß, Jürgen
hi Jürgen,
»» ... das Machwerk des Teufels ...
wenn du keinen ordentlichen Cache-Algorithmus hast, ist es das wahrlich: Warum erzeugst du statische Seiten bei jedem Aufruf neu? Warum stecken "langlebige" Inhalte in einer Datenbank auf dem Webserver?
Damit die mit meiner lokalen Suchmaschine durchsuchbar sind, damit ich von jedem Rechner der Welt aus (sofern da Perl drauf ist) meine Seiten aktualisieren kann mit einem sehr geringen Arbeitsaufwand. Die komplette Administration geht über HTTP, FTP brauche ich nur noch für CGI-Scripts und Images.
Oder läuft das Programm offline und erzeugt statische Seiten auf dem Server?
Nein. Es gibt überhaupt kein statischen Seiten (*.html) mehr. Alles, was im Browser zu sehen ist, außer CGI's, außer Images, kommt inhaltsmäßig aus der DB.
Die Ausgangsbasis war die, dass ich bisher faktisch alles doppelt hatte, sowohl .html-Dateien, als auch den Content in der DB (wg. der einfachen Durchsuchbarkeit). Daher bin ich gestern auf den Trichter gekommen, das redundante Zeugs wegzuschmeißen und da viel meine Wahl auf die *.html-Dateien, weil ich den Content in der DB ja für die Suchmaschine brauche.
Sicher gibts da noch Einiges zu durchdenken, vieleicht habt Ihr auch noch ein paar Tipps/Ideen für diese Art von Content-Management.
Danke Dir und viele Grüße an Alle,
Horst Haselhuhn
... das Machwerk des Teufels ...
wenn du keinen ordentlichen Cache-Algorithmus hast, ist es das wahrlich: Warum erzeugst du statische Seiten bei jedem Aufruf neu? Warum stecken "langlebige" Inhalte in einer Datenbank auf dem Webserver? Oder läuft das Programm offline und erzeugt statische Seiten auf dem Server?
Es ist äusserst komplex, fertige HTML-Seiten zu cachen.
Irgend etwas bleibt immer übrig, das im Nachhinein modifiziert werden soll.
Ich habe einen Cache-Mechanismus, der zumindest für Gäste Seiten als statische Seiten ausliefert. Aber das momentane Resultat ist eine Inkonsistenz in meiner Theme-Wahl. Für jedes flexible Element muss ich in .htaccess eine zusätzliche Prüfung vornehmen, ob einem Gast eine statische Version ausgeliefert werden darf.
Derzeit prüfe ich nur, ob ein Cookie status=guest vorhanden ist und/oder fehlt. In Rücksicht auf eine mögliche Theme-Wahl müsste ich nun das nächste Cookie setzen und dieses dann wiederum in die Entscheidung miteinbeziehen
Nun ja, Theme-Wahl gehört wohl nicht zum Standard-Betriebsmodus des CMS. Insofern dürfte die Cache-Methode doch gute Resultate bringen.
PS: Derzeit ist nur eine Seite gecacht:
http://www.elcappuccino.ch/ehome-factory/spam
Sofern du die Themawahl (rechts) betätigst (derzeit Auswahl zwischen Maroony und einem CSS-Selector Theme), kannst du eventuell eine Inkonsistenz feststellen, wenn du CSS-Selector aufrufst und dann etwas navigierst und zwischendurch die Spam-Seite aufrufst.
mfg Beat
hi Beat,
Cache ist ein Überlegung wert, sowas hatte ich auch mal vor ein paar Jahren. Allerdings dürfte ein Checksum-Vergleich zwischen einer lokalen Datei und dem Inhalt einer DB mehr Rechenleistung erfordern, als doch gleich die Seite ohne Umschweife aus der DB zu lesen und an den Browser zu liefern.
Außerdem muss in dem Verzeichnis, wo die statischen Seiten liegen, der Webserver ein Schreibrecht haben. Wie auch immer, dann hätten wir ja noch die Möglichkeit, das per Cron zu erledigen oder per Ajax.
Oder mit fastCGI ;)
Hotte
hi,
auf http://rolfrost.de/webtree.html (weiter unten) hab ich mal beschrieben, wie ich das nun praktisch realisiert habe. Alle Seiten auf meinem Server sind nun kein HTML mehr.
Das Erstellen/Editieren neuer Seiten ist jetzt ein Kinderspiel geworden:
Body im TexPad editieren und mit einem Tastendruck ist die Seite online sowie der Index/Navigation/Verlinkung aktuell. Ein extra Suchindex ist auch nicht mehr zu erstellen, die komfortable Volltextsuche greift direkt in den Content, der in einer MySQL-DB abgelegt ist.
Hotte