source - php cms

¿Cómo auto-actualizar PHP+MySQL CMS? (6)

Basado en la experiencia con varias aplicaciones, CMS y de otra manera, este es un patrón común:

Las actualizaciones son generalmente unidireccionales. Es posible tomar una instantánea del estado completo del sistema para una restauración en caso de fallo, pero la restauración generalmente implica la pérdida de cualquier dato / contenido / registro agregado al sistema desde la actualización. Realizar una reversión incremental puede poner los datos en riesgo si algo no se convirtió correctamente (por ejemplo, cambios en la tabla de la base de datos, conversiones de contenido, restricciones de clave externa, creación de índices, etc.) Esto es especialmente cierto si ha realizado personalizaciones que los scripts de reversión no pudieron posiblemente cuenta para
Los archivos de actualización se empaquetan con algunos medios de autenticación / verificación, como los hashes md5 o sha1 y / o la firma digital para garantizar que provengan de una fuente confiable y no hayan sido manipulados. Esto es particularmente importante para los procesos de actualización automatizados. Supongamos que un pirata informático explotó una vulnerabilidad y le dijo que actualizar desde una fuente maliciosa.
La aplicación debe estar en modo fuera de línea durante la actualización.
La aplicación debe realizar una autocomprobación después de una actualización.

Estoy escribiendo un CMS en PHP + MySQL. Quiero que sea auto-actualizable (lanzar un clic en el panel de administración). ¿Cuáles son las mejores prácticas?
Cómo comparar la versión actual de cms y una versión de la actualización (aplicación en sí y base de datos). ¿Debería simplemente descargar el archivo zip, subirlo y sobrescribirlo? (pero qué hacer con los archivos que ya no se utilizan). ¿Cómo comprobar si una actualización se ha descargado correctamente? También admite módulos y quiero que estos módulos se puedan descargar desde el panel de administración de cms.
¿Y cómo debo actualizar las tablas de MySQL?

Estoy de acuerdo con la respuesta de Bart van Heukelom , es la forma más habitual de hacerlo.

La única otra opción sería convertir su CMS en un conjunto de servicios web / scripts remotos y archivos CSS / JS externos que usted hospeda solo en una ubicación.

Entonces, todos los que usen su CMS se conectarán a su "servidor CMS" central y todo lo que habrá en su servidor (de llamadas) es un conjunto de scripts para llamar a sus Servicios web / scripts que realizan todo el procesamiento y la salida. Si optó por esta ruta, deberá identificar / autenticar cada solicitud para que devuelva los datos correspondientes para el usuario de CMS.

Hay una biblioteca de SQL llamada SQLOO (que creé) que intenta resolver este problema. Todavía es un poco difícil, pero la idea básica es que configura el esquema SQL en código PHP y luego SQLOO cambia el esquema de base de datos actual para que coincida con el código. Esto permite que el esquema SQL y el código PHP adjunto se cambien juntos y en porciones mucho más pequeñas.

http://code.google.com/p/sqloo/

http://code.google.com/p/sqloo/source/browse/#svn/trunk/example <- ejemplos

Tienes dos escenarios para tratar:

El servidor web puede escribir en archivos.
El servidor web no puede escribir en archivos.

Esto solo determina si va a descomprimir un archivo ZIP o usar FTP para actualizar los archivos. En el caso de ether, su primer paso es hacer un volcado de la base de datos y una copia de seguridad de los archivos existentes, de modo que el usuario pueda revertir si algo sale terriblemente mal. Como han dicho otros, es importante mantener cualquier cosa que el usuario pueda personalizar fuera del alcance de la actualización. Wordpress hace esto muy bien. Si un usuario ha realizado cambios en el código lógico central, es probable que sea lo suficientemente inteligente como para resolver los conflictos de combinación por su cuenta (y lo suficientemente inteligente como para saber que una actualización de un clic probablemente perderá sus modificaciones).

El segundo paso es asegurarse de que su secuencia de comandos no muera si se cierra el navegador. Este es un proceso que realmente no debe ser interrumpido. Puede lograr esto a través de ignore_user_abort(true); , o algún otro medio. O, si lo desea, permita que el usuario marque una casilla que diga "Continuar aunque me desconecten". Supongo que usted manejará los errores internamente.

Ahora, dependiendo de los permisos, puede:

Comprime los archivos que se actualizarán en el directorio system / tmp
Comprima los archivos que se actualizarán a un archivo temporal en el directorio de inicio

Entonces estás listo para:

Descargue y descomprima la actualización en situ , o en su lugar.
Descargue y descomprima la actualización al directorio / tmp del sistema y use FTP para actualizar los archivos en la raíz web

Usted puede entonces:

Aplicar los cambios de SQL según sea necesario
Preguntar al usuario si todo salió bien.
Retroceder si las cosas salieron mal
Limpie su directorio temporal en el directorio de sistema / tmp, o cualquier archivo provisional en el directorio raíz / inicio del usuario.

El aspecto más importante es asegurarse de que pueda revertir los cambios si las cosas salieron mal. La otra cosa para asegurar es que si usa / tmp, asegúrese de verificar los permisos de su área de preparación. 0600 debe hacer muy bien.

Echa un vistazo a cómo Wordpress y otros lo hacen. Si su elección de licencias y las suyas están de acuerdo, es posible que incluso pueda reutilizar parte de ese código.

Buena suerte con tu proyecto.

Una solución ligeramente más experimental podría ser utilizar algo como la biblioteca phpsvnclient .

Con características:

Listar todos los archivos en un directorio de repositorio SVN dado
Recuperar una revisión dada de un archivo
Recupere el registro de los cambios realizados en un repositorio o en un archivo dado entre dos revisiones
Obtener la última revisión del repositorio

De esta manera puede ver si hay archivos nuevos, archivos eliminados o archivos actualizados y solo cambiarlos en su aplicación local.

Reconozco que esto será un poco más difícil de implementar, pero el beneficio probablemente sería que es más fácil y rápido agregar actualizaciones a su CMS.

Mantenga su código en una ubicación separada de la configuración y, por lo demás, de los archivos variables (imágenes cargadas, archivos de caché, etc.)
Mantenga los módulos separados del código principal también.
Asegúrese de que su código tenga permisos del sistema de archivos para cambiarse a sí mismo (por ejemplo, use SuPHP).

Si haces esto, lo más simple sería descargar completamente la nueva versión (sin parches incrementales) y descomprimirla en un directorio adyacente al que contiene la versión actual. Debido a que no habrá archivos variables dentro del directorio de código, solo puede eliminar o cambiar el nombre del antiguo y cambiar el nombre del nuevo para reemplazarlo.

Puede mantener el número de versión en una constante global en el código.

En cuanto a MySQL, no hay otra manera que hacer un script de actualización para cada versión que cambie el diseño de la base de datos. Incluso las soluciones automáticas para cambiar la definición de la tabla no pueden saber cómo actualizar los datos existentes.