Seitenarchitektur

[mhuettl]

Hallo,

ich bin seo neuling, versuche nun meine ersten schritte und fange natürlich mit der onpage optimierung an.

ich habe mir ein kleines CMS programmiert, dass ich für meine kleinen Projekte verwenden möchte.

Im Backend kann man Seiten, Beiträge und Events anlegen.
All diese Elemente besitzen einen Titel

Seite1 -> Titel: Home
Beitrag1 -> Titel: Tag der offnen Tür
Event1 -> Titel: Zeltfest

Aus diesem Titel generiere ich einen slug, zb. wird aus Tag der offnen Tür "tag-der-offenen-tuer".

Um auf diese Seite zu kommen, muss ich nur die Domain https://www.example.com/tag-der-offenen-tuer aufrufen und ich bin auf dem Artikel.

Also auch, wenn eine Seite eine Unterseite einer anderen ist, dann finde ich sie trotzdem mit www.exaple.com/unterseite

Alles was hinter dem Domainnamen steht, wird in einer DB gesucht uns wenn es einen Match gibt, wird dieses Element geladen.

[ole1210]

42

[e-fee]

Und Deine Frage ist jetzt genau welche?

Aus eigener Erfahrung - vor zehn Jahren habe ich auch meine eigenen kleinen CMSe programmiert, bin dann aber irgendwann auf Open Source-Lösungen umgestiegen -, den dabei gemachten Fehlern und den Kenntnissen der Architektur bestehender Systeme heraus möchte ich aber sagen, dass Dein Ansatz nicht sonderlich praktikabel ist.

Und zwar aus folgendem Grund: Jeder Beitrag sollte eine eindeutige ID haben - im Normalfall wird dies eine Zahl sein. Jedenfalls nicht der Seitentitel.
Dein Ansatz wird genauso lange funktionieren, bis Du den Titel einmal änderst. Dann stellt sich nämlich die Frage, ob sich die URLs auch ändern sollen. Falls ja, wirst Du direkt auf der ganzen Seite, in allen Menüs, die Verlinkungen anpassen müssen. Entweder manuell oder Du musst Dein CMS noch um eine Redirect-Routine erweitern, was aber auch keine sonderlich schicke Lösung ist. Oder die URLs bleiben gleich, aber dann gibt das irgendwann Kuddelmuddel.
Es kann ja auch theoretisch sein, dass Du irgendwann einen zweiten Beitrag mit dem gleichen Titel haben möchtest.
Hierarchische Strukturen ließen sich damit auch besser realisieren, wenn man das Ganze noch etwas besser ausarbeitet.

Die gängigen CMSe arbeiten intern, vor allem für Menüstrukturen, Beitragslisten und dergleichen, immer mit dieser ID, auch wenn man von außen nur die schicken sprechenden URLs sieht. Die Jungs und Mädels dort in den großen Communities wissen schon, was sie tun und warum sie das tun.

Deine Bemühungen in allen Ehren, aber man muss nicht immer gleich das Rad neu erfinden. Deine bisherige Vorgehensweise lässt darauf schließen, dass Du nicht so furchtbar viel Ahnung von der Architektur eines CMS hast. Das wiederum lässt vermuten, dass Du Dir durch Eigenprogrammierung auch diverse Sicherheitslücken ins Haus holst, die lediglich durch eine gewisse Security by Obscurity (weil Dein System keiner kennt) etwas entschärft werden.
Warum, wenn es eine kleine bis mittelgroße Seite ist, nicht einfach ein Wordpress oder Contao hernehmen?
(Ich selbst arbeite zwar schwerpunktmäßig auf Drupal, sehe das aber für kleine Seiten mittlerweile auch als Overkill an.)

[Melegrian]

Weil ein kleines schneller ist, weniger DB-Abfragen benötigt, bestenfalls nur eine für die Beitragsseiten, niemand weiß, wo die Login-Seite liegt usw..

Würde aber wenigstens id | kategorie | seite | titel | usw. nehmen.

Name der Seite erfasse ich immer einzeln, weil der zuweilen auch kürzer sein soll als der Titel.

Das mit der Sicherheit ist richtig, da sieht man häufig gravierende Fehler. Es bringt nichts, wenn eine Seite so und so erreichbar ist, es soll nur eine bestimmte Seite in einer bestimmten Kategorie erreichbar sein.

Neu würde ich auch nicht mehr unbedingt ein eigenes Script verwenden, nur meine uralten, einst mit FrontPage angelegten Seiten, die habe ich dann alle so mit dem ursprünglichen Seitennamen übernommen, so dass sich da nichts von der Struktur änderte.

Wegen der Struktur wird wiederholt gefragt, doch die ist halt so, wie man Seiten nach Kategorien in Verzeichnisse einlagern würde.

[e-fee]

Weil ein kleines schneller ist, weniger DB-Abfragen benötigt, bestenfalls nur eine für die Beitragsseiten

Auch da gibt es aber schon gute Lösungen, bis hin zu welchen, die ganz ohne DB auskommen.

Ich kann mir auch ein kleines, vierrädriges Gefährt selbst zusammenschweißen - reicht doch, um von A nach B zu kommen?

[Melegrian]

Auch da gibt es aber schon gute Lösungen, bis hin zu welchen, die ganz ohne DB auskommen.

Ich kann mir auch ein kleines, vierrädriges Gefährt selbst zusammenschweißen - reicht doch, um von A nach B zu kommen?

