Actualización de una instalación multisitio a WordPress 3.0: ¡cuidado con los temas!

Como ya he ido señalando en mis intervenciones recientes en Twitter, durante estos primeros días de agosto estoy actualizando la plataforma Multiblog del PNTE a la versión 3.0 de WordPress. El núcleo de este proceso, es decir, la actualización de los archivos de la aplicación, no presenta serios inconvenientes si se siguen las recomendaciones habituales (esto es, realizar copias de seguridad de la base de datos y los archivos de la aplicación y de los usuarios, que en el caso de una instalación multisitio pueden suponer un espacio de almacenamiento considerable), y si se presta un especial cuidado a los cambios de configuración de los ficheros wp-config.php y .htaccess. Sobre este último asunto existen varios tutoriales un tanto imprecisos, y por ello recomiendo el titulado Upgrading WordPress MU 2.9.2 to WordPress 3.0, pues tanto en el texto del artículo como en las preguntas y respuestas de los comentaristas se halla la solución a la mayoría de conflictos que pueden aparecer en el proceso de actualización.

Por supuesto, al actualizar una plataforma de blogs a WordPress 3.0 es necesario actualizar también muchos plugins, para evitar incompatibilidades que puedan afectan a la funcionalidad de la aplicación. Esto no debiera constituir un problema con las extensiones “normales” (las instaladas en el directorio /wp-content/plugins), porque el sistema va avisando al administrador de las actualizaciones en el momento en que éstas se producen, y lo lógico es llegar al cambio de versión de la aplicación con la mayoría de las extensiones actualizadas. Sin embargo, tal circunstancia no se produce con las extensiones instaladas en el directorio /wp-content/mu-plugins, a no ser que sean compatibles con el plugin Update Notification, que está incluido en todas las extensiones del servicio de pago WPMU DEV Premium.

Así que el sufrido administrador de la plataforma tiene que hacer un esfuerzo especial por actualizar todas las extensiones de /mu-plugins, la mayoría de las cuales no están en el repositorio oficial de WordPress, bien porque son de pago (caso de las que publica WPMU DEV), bien porque están muy pobremente documentadas, o bien porque ya están “descatalogadas” y no hay manera de actualizarlas, a no ser sustituyéndolas por otras extensiones que hagan funciones parecidas. Todos estos problemas los he padecido en primera persona, y he sabido solventarlos de forma más o menos eficaz, y en algunos casos hasta elegante.

Más dificultosa será la actualización de los casi sesenta temas que en este momento tienen a su disposición los usuarios de la plataforma Multiblog. En rigor, esta es una tarea imposible, porque un buen puñado de los temas instalados ya no tienen continuidad. Sin embargo, los creadores de otros muchos los han ido actualizando para incorporar las nuevas funcionalidades de WordPress 3.0 (menús nativos, nueva estructura de plantillas, cabeceras y fondos personalizados, posibilidad de integrar los contenidos procedentes de taxonomías y tipos de contenido personalizados, etc.), y con tal motivo se impone una revisión a fondo de todos los temas instalados en la plataforma. En rigor, esta no es una tarea urgente, pues aunque los temas no sean del todo compatibles con las novedades de la última versión de WordPress no por ello pierden su funcionalidad.

Lo que en ningún caso debe hacerse sin las debidas precauciones, a pesar de las indicaciones de algunos tutoriales, es borrar los viejos temas que venían por defecto en versiones anteriores de WordPress (es decir, Default y Classic), porque en la plataforma Multiblog (y supongo que lo mismo ocurrirá en otras instalaciones) hay muchos blogs que tienen como tema activo el que hasta ahora utilizaba WordPress por defecto. Teóricamente, una vez actualizada la aplicación a la versión 3.0, dichos blogs deberían haber adoptado por defecto el tema TwentyTen, pero eso no ha ocurrido en nuestro caso, razón por la cual, tras borrar los temas antedicho, cuarenta y tantos blogs se han quedado en blanco (ojalá hubiera leído antes el artículo Change the default theme for sites without a plugin, pero cuando tuve noticia de él ya era tarde).

