Es gibt zu Editland keine Seitenzahlbegrenzung, jedoch verliert Editland ab der 50sten Seite rapide im Bereich Spassfaktor, wenn es um das Ergänzen einer Seite weit oben in der Hirarchie geht. Einer meiner Kunde hält bei der 400 Seite noch immer an Editland fest. Eine Frage der Prioritäten.
Weblog ist ein Datenbanksystem und bietet verschiedene Möglichkeiten die Seite zustrukturieren. Es hat nicht wie Editland nur eine einzige hirarchische Navigationsstruktur. Die Menüstruktur ist sehr stark auf die Tagebuchfunktion abgestimmt, was sich insbesondere bei Vielschreibern nachteilig auswirkt, wenn es darum geht Beiträge wiederzufinden.

Sowohl Editland als auch Weblog können hier durch sogenannte Plugins dazugewinnen.

Editland ist speziell für überschaubare Sites entwickelt worden.
Weblog ist speziell für Seiten geschrieben worden, die weit zurück in die Vergangenheit, Beiträge Archiviert und wieder zugänglich macht.

Editland kommt dem Nutzer entgegen bei der Organisation der Seiten.
Weblog ist etwas Sperrig, bei der Organisation der Seiten. Nachträgliches Reorganisieren ist immer davon Abhängig, welche Zusatzinformationen zur Seite man angelegt hat. Je älter die Site wird, desto starrer wird diese in ihrer Struktur.

Editland ist dynamisch, denn die Inhalte lassen sich schnell und bequem ändern. Doch Vorversionen gehen unwiderruflich verloren, hat man erst einmal gespeichert.
Auch Weblog hat keine Versionsverwaltung, doch dort wo in Editland eine Entscheidung über Sinn und Unsinn des Beitrages, über Aktualität und Priorität der Inhalte getroffen wird, wird in Weblog einfach ein neuer Beitrag an die erste Stelle gesetzt und der alte und der neue Beitrag miteinander verlinkt.

Editland-Sites sind wie alle im Umfang stark begrenzten Seiten stark fokusiert. Inhalte werden mit mehr sorgfalt konzipiert und umgesetzt. Thementreue und Themendisziplin ergeben sich durch den gesetzten Rahmen fast wie von selbst.
Das Weblog ist ein leichtes Plätschern, das zur Konversation anregt und dabei immer wieder den Fokus verliert. Inhalte werden mit einer gewissen Leichtigkeit konzipiert und umgesetzt. Das Abschweifen in artfremde Themen, die Neigung Themendisziplin schleifen zu lassen ergibt sich fast automatisch.

Editland hält einem Massenansturm sehr lange Stand. Wenn ein Beitrag “gediggt” wird, das heißt wenn plötzlich extrem viele Anfragen nach einer Seite vorhanden sind, wird das Editland nicht allzusehr in Schwierigkeiten bringen.
Das Datenbankbsierte Weblog und Wordpress im besonderen ist hier deutlich anfälliger. Ohne WP-Cache oder einem anderen Caching-System, brechen die Datenbanken schon einmal zusammen. Zwar ist nach dem Ansturm wieder alles in Ordnung, doch wäre es schön gewesen, hätte man im schlimmsten Sturm all die willkommenen Besucher empfangen können und den gewünschten Text liefern können.

Wie schnell ein Weblog in die Knie geht, ist auch ein Frage der Plugins. Dies gilt auch für Editland.

Editland hat keine Funktionen integriert, um sich selbst mit anderen Websites zu vernetzten.
Weblogs pingen was das Zeug hält und lassen nichts unversucht, um auf sich aufmerksam zu machen.

Beides hat seine Vor und Nachteile. Sites mit Editland werden von Spämmern weitgehend in Frieden gelassen. Weblogs befinden sich mit den Webspacken im Krieg und das System muss immer wieder aufgerüstet werden. So manche Site wird so überschwemmt, dass nur noch drastische Maßnahmen Abhilfe schaffen.

Bei diesem Plugin wird es dann möglich sein, Seiten zunächst versteckt anzulegen und diese in aller Ruhe fertig zu machen und erst dann in die Navigation zu integrieren.. Hierbei werden Seiten zunächst nur in dei struk.csv eingefügt und fallen damit aus der Navigation ganz raus. Seiten, die in der struk.csv enthalten sind aber nicht in der menudata.csv, erscheinen immer der obersten Ebene zugeordnet.

