Was passiert mit alten CMS/Blog-Websites?

Lesezeit: 5 Minuten

Ich habe ein paar wenige Seiten lange Websites für einmalige Projekte oder Konferenzen hauptsächlich in WordPress erstellt, und ich denke darüber nach, was mit diesen Websites in Zukunft passieren wird. Und ich denke, ich bin nicht allein, da es eine große Anzahl von Websites gibt, die jetzt nur noch als Archiv aufbewahrt werden, aber anders als in den 90er Jahren, als alles statisches HTML war, verwenden diese Websites jetzt eine Software, um CMS bereitzustellen Funktionalität, auch wenn es nur für ein paar Seiten + Suche ist.

Mein Problem ist, dass Sie bei all dieser modularen Software (WordPress, Joomla usw.) verschiedene Plugins und Themen verwenden müssen, um sie nutzbar und schön zu machen, aber all diese Funktionen brechen früher oder später. Das heißt, wenn Sie die Website unverändert lassen möchten, müssen Sie die alten Versionen der Software verlassen. Ich meine für immer.

Andererseits sind sie so beliebt (WordPress hat jetzt mehr als 100 Millionen Downloads), dass ich überrascht wäre, wenn sie nicht in naher Zukunft ein Ziel für die beliebtesten Exploits werden würden. Ich weiß nicht, wie sicher diese Software ist, aber ich habe erlebt, was es bedeutet, eine osCommerce-Website mit etwa 7 erfolgreichen Hackerangriffen jeden Monat kontinuierlich zu bereinigen / zu reparieren, bis der Eigentümer der Website zustimmt, dass es besser ist, die Website vollständig zu schließen und zu starten einen neuen bauen.

Gibt es als alternative Lösung (aber ich weiß wirklich nicht, ob es möglich ist) eine Möglichkeit, eine ganze Site in einen schreibgeschützten Modus zu versetzen? Ich meine so etwas wie die Datenbank schreibgeschützt zu machen, das Dateisystem schreibgeschützt zu machen, die Admin-Oberfläche und alle Kommentarfelder zu deaktivieren und die Seite einfach als Archiv zu belassen, wobei der einzige dynamische Teil die Suchfunktion ist.

Ist es auf Dateisystem-/Datenbankebene möglich? Hilft es überhaupt, Hacker fernzuhalten? Gibt es eine andere Lösung? Bitte verstehen Sie, dass mein Punkt das ist Es ist nicht möglich, CMS-Sites immer auf dem neuesten Stand zu halten, und selbst wenn einige von ihnen fanatisch genug sind, eine Nacht damit zu verbringen, ein kaputtes Theme/Plugin zu reparieren, das gerade nach einem Core-Upgrade kaputt gegangen ist, werden 99 % der Websites in einem “behobenen” Zustand enden; für immer eine funktionierende, aber alte CMS/Plugins/Theme-Kombination verwenden.

  • wget -r http://example.com && ftp ftp.example.com

    – cthom06

    11. März 2011 um 20:58 Uhr


  • @cthom06: Verwenden Sie immer noch FTP? Ach.

    – Lekenstein

    11. März 2011 um 21:06 Uhr

Ich denke, 99 % sind eine sehr großzügige Schätzung, aber das ist nebensächlich. Die Mehrheit der Websites, die in dem Zustand landen, auf den Sie sich beziehen, bestehen nur so lange wie ihre Domänenregistrierungen (zumal die meisten WordPress- oder OSCommerce-Bereitstellungen normalerweise als Stammdomäne eingerichtet sind und die gesamte Webpräsenz bedienen.) Also Wenn die Domain selbst vernachlässigt und aufgegeben wird, wird sie im Allgemeinen durch den natürlichen Ablaufprozess außer Betrieb genommen und ist nicht mehr allgemein zugänglich.

