Ankündigung

Einklappen
Keine Ankündigung bisher.

einfaches Blog System so umsetzbar?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • einfaches Blog System so umsetzbar?

    Hallo Leute,

    ich benötige ein einfaches Blog System, das dabei auch suchmaschinen freundlich sein soll. Das auch möglichst schnell. Ich möchte es früher oder später openSource machen. Deswegen habe ich mir folgendes gedacht:

    So viel ich weiß, mag Google statische Seiten, die es schon lange gibt. Deshalb wollte ich pinrzipiell HTML Dokumente erstellen. Das sollte ja prinzipiell möglich sein. Auch Mehrsprachigkeit ist wichtig. Ich dachte deshalb, dass ein Aufbau nach Sprachkürzel, ISO Datum und Slug als Dateiname sinnvoll wäre. Der Slug ist dabei bei jeder Sprache gleich. Zum Beispiel:

    www.example.com/de/2017-01-26/creating-apps.html
    www.example.com/en/2017-01-26/creating-apps.html
    www.example.com/fr/2017-01-26/creating-apps.html

    Prinzipiell ist das ok, aber erzeuge ich damit nicht Duplicate Content? Denn ich möchte darin auch Meta Tags abbilden, die bei jeder Sprache gleich sind. Also in den oben gezeigten Beispiel würden dann genau die gleichen Meta Tags enthalten sein.

    Die Erzeugung dieser Seiten sollte im Backend auch leicht sein: TinyMCE hergenommen und das da rein geladen, und vielleicht vorher noch den <head> Bereich abgeschnitten. Zusätzlich dazu einen HTML Crawler, der die Meta Tags einliest und zurückschreiben kann.

    Zum Speichervorgang der HTML Dokumente selbst gäbe es zwei Möglichkeiten:
    1. Direkt per PHP Speichern (Webserver Benutzer, eher schlecht).
    2. Eine Message an RabbitMQ schicken, worauf hin es dann der Consumer abpseichert. Damit kann das Abspeichern Skript von einem anderen Benutzer ausgeführt werden, folglich braucht der Webserver Benutzer keine Schreibrechte. Aber kann man ein ganzes HTML Dokument in die Message packen?

    Ich wollte auch eine kalendarische Darstellung machen, das heißt, Tage im Kalender hervorheben, die einen Blog Eintrag haben. Das wollte ich mittels PHP DirectoryIterator machen. Ebenso für die Ermittlung, in welcher Sprache es den Blog Eintrag noch gibt. Mein Ziel ist es, damit gänlich auf eine Datenbank zu verzichten. Warum? Nun ja, in der iX gab es neulich einen Artikel über Webseitenoptimierung. Darin wurde beschrieben, dass Caching zwar gut ist, aber nicht das eigentliche Problem löst: Warten auf die Datenbank. Folglich: Wenn ich keine habe, muss ich auf keine warten. Die DirectoryIterator Klasse ist eine PHP interne Funktion, also eine C Funktion => schnell => Damen hoch!

    Die Übersetzungen wollte ich in po Dateien packen, wie es Wordrpess macht oder es mal gemacht hat. Wenn ich mich nicht irre, gibt es sogar eine PHP Extension. Wordpress wird häufig eingesetzt, das heißt, das geht selbst bei den billigsten Hoster.


    Zu dem Problem PHP in HTML Dateien:
    Soviel ich weiß, bzw. wie ich es neulich hier gesehen hatte, wird das nicht automatisch ausgeführt, da der Webserver meint, dass in einem HTML Dokument kein PHP enthalten ist.

    Lösung 1:
    AddHandler Eintrag in die .htaccess Datei

    Lösung 2:
    RewriteRule dafür anlegen. Ist denke ich eher schlechter, aus zweierlei Gründen:
    1. Es wird immer PHP ausgeführt, bzw. alles darüber geleitet.
    2. Die Portierbarkeit geht eventuell verloren, denn nicht jeder Hoster unterstützt URL Rewriting.


    Für die Übersetzung, oder besser gesagt, für die Daten, die sich so schnell nicht ändern werden und die nur einmal eingelesen werden müssen, könnte man einen Redis dahinter schalten. Sollte dann deutlich schneller gehen, wenn die Übersetzung gecacht sind, bzw. die Directory Iteration.


    Was haltet ihr davon? Ist das so machbar? Habt ihr vielleicht bessere Vorschläge, zum Beispiel ein vorhandenes System nutzen, dass die Anforderungen erfüllt?


    MFG derwunner

  • #2
    Ich denke das was du brauchst ein "static site generator" wie etwa https://sculpin.io/ dort erstellst du markdown dateien, diese sind in 2 teile aufgeteilt, oben im header sind meta informationen unten ist der Content, anschließend wird ein PHP Prozess angestoßen der dann dir statische html dateien generiert.

    für die Vorschau wird der Built-in webserver von PHP genutzt, alternativ kann man auch deployment damit konfigurieren.

    Es wird auch keine Rewrite Rules geben, denn sculpin generiert dir die Ordnerstruktur, du hast dann richtige HTML Dateien in den Ordnern
    apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

    Kommentar


    • #3
      BlackScorp Prinzipiell, ja, danke, gute Idee. Aber das Teil bringt mir schon wieder zu viel Struktur und anderen Krims Krams mit.

      Also, ich habe mich mal erkundigt. Duplicate Content erzeugen die Meta Tags für die Sprachversionen des gleichen Beitrags nicht, weil es vom URL her unterschiedlich ist und auch sonst unterscheidet es sich im Inhalt. Da ich es besser heut als morgen brauche, werde ich noch heute damit loslegen.

      Ich habe mir folgenden Aufbau gedacht:
      Frontend:
      Struktur nach Sprachen und Datum wie eingangs festgelegt, allerdings werde ich PHP Dateien anlegen. Ein Zusatz noch: Ich möchte auch Kategorien haben, das heißt unterhalb des Sprachkürzels kommt noch die Katogerie.
      Das einzige dynamische in der Seite werden dann die verlinkten Blogbeiträge sein. Das Ergebnis vom DirectoryIterator wird dann im Redis gecacht, oder File Cache, falls kein Redis vorhanden. Letzteres ist mit HInblick auf openSource so angedacht. Den Aufbau des DirectoryIterators kann man ja trotzdem in eine eigene Klasse auslagern, wo es dann in jedem Blog Beitrag nur ein einzeiliger Aufruf wird.

      Backend:
      Nun ja, ganz ohne Datenbank werde ich wohl nicht auskommen, denn für den Login habe ich lieber noch ein Passwort davorgeschalten. Einfach den Hash in eine YAML Datei schreiben möchte ich auch nicht.
      Das heißt, es wird eine Datenbank für den Login benötigt. Es wird ein Console Skript geben, mit dem man sich sein Passwort hashen kann. Eine Änderung soll zusätzlich auch über das Backend möglich sein.
      Ich möchte auch Twig Templates verwenden für den Seitenaufbau selbst. Man kann die ja rendern lassen und dann den String in eine Datei schreiben. In dem Twig Template selbst werde ich dann eine Kennzeichnung einbauen, an welcher Stelle der PHP Code soll. Via file_get_contents kann man das dann ja "unscharf" in den gerenderten String erstezen. Vielleicht nicht ganz sauber, aber so muss ich wenigstens nicht auf Twig verzichten. Die Dateien werden im web Verzeichnis unter den jeweiligen Sprachkürzel landen. Die Sprachkürzel Ordner sind beschreibbar.
      Zum Thema Caching: Der Cache muss ja nur verändert werden, wenn ein Autor einen neuen Blogbeitrag hinzufügt. Also wird der Cache dadurch neu aufgebaut.


      Composer Dependencies:
      hautelook/phpass
      Symfony YAML Component (für Redis config und so)
      predis

      Generell im Backend: Autoloading nach PSR-4.

      Kommentar


      • #4
        derwunner ach diese PHP Entwickler, eine YAML Datei nehmen und in HTML umwalden lokal ist zu viel "Krims Krams" aber Redis, und Backend mit login und co ist nicht zu viel "Krims krams" ?

        Schau dir unsere Wissensdatenbank an, da sind Yaml files auf github und diese werden von Jekyll in HTML umgewandelt und gerendert, "Login" passiert über github + Pullrequests. Dateien müssten nicht mal gehostet werden, alles macht github und lokal kann man schön markdown content einpflegen. Kannst branches für Drafts machen usw.. Paradies für entwickler

        apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

        Kommentar


        • #5
          Warum das Rad neu erfinden
          http://www.nibbleblog.com/demo/en/

          Kommentar


          • #6
            Zitat von protestix Beitrag anzeigen
            Warum das Rad neu erfinden
            http://www.nibbleblog.com/demo/en/
            echt jetzt?
            apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

            Kommentar


            • #7
              Zumindest kann er sich den Quellcode rein ziehen und Anregungen holen, wenn er wissen will wie das andere gelöst haben.

              Kommentar


              • #8
                Zitat von protestix Beitrag anzeigen
                Zumindest kann er sich den Quellcode rein ziehen und Anregungen holen, wenn er wissen will wie das andere gelöst haben.
                allein die aussage

                "Symfony YAML Component (für Redis config und so)
                predis
                Generell im Backend: Autoloading nach PSR-4."

                sagt schon aus dass derwunner weiter ist als das was du als Beispiel zeigst. Da fehlt PSR, Tests und alle andren best practices von PHP. Sich davon anderungen holen wäre nur Kontraproduktiv
                apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                Kommentar


                • #9
                  Das mit YAML zu HTML habe ich auch schonmal in Erwägung gezogen, allerdings hat YAML das Problem, es ist nicht an die Reihenfolge gebunden. Das eingelesen Array kann also irgendwie kommen. Dann steht halt z. B. mal der Footer über den Header. Deswegen verwende ich für sowas kein YAML. Hatte nämlich ein ähnliches Problem und hatte mich in die YAML Dokumentation eingelesen. Da stand nichts davon, dass das ganze strukturabhängig ist.

                  Oh und phpass verwende ich deswegn, weil es gut ist und ich mich mit den hash Funktionen in PHP nicht wirklich auskenne. Es gibt zwar eine Funktion, die es erleichtern soll, die ist aber erst ab einer relativ hohen PHP 5 Version verfügbar. Und ich möchte von 5.3 bis 7.1 alles unterstützen. Außerdem vertraue ich den hautelook Typen, der hat auch schon Fixtures für Doctrine/Symfony Bundles gebaut.


                  PS: Stand bisher:
                  - Datenbank für den Backend Login.
                  - DB Tabellen für das Beitrag / User Mapping. Damit man auch seinen Namen ändern kann und es in den alten Templates trotzdem übernommen wird. Soll ja mal vorkommen, dass Menschen ihren Namen ändern.
                  - Ich habe ein Template, das inhaltlich gleich ist, es bindet nur die unterschiedlichen Daten ein anhand der __FILE__ und __DIR__ Konstanten.
                  - Die Daten werden in einfachen PHP Dateien abgelegt via var_export. Diese kann ich dann leicht in mein Twig Template einbinden und zur Not auch on-the-fly die Cache File dazu generieren. Mit dem @ Zeichen davor sogar Fehler unterdrücken, dann wirds beim nächsten Aufruf einfach nochmal generiert, tut ja keinem weh. Später soll es dann noch mittels Monolog geloggt werden, wenn es zu so einem Fehler kommt.
                  - Es landet wirklich nur das PHP Template im Web Folder, um Suchmaschinen Missverständnisse jeglicher Art gleich von vorne herein zu vermeiden. Alles andere ist eine Ebene über den Webserver DocumentRoot.
                  - In meinen Templates verwende ich auch den Symfony HTTP Foundation Kompenente, lässt sich also auch schön lesen, falls da sich mal jemand rein lesen muss.
                  - Ich versuche noch irgendwie die Bootstrap Twig Templates von den eigenen Templates abzutrennen, damit die eigenen Templates von Git ignoriert werden, man aber ein Submodule oder ähnliches machen kann für die eigenen Templates.
                  - Ein Cache Warmer, bzw. Template Regeneration ist vorgesehen. Ich ziehe hierfür auch in Erwägung, Threads zu verwenden. Also per DirectoryIterator alles auslesen, die Arbeit gleichmäßig auf die Threads aufteilen und noch einen Thread für Socket Connection (Fortschritt Balken fürs Frontend). Letzterer könnte eventuell sogar über WebSockets angesprochen werden. Bin da aber nicht mehr auf dem Laufenden, in wie weit schon WebSockets unterstützt werden. Wenn die Regeneration vollbracht ist, ob single Threaded oder Multi Threaded, soll eine E-Mail rausgehen.

                  Kommentar


                  • #10
                    ok ich sehe schon.. hier geht es nicht um das Endprodukt sondern um die Entwicklung und möglichst absurde dinge zu kombinieren.

                    1) YAML sollte nur für metadaten da sein, nicht für layout.. was hat das mit Footer etc zu tun?
                    2) PHP 5.3.. wtf, php 5.6 wird nur noch mit Security patches gefixt, alles andere hat bereits sein end of live erreicht.
                    3) @ Zeichen ist ein Codesmell
                    4) "In meinen Templates verwende ich auch den Symfony HTTP Foundation Kompenente, lässt sich also auch schön lesen, falls da sich mal jemand rein lesen muss." ok du mischt also Inhalt mit Darstellung und findest es schön zu lesen?

                    zu den weiteren Punkten, werde ich nichts sagen..

                    im Großen und Ganzen frage ich mich, weißt du was du da tust? Es gibt Personen, die ein Blog wollen, diese nehmen fertige Lösungen, wie Wordpress, OctoberCMS etc und dann gibt es leute die nur etwas Rumalbern wollen die erstellen dinge, verkomplezieren irgendwie alles. Erinnert mich gerade an den Spruch "Just rewrote my app from Backbone to Angular, feels good to make progress".

                    my 2ct
                    apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                    Kommentar


                    • #11
                      BlackScorp Ich sehe schon, ich werde wieder deutlich verstanden xD
                      Ok, dass es bei den YAML Sachen nur um Meta Daten geht, muss ich wohl auch überlesen haben. Ich bin auch nicht dafür, die eigentlichen Daten, die normalerweise in der ein Datenbank liegen in XML Dateien abzuspeichern. Da muss es wieder nur eingelesen werden und einen Index oder ähnliche Technologien zum schneller drüber lesen gibt es dort auch nicht. Da da das eh kein Mensch sich ansehen wird, reicht es doch in pretty plain PHP mit var_export. Arrays in PHP sind gleichzusetzen mit Hash Maps und dadurch deutlich schneller als irgendwas von XML einzulesen.
                      Und ja natürlich geht es hier auch mit um Code, die Frage war ja, ob das so umsetzbar ist. Wie soll man es sonst Deiner Meinung nach heraus finden?
                      Zu 3): Das eine Code Smell kann man schon verkraften. Konventionen decken ja auch nur den Allgemeinfall ab. In speziellen begründeten Einzelfällen kann man schonmal davon absehen. Außerdem kommt das eh bald raus, denn um das Loggen zu können, muss ich ja ein file_exists vorschalten.
                      Zu 4): Pseudo Code für das Template (vom Client abrufbare PHP Datei) sieht in etwa so aus (nach aktuellem Stand der Dinge):
                      PHP-Code:
                      <?php
                      // Symfony HttpFoundation
                      $request Request::createFromGlobals();

                      // GZip Unterstützung prüfen => folglich:
                      $response->headers->set(...)

                      // Daten basierend auf der Herkunft holen:
                      $data TemplateManager::getData(__FILE__);
                      $tpl TemplateManager::getTemplate(__FILE__);

                      // Gzip komprierten Inhalt vom Cache Verzeichnis auslesen, falls vorhanden), ansonsten:
                      // wegen des statischen Templates muss ja das nicht jedes mal via ob_gzhandler geschehen
                      $content $twig->render($tpl$data);

                      $response->setContent($content);

                      $request->validate($response);
                      $response->send();

                      // Ende
                      Wie gesagt Pseudo Code, recht überspitzt ausgedrückt, aber Ablauf sollte damit erkennbar sein.

                      Kommentar


                      • #12
                        Irgendwie werden hier mit jedem Post neue Technologien und Anforderungen in den Raum geworfen. (Zwischendurch noch ein Kommentar à la "Letzteres ist mit HInblick auf openSource so angedacht."... wtf^^)

                        Möchtest du eigentlich tatächlich Antworten oder willst du nur zeigen womit du arbeitest und wovon du Ahnung hast?
                        Kannst du nochmal das Ziel beschreiben, ohne dabei bereits auf mögliche Lösungsmöglichkeiten einzugehen?
                        [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
                        [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

                        Kommentar


                        • #13
                          Zitat von VPh Beitrag anzeigen
                          Kannst du nochmal das Ziel beschreiben, ohne dabei bereits auf mögliche Lösungsmöglichkeiten einzugehen?
                          Ähm nein, kann ich nicht, weil der Thread sich mit der Machbarkeit beschäftigt.

                          Ziel ist es, ein einfach Blog System zu haben, dass statische Seiten generiert ohne URL Rewriting oder sowas. Also einfach ganz klassisch eine Seite entspricht einer Datei, die per URL abrufbar ist. Das ganze soll dabei auch Mehrsprachig sein. So, das heißt, es soll auch die gleiche Seite zum Beispiel in Englisch geben. Bei dem eine Datei pro URL ist das prinzipiell auch kein Problem. ABER: Es wird eine Möglichkeit benötigt, die statischen Seiten neu zu generieren. Weil was ist, wenn der Autor zum Beispiel seinen Namen ändert? Dann steht das mit reiner Statik in den alten Beiträgen falsch in und den neuen richtig drin.
                          Deswegen kam ich auf den Gedanken, es wäre doch praktisch Daten getrennt vom Template zu haben. Da es bei dem Projekt auch um Page Speed geht und weniger darum "wie halte ich die meisten Software Patterns ein?", dachte ich, wäre es sinnvoll die Daten direkt in seperaten PHP als Array abzulegen. Also dass dann im Web Ordner die Abrufbaren PHP Dateien selbst liegen, die aber keine Daten enthalten. Die sind eigentlich bloß für den Slug, also für den eindeutigen URL Titel da. Jede abrufbare Datei weiß ja durch die __FILE__ Konstante, wie sie heißt. Und das möchte ich mir zu Nutze machen, indem ich diese Konstante an einen Daten Lade Manager übergebe, der dann passend zum aufgerufenen URL die Daten lädt.
                          Da es aber wie bereits erwähnt auch vorrangig um Page Speed geht, möchte ich die gerenderten Daten in einem Cache speichern. Da es auch nicht nötig ist, jedes mal PHP on-the-fly zu gzippen, kann die Cache File gleich im Gzip Format abgelegt werden.
                          Also man kann sagen, ich versuche das Frontend komplett ohne Datenbank im Hintergrund zu gestalten. Nur das Backend braucht eine für den Login und für das Autor zu Beitrag Mapping.

                          So, ich hoffe, das war nun besser verständlich, was ich vor habe.

                          Kommentar


                          • #14
                            Und was für einen Vorteil/USP soll das ganze gegenüber den hier genannten haben?
                            Mehr noch sehe ich bei deinem Projekt viel mehr Nachteile gegenüber den obigen.

                            Ich kann mir nicht vorstellen, dass ein Blog Autor für jeden Blog-Eintrag eine Datei im Dateipfad anlegen möchte. Möchtest du Kategorien ebenfalls im Dateisystem abbilden? Was passiert, wenn der Autor dann Seiten verschiebt?

                            Wenn du die gerenderten Daten in einem Cache speichern möchtest haben wir doch am Ende vom Tag nix anderes als ein System, das statische HTML Seiten generiert, die dann statisch abgerufen werden können?

                            Es liest sich so wie damals die Idee zu Jekyll ... aber wie gesagt damals.
                            "Software is like Sex, it's best if it's free." - Linus Torvalds

                            Kommentar


                            • #15
                              JaMa Ja, also ich möchte schon per WYSIWYG Editor den Autor statische HTML Seiten anlegen lassen. Diese sind einer Kategorie und einem Sprachschlüssel zugewiesen. Und der Beitrag landet dann automatisch im Unterordner für das jeweilige Datum, an dem dieser erstellt wurde. Also wenn ich heute einen deutschen Beitrag in der Kategorie "php" erstellen würde mit dem Namen "einstieg-in-php", dann würde nach dem Speichern der Abrufbare URL so aussehen:
                              http://www.example.com/de/php/2017-0...ieg-in-php.php

                              Und wie bereits oben erwähnt, ist es aktuell so vorgesehen, dass die Datei einstieg-in-php.php das Template selbst ist. Und genau die Datei enthält den Code wie oben in dem Pseudo Code Beispiel gemacht. Was aktuell passiert, bzw. was passieren wird, wenn der Autor auf speichern klickt:
                              1. Die Daten werden der zetralen Klasse TemplateManager übergeben. Als Parameter hat man dann den Sprachschlüssel, den Kategorienamen, das Datum (kann aber auch intern angelegt werden), und den Beitragnamen, also den Slug selbst.
                              2. Der Template Manager geht dann her und kopiert die Template Vorlage in nach web/de/php/2017-02-15/einstieg-in-php.php.
                              3. Die Daten, also der Beitrag selbst landet in var/data/de/php/2017-02-15/einstieg-in-php.php. Die Datei enthält ein simples Array mit der Autor ID und den Beitrag selbst (als String).

                              Nachdem beide Dateien abgelegt sind, kann der URL von der Öffentlichkeit aufgerufen werden. Der Datenordner liegt außerhalb des DocumentRoot ist somit für niemanden sichtbar. Der Web Ordner, also der vhost DocumentRoot muss vom Webserver Benutzer beschreibbar sein. Ein verschieben der Blogbeiträge ist nicht vorgesehen. Das ist der Stand bisher und eben auch gleichzeitig die Frage, ob das so Sinn macht.

                              Kommentar

                              Lädt...
                              X