¿Qué sucede con los sitios web antiguos de CMS/blog?

6 minutos de lectura

He creado un par de sitios web de pocas páginas para proyectos únicos o conferencias en su mayoría en WordPress, y estoy pensando en lo que sucederá con esos sitios web en el futuro. Y creo que no estoy solo, ya que hay una gran cantidad de sitios que ahora solo se guardan como un archivo, pero a diferencia de los años 90, donde todo era HTML estático, estos sitios web ahora usan algún software para proporcionar CMS. funcionalidad, incluso si es solo para unas pocas páginas + búsqueda.

Mi problema es que con todo este software modular (WordPress, Joomla, etc.) necesitas usar varios complementos y temas para hacerlos utilizables y agradables, pero todas estas funciones se frenan tarde o temprano. Lo que significa que si desea mantener el sitio web como está, debe dejar las versiones anteriores del software. Quiero decir para siempre.

Por otro lado, son tan populares (WordPress tiene más de 100 millones de descargas ahora), que me sorprendería si no se convirtieran en un objetivo para los exploits más populares en un futuro cercano. No sé cuán seguros son estos programas, pero he experimentado lo que significa limpiar/arreglar continuamente un sitio web de osCommerce con alrededor de 7 ataques exitosos de piratas informáticos cada mes, hasta que el propietario del sitio acordó que es mejor cerrar el sitio por completo y comenzar. construyendo uno nuevo.

Como solución alternativa (pero realmente no sé si es posible), ¿hay alguna forma de convertir un sitio completo en modo de solo lectura? Me refiero a algo como hacer que la base de datos sea de solo lectura, el sistema de archivos solo de lectura, deshabilitar la interfaz de administración y todos los campos de comentarios y simplemente dejar el sitio como un archivo, siendo la única parte dinámica la función de búsqueda.

¿Es posible a nivel de sistema de archivos/base de datos? ¿Ayudará en absoluto a mantener alejados a los piratas informáticos? hay alguna otra solucion? Por favor, comprenda que mi punto es que no es posible mantener los sitios CMS siempre actualizados para siempre, e incluso si algunos de ellos son lo suficientemente fanáticos como para pasar una noche buscando arreglar un tema/complemento roto que acaba de fallar después de una actualización central, el 99% de los sitios terminarán en un estado “arreglado”; usando una combinación de CMS/complementos/tema en funcionamiento pero antigua para siempre.

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

    – cthom06

    11 de marzo de 2011 a las 20:58


  • @cthom06: ¿Sigue usando FTP? Oh

    – Lekenstein

    11 de marzo de 2011 a las 21:06

Creo que el 99% es una estimación muy generosa, pero eso no viene al caso. La mayoría de los sitios que terminan en el estado al que te refieres solo duran mientras sus registros de dominio (especialmente porque la mayoría de las implementaciones de WordPress u OSCommerce generalmente se configuran como el dominio raíz y dan servicio a la totalidad de la presencia web). Entonces en términos generales, si el propio dominio se encuentra en estado de abandono y descuido, el proceso de caducidad natural lo desmantelará y ya no será accesible en general.

En cuanto a bloquear un estado completo en todo el sitio en uno de estos sistemas CMS, en teoría podría ser posible si uno eliminara todos los privilegios de escritura para todos los archivos del servidor y revocara todos los privilegios de usuario de la base de datos excepto SELECT. En la mayoría de los casos, esto frustraría el propósito de dejar el software para CMS allí, ya que ninguno de los registros sería actualizable (elementos en el caso de OSCommerce, publicaciones en el caso de WordPress). Pero esto dependería en gran medida de el entorno requerido por el CMS en particular, y WordPress para uno es bastante particular acerca de los permisos de lectura/escritura para trabajar en absoluto. Sería un experimento interesante, pero probablemente no sea una solución práctica para lo que estás describiendo.

Tomar el contenido renderizado y crear un espejo estático es otra opción, y se puede automatizar bastante fácilmente escribiendo un script que pueda obtener el contenido HTML de las páginas renderizadas y creando alternativas estáticas y vinculadas. Pero esto también es un poco impráctico, especialmente en el caso de una búsqueda (ya que esto, por su propia definición, requiere acceso a la base de datos).

En resumen, es una idea interesante, pero en última instancia, los sitios que se descuidan y cuyos propietarios no se comprometen a mantener las actualizaciones adecuadas están condenados a caducar, y el curso natural de los negocios en Internet y el registro de dominios a menudo los darwiniza.

  • La búsqueda basada en bases de datos no funcionará, pero siempre puede reemplazarla con una Búsqueda personalizada de Google en las páginas estáticas.

    –Steven T. Snyder

    13 de enero de 2012 a las 0:53

Sí, puede tomar una instantánea de un sitio web usando wget o similar, básicamente reemplazando el sitio controlado por CMS con páginas HTML estáticas.

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

De esa manera no necesitarías actualizarlo para siempre.

  • K – +1 Esto es práctico para bajar todo el contenido renderizado del servidor, pero el OP pregunta particularmente cómo mantener algunas de las funciones dinámicas en su estado actual, es decir, una búsqueda de elementos; esto no sería posible con una colección. de páginas estáticas. Aunque creo que simplemente capturar el contenido renderizado para la mayoría de estos CMS simples y simplemente deshacerse del contenido dinámico como usted sugirió es probablemente la mejor idea para los sitios programados para el abandono.

    – Diácono Desperado

    11 de marzo de 2011 a las 21:16


Como solución alternativa (pero realmente no sé si es posible), ¿hay alguna forma de convertir un sitio completo en modo de solo lectura? Me refiero a algo como hacer que la base de datos sea de solo lectura, el sistema de archivos solo de lectura, deshabilitar la interfaz de administración y todos los campos de comentarios y simplemente dejar el sitio como un archivo, siendo la única parte dinámica la función de búsqueda.

WP Super Cache tiene una función de “Bloqueo”: sirve archivos HTML estáticos para casi todos los visitantes. No es exactamente lo que está buscando, sino una solución simple, ya que no conozco una función de “solo lectura” para WordPress.

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

¿Ha sido útil esta solución?