Ja sicherlich, ich bezog das auch mehr auf CMS, die bereits um die Tausend Scriptseiten nach der Installation enthalten, mehrsprachig ausgelegt sind, obwohl nicht benötigt, spätestens nach dem 20. Plugin so unsicher sind, wie ein offenes Scheunentor usw..

Und wer weiß schon, vielleicht ist ja sein kleines CMS sicher und gut.

[e-fee]

Auch da gibt es aber schon gute Lösungen, bis hin zu welchen, die ganz ohne DB auskommen.

Ich kann mir auch ein kleines, vierrädriges Gefährt selbst zusammenschweißen - reicht doch, um von A nach B zu kommen?

Ja sicherlich, ich bezog das auch mehr auf CMS, die bereits um die Tausend Scriptseiten nach der Installation enthalten, mehrsprachig ausgelegt sind, obwohl nicht benötigt, spätestens nach dem 20. Plugin so unsicher sind, wie ein offenes Scheunentor usw..

Und wer weiß schon, vielleicht ist ja sein kleines CMS sicher und gut.

Na, ich bin da jetzt nicht gerade sehr optimistisch. Schon allein

Alles was hinter dem Domainnamen steht, wird in einer DB gesucht uns wenn es einen Match gibt, wird dieses Element geladen.

klingt nach 'ner tollen Möglichkeit für SQL-Injections und ähnliche Scherze. Schreib ich jetzt als jemand, der auch nicht viel Ahnung von Detailfragen zur Absicherung hat, aber ich kenne meine Grenzen. Trial&Error ist da nicht so gut.
Übrigens hatte ich in grauer Vorzeit (ist wirklich schon ganz lang her, da war ich noch hobbymäßig unterwegs) mal ein ähnliches Konstrukt geschrieben, als mein 1&1-Webspace noch keine Datenbank hatte, wohl aber PHP konnte. Da hab ich dann die Inhalte aus .txt-Dateien gezogen, die wie "alles hinter dem Domainnamen" hießen. Da bekam ich sogar von dem Laden, der ja sonst nicht mit der Riesen-Kompetenz gesegnet ist, aus freien Stücken eine Mail, dass mein Konstrukt da ein wenig anfällig sei ...

[Melegrian]

Gut, dann ein Beispiel, wie ich das in etwa mit meinen alten HTML-Seiten gemacht habe, um die in ein kleines, selbstgestricktes CMS einzupflegen, Parameter und sonstige Bezeichner wurden geändert, der Code leicht verändert, will ja nicht den von mir verwendeten veröffentlichen. Somit könnten sich jetzt Fehler eingeschlichen haben, da in dieser Schreibweise jetzt alles ungetestet ist.

Beispiele für URLs:

Code: Alles auswählen

"www.example.com/heimtiere/kleine-katzen.html"
"www.example.com/heimtiere/junge-hunde.html"
"www.example.com/events/rasseschau-2016.html"

In der htaccess möglichst wenig (.*) verwenden, sondern möglichst nur die Zeichen, die auch in den URLs vorkommen dürfen. Halte ich zumindest bereits für eine erste Filterung.

Beispiele für htaccess:

Code: Alles auswählen

RewriteCond %{QUERY_STRING} !^.*nur=so$
RewriteCond %{QUERY_STRING}  ^kategorie=heimtiere&beitrag=([a-z_-]+)$
RewriteRule ^bord/beitraege.php             /heimtiere/%1.html? [L,R=301]
RewriteRule ^heimtiere/([a-z_-]+)\.html$    /bord/beitraege.php?kategorie=heimtiere&beitrag=$1&nur=so [QSA,L]

RewriteCond %{QUERY_STRING} !^.*nur=so$
RewriteCond %{QUERY_STRING}  ^kategorie=events&beitrag=([a-z0-9_-]+)$
RewriteRule ^bord/beitraege.php            /events/%1.html? [L,R=301]
RewriteRule ^events/([a-z0-9_-]+)\.html$   /bord/beitraege.php?kategorie=events&beitrag=$1&nur=so [QSA,L]

Dann die Datei beitraege.php:

Code: Alles auswählen

if (isset($_GET["kategorie"])
      and !empty($_GET["kategorie"])
      and  isset($_GET["beitrag"])
      and !empty($_GET["beitrag"])) {

// GET oder POST muss immer gefiltert werden.

    $var_kategorie = preg_replace("/[^a-z_-]/",    "", $_GET["kategorie"]);
    $var_beitrag   = preg_replace("/[^a-z0-9_-]/", "", $_GET["beitrag"]);

// Hier könnte eigentlich bereits eine Abfrage als Prepared Statement erfolgen.
// $sqli muss vorher noch definiert werden, am besten in einer Klasse.

    if ($stmt = $sqli->prepare("
                  SELECT kategorie, seite, titel, text
                    FROM ausgewaehlte_tabelle
                   WHERE kategorie = ?
                     AND seite = ?
                  ")) {

        $kategorie  = $var_kategorie;
        $seite      = $var_beitrag;

        $stmt->bind_param("ss", $kategorie, $seite;
        $stmt->execute();
        $stmt->bind_result($kategorie, $seite, $titel, $text);

        // Vorbereitung für Ausgabe ab hier ...
        // Ohne store_results wird je nach PHP-Version nur 0 geliefert.

        $stmt->store_result();
        $ergenis = $stmt->num_rows;   // 1 oder 0
        $stmt->close();
    }
    if ($ergenis == 0) {
        // Weiterleitung falls nichts gefunden.
    }
}
else {
    // Weiterleitung falls ein Fehler auftritt.
}