Will man diese Funktion also nicht nur dazu nutzen stressfrei verborgen vor den Augen der Äffentlichkeit neue Setien zu erstellen, sondern auch Sonderseiten zu schaffen, die separat stehen und nicht in der Navigaiton angezeigt werden, wie z.B. Detailseiten, die nur über das Produktbild erreichbar sein sollen, dann steht man vor der Schwierigkeit, dass diese Seiten außerhalb der Hierarchie stehen, das Menü also zuklappt und je nach Strukturtiefe, der Kunde sich über drei, vier Klicks wieder zum Ausgangsort klicken müsste. Dies ist natürlich ein Unding, zumal der Nutzer häufig nicht einmal wissen wird, in welcher Unterebene er sich gerade befindet.

Bei der Navigationsverwaltung von Editland, die schlicht einfach und clever ist, gibt es keine Möglichkeit, dem System zu sagen, wie die Navigation aufklappen soll. Ein Problem? Nicht wirklich, denn ich kann natürlich jederzeit in einer separaten Liste die übergeordnete Seite zuordnen und eine entsprechenden Link zurück zu übergeordneten Seite anbieten.

Eine solche Navigation nennt sich eine zentrale Navigation oder zentrumsorientierte Navigation, weil immer nur eine Seite als führende Seite zu erreichen ist.

Seiten aus der struk.csv in Editland herausnehmen, führt in die Notwendigkeit eine zentraler Navigation, will man nicht für diese Seiten eine vollkommen neue aufwendige Navigation erzeugen. Da aber solche versteckten Seiten ohnehin eine Sonderrolle spielen, ist eine zentrumsorientierte Navigation durchausangemessen, in der es nur einen Link gibt oder aber einen Link plus die wichtigsten Seiten der ersten Navigationsebene.

Was muss gegeben sein, dass CHMOD 777 zur Plage wird?

Es muss ein Script offen auf dem Server liegen, von dem aus auf den Server geschrieben werden kann, es muss ein offener FTP existieren, mit dem Dateien überschrieben werden können. CHMOD 777 alleine nützt soweit ich bislang rechieren konnte, niemandem etwas. Ich muss zunächst noch eine zweite Tür aufmachen, über die dann die durch CHMOD 777 geöffnete Räume umgestellt, ausgeräumt oder mit weiteren ungebetenen Skripten befüllt werden kann.

Das dieses Thema etwas heikel ist und Provider hier ein wenig empfindlich reagieren, ist sicherlich verständlich, denn es erfordert, dass Traffik kontrolliert werden muss. Nicht alle Provider bieten ein Monitoring und die Traffikbremse an. Wozu braucht man diese Traffikbremse. Nehmen wir an, jemand impft durch ein fehlerhaftes Skript auf Ihrem Server ein Skript mit dem von Ihrem Server aus eine Tauschbörse eingerichtet wird. Anschließend wird auf den Infoservern der Anbieter dieser Dienste mit viel Werbeeinnahmen wieder eine Liste rausgegeben, welche Server zur Verfügung stehen, eventuell gibt es sogar auf dem Infoserver ein Skript, das prüft, welche der so illegal geschaffenen Tauschbörsen-Server noch aktiv sind und welche schon vom Nutzer oder vom Provider wieder geschlossen wurden.

Doch dass so ein Modus 777 zur Falle werden kann, und man ein illegales Skript auf den Server setzen kann braucht es zunächst einmal eine offene Tür in Form eines Scriptes, dessen sich solche typen bedienen können.

Provider überbuchen ihre Server. Das heißt, würden alle auf dem Server ihre eingekauftes Nutzungsrecht bis zur Neige ausschöpfen, wäre der Server sehr schnell am Ende. Wie stark so ein Server überbucht ist und wie die Hostingprovider Backup-Systeme einsetzen, um Spitzen aufzufangen, wenn einmal auf zu vielen der gehosteten Plätze der Bär abgeht, ist von Provider zu Provider verschieden und an der Geschwindigkeit und Erreichbarkeit trennt sich die Spreu vom Weizen.