Was das Sperren eines gesamten Site-weiten Zustands auf einem dieser CMS-Systeme angeht, könnte es theoretisch möglich sein, alle Schreibrechte für alle Serverdateien zu entfernen und alle Datenbankbenutzerrechte außer SELECT zu widerrufen. In den meisten Fällen würde dies den Zweck zunichte machen, die Software für CMS überhaupt dort zu belassen, da keiner der Datensätze mehr aktualisierbar wäre (Items im Fall von OSCommerce, Posts im Fall von WordPress). Dies wäre jedoch stark abhängig von die Umgebung, die vom jeweiligen CMS benötigt wird, und WordPress ist ziemlich wählerisch in Bezug auf Lese-/Schreibberechtigungen, um überhaupt zu funktionieren. Es wäre ein interessantes Experiment, aber wahrscheinlich keine praktische Lösung für das, was Sie beschreiben.

Das Nehmen des gerenderten Inhalts und das Erstellen eines statischen Spiegels ist eine weitere Option und kann ziemlich einfach automatisiert werden, indem ein Skript geschrieben wird, das den HTML-Inhalt der gerenderten Seiten abrufen und statische, verknüpfte Alternativen erstellen kann. Aber auch dies ist etwas unpraktisch, insbesondere im Fall einer Suche (da diese per Definition einen Datenbankzugriff erfordert).

Kurz gesagt, es ist eine interessante Idee, aber letztendlich sind Websites, die vernachlässigt werden und deren Eigentümer sich nicht dazu verpflichten, ordnungsgemäße Updates aufrechtzuerhalten, dem Verfall geweiht, und der natürliche Verlauf des Internetgeschäfts und die Registrierung von Domänen werden sie ziemlich oft darwinisieren.

  • Die datenbankbasierte Suche funktioniert nicht, aber Sie können sie jederzeit durch a ersetzen Benutzerdefinierte Google-Suche auf den statischen Seiten.

    – Steven T. Snyder

    13. Januar 2012 um 0:53 Uhr

Ja, Sie können einen Snapshot einer Website mit erstellen wget oder ähnliches, wobei die CMS-gesteuerte Website im Grunde durch statische HTML-Seiten ersetzt wird.

wget -mk http://www.example.com/

Auf diese Weise müssten Sie es nicht für immer aktualisieren.

  • K – +1 Dies ist praktisch, um alle gerenderten Inhalte vom Server herunterzuladen, aber das OP fragt insbesondere, wie einige der dynamischen Funktionen in ihrem aktuellen Zustand gehalten werden können, dh eine Artikelsuche – dies wäre mit einer Sammlung nicht möglich von statischen Seiten. Obwohl ich denke, dass es wahrscheinlich die beste Idee für Websites ist, die für die meisten dieser einfachen CMSes nur den gerenderten Inhalt zu erfassen und den dynamischen Inhalt einfach fallen zu lassen, wie Sie vorgeschlagen haben.

    – DiakonDesperado

    11. März 2011 um 21:16 Uhr


Gibt es als alternative Lösung (aber ich weiß wirklich nicht, ob es möglich ist) eine Möglichkeit, eine ganze Site in einen schreibgeschützten Modus zu versetzen? Ich meine so etwas wie die Datenbank schreibgeschützt zu machen, das Dateisystem schreibgeschützt zu machen, die Admin-Oberfläche und alle Kommentarfelder zu deaktivieren und die Seite einfach als Archiv zu belassen, wobei der einzige dynamische Teil die Suchfunktion ist.

WP Super Cache hat eine „Lockdown“-Funktion, die statische HTML-Dateien für fast jeden Besucher bereitstellt. Es ist nicht genau das, wonach Sie suchen, aber eine einfache Problemumgehung, da ich keine “Nur-Lesen”-Funktion für WordPress kenne.

http://wordpress.org/extend/plugins/wp-super-cache/

1393320cookie-checkWas passiert mit alten CMS/Blog-Websites?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy