hotti: Das Web aus der Datenbank

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

--
Achtung: Lange Leitung.
  1. 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

    1. Hi,

      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.

      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

      --
      Light travels faster than sound - that's why most people appear bright until you hear them speak.
      1. 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

        --
        Ich sag doch: Lange Leitung.
    2. 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?

      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

      --
      ><o(((°>           ><o(((°>
         <°)))o><                     ><o(((°>o
      Der Valigator leibt diese Fische
      1. 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

        --
        Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
  2. 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:

    • im lokalen Index (das ist eine ini-Datei) notieren, wie die Einzelseite heißt, das kann auch ein CGI-Script sein; in der ini wird außer dem "Dateinamen" der Titel und eine kurze Beschreibung notiert,
    • wenn kein CGI, erstelle ich die Datei in einem gesonderten lokalen Ordner ohne <head></head> und ohne </body></html> also nur den Body,
    • Und dann kommt der große Klick, der mir den ganzen Kram samt virtuellen Ordnern erstellt und zu meinem MasterScript auf dem Webserver schickt, was den Content in eine MySQL-Tabelle einbaut (url, title, body, virtualfolder).

    Das ist wie ein Tag, wo Weihnachten und Ostern zusammenfallen! Ich bin echt begeistert :-)

    Viele Grüße an Alle,
    Hotti

    --
    Nüschd.
    1. 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

      1. 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

        --
        Hotte ist ein fauler Sack.
      2. ... 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

        --
        ><o(((°>           ><o(((°>
           <°)))o><                     ><o(((°>o
        Der Valigator leibt diese Fische
        1. 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

  3. 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

    --
    Nachdenken lohnt sich manchmal ;-)