CHMOD 777 ist sogesehen für mich immer noch ein Feature und keine Sicherheitsrisiko. Das Sicherheitsrisiko ist das unsichere Skript. Wenn ich meine Schlüssel im offenen Wagen stecken lasse, wird mein Auto nicht unsicherer. Ich risikiere allerdings, dass nicht autorisierte Personen mein Fahrzeug nutzen. Tun sie das, wenn ich es ohnehin nicht nutze und fahren damit in eine Stau und verstopfen die Straßen noch mehr, sehe ich das nicht wirklich als mein Problem an, sondern eher als das Problem des Verkehrsleitsystem. Ich habe nur das Problem, dass ich den Sprit bezahlen muss und die Autosteuer.

Nimmt jemand das Fahrzeug, der damit in eine Fußgänger-Zone rauscht und zig Menschen tötet, dann ist das zwar denkbar, aber nicht wirklich wahrscheinlich. Wahrscheinlicher ist, dass ein jugendlicher Rabauke die Gelegenheit nutzt und dadurch ein erhöhtes Risiko entsteht. Mein Auto ist deswegen weder gefährlicher geworden, gefährlicher ist die Nutzungsmöglichkeit.

Ich muss also wenn ich darauf wert lege, dass ich jederzeit mit und ohne Hosentaschen für einen Autoschlüssel mein Fahrzeug bewegen kann, dafür sorgen, dass andere Sicherungsmaßnahmen greifen.

Zurück zu meinem Server und Sicherungsmaßnahmen. Wenn ich per CHMOD 777 sicherstellen möchte, dass mein FTP-User alles das kann, was auch der User WWWRUN darf (wwwrun heißt in der Regel der User, der die Rechte innehält, wenn ein Skript auf dem Server innerhalb eines Redaktionssystems), dann sollte ich sicherstellen, dass nur diejenigen das dürfen, die sich vorher auf andere Weise autorisiert haben und ich sollte für menschliche oder technische Unzulänglichkeit Routinen entwickeln, die die Daten davor schützen, dass diese versehentlich durch einen anderen User überschrieben werden. Im FTP geschieht das durch das Login. Man sollte den FTP nicht länger offen lassen als nötig. Und auch Skripte die Schreibfunktionen enthalten, sollten stets hinter Sicherheitstüren in Form eines Logins per htaccess gepackt werden.

Das nächste Sicherheitsrisiko ist das Browserfenster und Spyware auf Ihrem Rechner. Doch sowohl das Spionieren via Browserfenster, dass z.B. ein Script dafür sorgt, dass Sie die nächsten Seiten in einer Unterinstanz öffnen oder Malware, die jedes Bit und Byte protokollieren sind generell eine Gefahr und haben mit dem Risiko CHMOD 777 soviel zu tun wie der Dietrich oder das Brecheisen des Autodiebs mit dem Beispiel des Schlüssels im offenen Fahrzeug.

Ich lasse mich in der Angelegenheit Sicherheitsrisiko 777 gerne belehren. Doch ich sehe in 777 alleine kein Sicherheitsrisiko. Es sind wenige Zusatzsicherungen, die man beachten muss und sind in ähnlicher Weise zu sehen, wie die Funktion von Mailfunktionen in Programmiersprachen, die insbesondere in PHP in den letzten Wochen zu massiven Spamproblemen geführt haben. Hier wurden PHP-Mailformulare mit Skripten geimpft und zahlreiche Formulare mussten nachgrüstet werden mit Abfragen und Filtern um auszuschließen, dass Spammer via CC und BCC ihre Spammails in die Welt blasen.

Meine Empfehlung für Kunden von Providern, die kein 777 zulassen. Provider wechseln, denn zumindest ich genieße die Bequemlichkeit via FTP und HTTP auf Daten und Ordner frei zugreifen zu können. Welche Skripte aber in nicht durch htaccess geschützte Ordner kommen, sollte man dann doch ein wenig sorgsamer sein, bzw. selbst auf ein Monitoring des eigenen Webspaces zu achten, so dass man weiß, ob und wann sich Ungewöhnliches ereignet und ob das vielleicht an einem unsicheren Skript an falscher Stelle liegen könnte.