Cierto es que el problema tenía una importancia menor, pues la mayor parte de los blogs afectados sólo tenían una entrada, y que la solución era tan fácil como la de copiar de nuevo en el servidor los dos temas borrados, pero he preferido optar por una alternativa más sólida y con mayor proyección de futuro, de la que alguna vez ya he tratado en La Bitácora del Tigre: editar minuciosamente en cada blog las opciones template, stylesheet y current_theme (lo cual puede hacerse desde el backend de administración de la plataforma o mediante la oportuna consulta ejecutada directamente sobre MySQL), y sustituirlas por el valor apropiado para cada una de ellas: “twentyten” para las dos primeras y “Twenty Ten” para la tercera. Un incordio bastante fastidioso, la verdad.

Otro problema mucho más difícil de resolver es el que me encontré ayer por la mañana, cuando me di cuenta, al actualizar el tema Tarski, que el usuario administrador de un blog que utilizo para pruebas (no confundir con el super administrador de la plataforma de blogs, propio de las instalaciones multisitio, que no se ve afectado) no podía acceder a la página de opciones de dicho tema. Al principio, pensé que era un problema de la nueva versión de Tarski, pero en seguida me di cuenta de que afectaba a varios temas con páginas de opciones, independientemente de su versión, y a todos los blogs que hacían uso de este tipo de plantillas.

Como el problema era bastante serio, me enfrasqué en encontrar una solución, y después de un par de horas de búsquedas poco fructíferas y de algunas hipótesis infundadas sobre colisiones con plugins y otros conflictos semejantes –véase, como ilustración de mis indagaciones, el hilo que abrí en los foros de soporte de WPMU DEV- di con la solución en varias intervenciones de los foros de WordPress, que cito a continuación en orden vagamente cronológico:

• Capability manage_options vs edit_themes.
• Multi-user set up – users can’t customize themes.
• WP 3.0 MS – User’s can’t See Theme Options Pages.
• WP 3.0 multisite + Constructor.
• Atahualpa WPMU Problems.
• My users can’t see settings of some theme.
• Theme option menu access.

Por lo que yo he podido entender de todo este maremágnum de preguntas y respuestas (véase también el artículo Did your user’s theme options and widgets page disappear?), en las instalaciones multisitio de WordPress 3.0, la capacidad ‘edit_themes’, que en versiones anteriores de la aplicación estaba a disposición de los administradores de blogs individuales, se ha circunscrito o limitado al usuario super administrador del multisitio. Esto provoca que los administradores de blogs individuales no pueden acceder a la página de opciones de aquellos temas cuya configuración se activa invocando dicha capacidad, con los perjuicios consiguientes.

La solución consiste en localizar en cada tema el código que activa la página de opciones, y modificarlo, eliminando la capacidad ‘edit_themes’  y sustituyéndola por otra de la que dispongan los administradores de blogs individuales. En las intervenciones que acabo de citar se proponen varias diferentes: ‘switch_themes’, ‘manage_options’ y ‘edit_theme_options’. Después de un análisis detallado de los casos que se relatan en los foros y de la lectura de los artículos Roles and Capabilities y Adding Administration Menus del Codex de WordPress, creo que la opción más adecuada es la última, aunque, como se verá más adelante, yo he optado por la segunda en los temas que he ido modificando durante estos dos últimos días, porque hasta la tarde de hoy no he dispuesto de toda la información que ahora ofrezco a mis lectores.

Hasta aquí la teoría, aunque en la práctica la situación es todavía más complicada, pues si bien la gran mayoría de temas actuales que disponen de páginas de opciones contienen un código con una estructura semejante a ésta:

<?php add_theme_page( $page_title, $menu_title, $capability, $menu_slug, $function); ?>

