¿Cómo actualizar automáticamente PHP + MySQL CMS?

Question

Estoy escribiendo un CMS en PHP + MySQL. Quiero que sea auto-actualizable (tiro 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 propia y base de datos). ¿Debería simplemente descargar un archivo zip, subirlo y sobrescribirlo? (pero qué hacer con los archivos que ya no se usan). ¿Cómo verificar si una actualización se descargó 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?

Answer 1

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

con las características:

• una lista de todos los archivos en un directorio del repositorio SVN dado
• recuperar una revisión dada de un archivo
• recuperar el registro de los cambios realizados en un depósito o en un archivo dado entre dos revisiones
• Obtener el repositorio última revisión

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

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

Answer 2

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

Si hace 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ódigos, puede simplemente eliminar o renombrar el antiguo y cambiarle el nombre al 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.

Answer 3

Estoy de acuerdo con Bart van Heukelom 's respuesta, 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 aloja en una sola ubicación.

Entonces todos los que usan su CMS se conectarían a su "servidor CMS" central y todo lo que encontraría en su servidor sería un conjunto de scripts para llamar a sus servicios web/scripts que procesan y publican todo. Si realizara esta ruta, necesitaría identificar/autenticar cada solicitud para que devuelva los datos correspondientes para el usuario de CMS dado.

Answer 4

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

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

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

Answer 5

Se tienen dos escenarios para hacer frente a:

1. El servidor web puede escribir en archivos.
2. El servidor web no puede escribir en los archivos.

Esto simplemente indica si va a descomprimir un archivo ZIP o usar FTP para actualizar los archivos. En el caso de ether, su primer paso es realizar un volcado de la base de datos y una copia de seguridad de los archivos existentes, para que el usuario pueda retroceder si algo sale mal. Como han dicho otros, es importante mantener todo lo que el usuario probablemente personalizará fuera del alcance de la actualización. Wordpress hace esto muy bien. Si un usuario ha realizado cambios en el código de la lógica central, es probable que sea lo suficientemente inteligente como para resolver cualquier conflicto de fusió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 el script no se muere si el navegador está cerrado. Este es un proceso que realmente no debe ser interrumpido. Puede hacerlo a través del ignore_user_abort(true);, o de algún otro modo. O, si lo desea, permita que el usuario marque una casilla que dice "Continuar aunque me desconecten". Supongo que manejarás los errores internamente.

Ahora, dependiendo de los permisos, puede:

• comprimir los archivos que se actualizan en el directorio del sistema/tmp
• comprimir los archivos que se actualizará en un archivo temporal en el directorio principal

entonces usted está listo para:

• Descargar y descomprimir la actualización en situ, o en su lugar.
• Descargar y descomprimir la actualización al directorio del sistema/tmp y utilizar FTP para actualizar los archivos en la raíz de la tela

continuación, puede:

• aplicar los cambios de SQL según sea necesario
• Pregúntele al usuario si todo salió bien
• Desplácese hacia atrás si las cosas salieron mal
• Limpie su directorio temporal en el directorio system/tmp, o cualquier archivo f es en el directorio raíz/inicio web del usuario.

Lo más importante es asegurarse de que puede deshacer los cambios si las cosas van mal. La otra cosa para garantizar es que si usa/tmp, asegúrese de verificar los permisos de su área de ensayo. 0600 debería funcionar bien.

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

Buena suerte con su proyecto.

Answer 6

Con base en la experiencia con una serie de aplicaciones, CMS y de lo contrario, este es un patrón común:

• Las actualizaciones son generalmente de un solo sentido. Es posible tomar una instantánea del estado del sistema completo para una restauración en caso de falla, pero restaurar generalmente implica la pérdida de datos/contenidos/registros agregados al sistema desde la actualización. Realizar una reversión incremental puede poner en riesgo los datos si algo no se convirtió correctamente (por ejemplo, cambios en la tabla de 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 podrían posiblemente tenga en cuenta.
• Los archivos de actualización se empaquetan con algunos medios de autenticación/verificación, como hashes md5 o sha1 y/o firma digital para garantizar que provienen de una fuente confiable y que no fueron alterados. Esto es particularmente importante para los procesos de actualización automatizados. Supongamos que un hacker explota una vulnerabilidad y le dice que actualice desde una fuente no autorizada.
• La aplicación debe estar en modo fuera de línea durante la actualización.
• La aplicación debe realizar una autoverificación después de una actualización.