Pues como todo Software Libre utilizan Subversión como herramienta de desarrollo y permite a sus desarrolladores tener acceso inmediato a los cambios más recientes en el código. Pero lo interesante es que aún si no estás involucrado en el desarrollo de WordPress puedes sacar provecho de este:

Actualizaciones mucho más sencillas

Tanto la instalación como la actualización usando el repositorio Subversion de WordPress son bastante sencillos, solo necesitas:

  • Tener acceso SSH hacia el servidor donde vas usar WordPress
  • Y que este tenga instalado un cliente Subversion

Puedes usar cualquier versión publicada por Automattic, todo es de buscarla en:

http://core.svn.wordpress.org/tags/

Instalación desde cero

El proceso de instalación y actualización está detallado en el Codex de WordPress, acá solo los mencionaré brevemente. Por ejemplo para iniciar una instalación de cero usamos el comando checkout (abreviado co):

$ mkdir public_html
$ cd public_html
$ svn co http://core.svn.wordpress.org/tags/3.0.2 .

Con esto tendrás el código de la versión 3.0.2 dentro de public_html, que es equivalente a descargar el .zip de dicha versión y extraerlo en este folder, pero con Subversion queda automáticamente “amarrado” al repositorio (ya veremos como cambiar de versión).

Migrar desde una instalación ya existente

Si ya tenemos un sitio funcionando con WordPress y queremos que esté ligado el repositorio, el proceso es un poco más laborioso pero solo se hace una vez:

  1. Creamos un directorio temporal para la copia de WordPress en el repositorio: 
    $ mkdir tempwp
$ cd tempwp
$ svn co http://core.svn.wordpress.org/tags/3.0.2 .
  2. Ahora copiamos la configuración del blog hacia la nueva instancia en tempwp: 
    $ cd ../public_html
$ cp -p wp-config.php .htaccess ../tempwp

    Asumiento que nuestra instalación activa se encuentra en public_html

  3. Ahora movemos lo del wp-content hacia tempwp 
    $ cp -rfp wp-content/* ../tempwp/wp-content

    Esto posiblemente cree conflictos con algunos archivos del wp-content que están dentro del repositorio. Para eso ejecutamos:

    $ cd ../tempwp
$ svn status
?      wp-config.php
?      .htaccess
?      wp-content/upgrade
?      wp-content/uploads
?      wp-content/plugins/hacks.php
?      wp-content/plugins/dashboard-widget-manager
?      wp-content/plugins/privatewp
X      wp-content/plugins/akismet
?      wp-content/plugins/openid
?      wp-content/themes/p2
?      wp-content/themes/prologue

    Normalmente todo debería salir con un símbolo de ? (que no está en el repositorio) o X de akismet. Si hay algo con M (tiene modificaciones) lo mejor es revertir cualquier diferencia que tenga. Por ejemplo si tuviéramos una versión anterior de akismet a la del repositorio, lo revertimos ejecutando:

    $ svn revert wp-content/plugins/akismet/akismet.php

    Y así para el resto de archivos marcados como modificados.

  4. Si tienes algún otro archivo fuera del wp-content también hay que copiarlo.
  5. Con esto ya solo quedaría renombrar los directorios para usar la que nos interesa: 
    $ mv public_html old_html
$ mv tempwp public_html

    Si por alguna razón no funciona, siempre tienes una copia en old_html (o según corresponda en tu caso) a la cual puedes regresar rápidamente.

Actualizar la instalación

Una vez ya tengas una instalación ligada al repositorio, podemos cambiar la versión de nuestro WordPress usando el comando switch (abreviado sw). Por ejemplo para pasar de 3.0.1 al recién salido 3.0.2:

$ svn sw http://core.svn.wordpress.org/tags/3.0.2/
U    wp-includes/ms-files.php
U    wp-includes/version.php
U    wp-includes/comment.php
U    wp-includes/functions.php
U    wp-includes/load.php
U    wp-includes/canonical.php
U    wp-includes/capabilities.php
U    readme.html
U    wp-admin/includes/plugin.php
U    wp-admin/includes/file.php
U    wp-admin/includes/update-core.php
U    wp-admin/plugins.php
Updated to revision 16644.

¿Fácil no? Esto también significa que podemos regresar a una versión anterior, siempre y cuando la base de datos lo permita; todo es de buscar en los tags del repositorio las versiones correspondientes. Para los temerarios, también pueden pasarse directamente al /trunk, la rama principal de desarrollo donde no es raro que las cosas dejen de funcionar.

Detectando Malware

El hecho que podamos ver que archivos tienen modificaciones respecto al repositorio o cuales no están en este, nos ayuda mucho a detectar malware que por algún plugin defectuoso logró infectar nuestro WordPress. Para esto usamos nuevamente svn status:


$ svn status
?      wp-config.php
?      redir.php
?      .htaccess
?      sitemap.xml.gz
?      geositemap.xml
?      imgs
?      wp-includes/malware.php
M      wp-includes/general-template.php
M      index.php
?      wp-content/cache
?      wp-content/languages
?      wp-content/plugins/hacks.php
?      wp-content/plugins/wp-super-cache
?      wp-content/plugins/wp-postviews
X      wp-content/plugins/akismet
?      wp-content/plugins/google-sitemap-generator
?      wp-content/plugins/postie
?      wp-content/themes/log
?      wp-content/themes/sandbox

En este ejemplo no hay razón para que el index.php y wp-includes/general-template.php tengan modificaciones (marcados con M), o para que exista un archivo como wp-includes/malware.php y que no esté en el repositorio (marcado con ? dentro de wp-includes). Sino hemos hecho modificaciones por nuestra cuenta a dichos archivos, lo mejor es revertir cualquier cambio:

$ svn revert index.php wp-includes/general-template.php
Reverted 'index.php'
Reverted 'wp-includes/general-template.php'

Y eliminar cualquier otro archivo que nosotros no hayamos puesto demás. Sin el repositorio hubiera sido complicado encontrar dichas modificaciones, incluso sería más sencillo sobreescribir todos los archivos del core de WordPress.

Si el malware está en el wp-content va ser un poco más complicado, porque es natural que esos archivos no estén en el repositorio, toca actualizar todos los plugins y themes o incluso ir desactivando los que parezcan sospechosos. No hay una formula mágica para esos casos.