sin embargo, no todos activan la página de opciones desde el mismo archivo y de la misma forma. Esta circunstancia hace que la actualización de los temas en una plataforma como Multiblog (muchos de ellos bastante modificados, además), se convierte en una tarea muy fatigosa. A guisa de ilustración de la variedad con la que me ido encontrando, ofrezco a continuación cuatro casos, todos ellos diferentes, correspondientes a otros tantos temas de nuestra plataforma de blogs.

1. Tema Arjuna X, versión 1.3.9. En el archivo functions.php, línea 352, donde originalmente dice:

add_theme_page(__('Arjuna Options', 'Arjuna'), __('Arjuna Options', 'Arjuna'), 'edit_themes', basename(__FILE__), 'arjuna_add_theme_page');

debe decir:

add_theme_page(__('Arjuna Options', 'Arjuna'), __('Arjuna Options', 'Arjuna'), 'manage_options', basename(__FILE__), 'arjuna_add_theme_page');

A tenor de mis comprobaciones, el recurso al archivo functions.php es la situación más habitual entre los temas que activan su página de opciones mediante la llamada a “add_theme_page”.

2. Tema Mystique, versión 2.4.2. En el archivo /admin/theme-settings.php, líneas 865-872, donde dice:

function mystique_add_menu() {
     $page = add_theme_page(
          __('Mystique settings', 'mystique'),
          __('Mystique settings', 'mystique'),
         'edit_themes',
         'theme-settings',
         'mystique_theme_settings'
    );

hay que cambiar ‘edit_themes’, por ‘manage_options’.

3. Tema Tarski, versión 2.7.1. En el archivo /library/helpers/admin_helper.php, líneas 226-233, donde dice

function tarski_addmenu() {
     $page = add_theme_page(
          __('Tarski Options','tarski'),
          __('Tarski Options','tarski'),
         'edit_themes',
         'tarski-options',
         'tarski_admin'
     );

hay que cambiar ‘edit_themes’, por ‘manage_options’.

En este tema, la capacidad ‘edit_themes’ aparece otras cuatro veces en el mismo fichero (en concreto, en las líneas 53, 78, 104, 230 y 248). Hay que asegurarse de cambiarla en todas ellas por ‘manage_options’, para evitar que pueda haber problemas con el funcionamiento del tema en entornos multisitio. Por si acaso la solución no es correcta, y de paso para informar al autor del tema Tarski sobre esta circunstancia, he abierto un hilo en los foros que con tanta eficiencia administra su creador, Ben Eastaugh.

4. Tema Mandigo, versión 1.42. En este caso, son tres los archivos que deben modificarse: /backend/theme_options.php (línea 13), /backend/html_inserts.php (línea 9), en los que hay que cambiar ‘edit_themes’, por ‘manage_options’; y /backend/readme.php (línea 9), donde hay que cambiar la capacidad ‘switch_themes’, por ‘manage_options’.

Un truco antes de acabar: para encontrar la llamada a esta capacidad en cada uno de los temas mencionados, he utilizado una de mis herramientas favoritas de edición web, de la que ya traté en un artículo anterior de este blog. Me refiero a Windows Grep, una utilidad que en tareas complejas de búsqueda de código ofrece unas posibilidades inmensas.

Y esto es todo, al menos por el momento. Estoy casi seguro de que esta apasionante historia no terminará aquí, al menos para un servidor, a quien le toca la ardua tarea de actualizar en próximos días unos treinta o cuarenta temas.

Entradas relacionadas

1. Dos temas tipográficos para WordPress y sus traducciones al español
2. Más sobre temas especiales para WordPress: el tema News, 1
3. Más sobre temas especiales para WordPress: el tema News, 2
4. Más sobre temas especiales para WordPress: el tema News, 3
5. Sobre los temas de WordPress para usos especiales y la traducción del tema Portfolio Press
6. Actualización a WordPress 2.8
7. Actualización a WordPress 2.8.3
8. Actualización de WordPress a la versión 2.3.3
9. Actualización de WordPress a la versión 2.0.4
10. Actualización a la versión 1.5.1.2 de WordPress