Programador ASP

Recientemente en WordPress MU se me ha dado el caso de que la página de configuración de widgets ha dejado de funcionar en todos mis sitios, no se podía hacer drag and drop en ella ni aparece la barra (sidebar) con los widgets activados. Después de buscar mucho por Internet, leí que ciertos plugins pueden ocasionar que la página de widgets deje de funcionar. Activando y desactivando uno a uno todos los plugins, observé que el error se daba cuando estaba activado el plugin Google Analyticator de Spiral Web Consulting. Tenía la versión 5.3.1 instalada, así que miré en otros blogs (no WordPress MU) y vi que tenía la versión 2.40, originalmente de Cavemonkey y Ronald Heft. Así que sustituí la carpeta del plugin google-analyticator 5.3.1 por la versión 2.40 y la página de widgets volvió a funcionar. Sé que las combinaciones de plugins y versiones pueden ser muchas, pero expongo la solución a este caso concreto que me ocurrió a mí por si puede resultar de utilidad u orientación a alguien que pueda tener un problema parecido.

Como ya mencioné en el artículo sobre qué hacer cuando el archivo .mo de traducción del tema de WordPress no funciona, para traducir un tema de WordPress en primer lugar es necesario aplicar las funciones __() y _e() a todas las frases y expresiones que se quieran traducir contenidas en los archivos del tema. La función __() devuelve la expresión traducida, mientras que la función _e() devuelve la expresión traducida y además la muestra por pantalla (echo), siempre que se disponga del archivo de traducción adecuado con extensión .mo. La mayoría de los temas vienen con las funciones __() y _e() aplicadas, aunque hay algunas expresiones en las que deberemos añadirlas nosotros a mano. Como se explica en el artículo mencionado, en las funciones __() y _e() también es necesario indicar el normbre del tema, de la forma:

_e('This post was written by ','nombre_tema');

y especificar que cargue el el archivo de localización .mo del tema añadiendo la línea

<?php load_theme_textdomain('nombre_tema'); ?>

en algún archivo que se cargue siempre (como header.php).

Una vez tengamos todas las expresiones que queremos traducir con las funciones __() y _e() aplicadas, hay que utilizar la herramienta gettext, que rastrea todos los archivos del tema y extrae todas las expresiones que encuentra que utilicen las funciones __() y _e(). Las expresiones las almacena en un archivo de texto con extensión .po. Existen muchas versiones de herramientas gettext, por ejemplo el popular programa PoEdit trae entre sus archivos el ejecutable xgettext.exe.

Para utilizar el programa xgettext, los pasos básicos a seguir son:

1.- Introducir en un archivo de texto una lista de los archivos a rastrear. Se puede hacer desde la carpeta donde tengamos el tema con “dir > archivos.txt” desde la línea de comandos y después editar el archivo para quedarnos sólo con la lista de archivos PHP.
2.- Ejecutar desde la línea de comandos “PATH c:\archivos de programa\poedit\bin” (o la ruta del ejecutable xgettext.exe) para que lo tengamos disponible desde la carpeta del tema.
3.- Ejecutar xgettext de la siguiente forma (todo en una línea):

xgettext.exe --keyword=__ --keyword=_e --language=PHP
--files-from=archivos.txt --from-code=UTF-8 -d es_ES

lo cual generará un archivo es_ES.po con todas las expresiones que haya encontrado en las funciones __() y _e(). Si queremos añadir nuevas expresiones para traducir a un catálogo .po ya existente, hay que utilizar -j:

xgettext.exe --keyword=__ --keyword=_e --language=PHP
--files-from=0.txt -j --from-code=UTF-8 -d es_ES

Una vez tengamos el archivo .po generado lo podemos traducir con la ayuda del programa PoEdit, que también genera el archivo .mo final.

Más info: Localización con WordPress

Recientemente he cambiado mi blog Chistes con buen humor de servidor Windows 2003 a Linux. Al intentar subir imágenes en el nuevo hosting me daba varios errores de permisos. Expongo aquí una lista de problemas que pueden darse y cómo solucionarlos.

- En primer lugar, hay que asegurarse que la carpeta “wp-content/uploads” tiene permisos de escritura 755.
- En el panel de control de WordPress, en Opciones / Misceláneas, en “Guardar los archivos subidos en esta carpeta” la ruta de archivos no debe ser formato Windows (C:\http\sites\…) sino Linux, lo mejor es dejar la carpeta por defecto, “wp-content/uploads”.
- Por último, uno de los errores que más me trajo de cabeza era “No se pudo crear el directorio /var/www/vhosts/chistesconbuenhumor.com/httpdocs/wp-content/2009/05. Asegúrese de que el servidor tiene permisos de escritura para el directorio superior”. Investigando un poco averigüé que el error se daba por tener el modo seguro de PHP (safe_mode) activado en el hosting, con lo que había que desactivarlo en las propiedades del dominio (http://de.php.net/features.safe-mode):

Modo seguro (safe mode) PHP en Plesk

En una ocasión, instalando un servidor web con sistema operativo Linux Debian y soporte para PHP y MySQL, me encontré al instalar WordPress para un blog con el problema “Parece que tu instalación de PHP no cuenta con la extensión de MySQL, necesaria para WordPress”. La solución al problema es descomentar una línea del archivo php.ini, como especifica Patob en su blog. Hay que descomentar en el php.ini, generalmente en /etc/php5/apache2/php.ini (eliminar el punto y coma ; de delante) la línea:

;extension=mysql.so

con esto PHP carga la extensión para MySQL automáticamente. Por último reiniciamos Apache y MySQL:

#/etc/init.d/apache restart
#/etc/init.d/mysql restart

y este problema debería solucionarse.

Como ya sabe cualquier usuario avanzado de WordPress, el panel de control y algunas frases genéricas de este CMS se pueden traducir al español poniendo el archvio es_ES.mo en /wp-content/languages y definiendo en /wp-config.php la línea define(‘WPLANG’,'es_ES’);

Pero para traducir un tema en particular, es necesario poner todas las frases que se quieran traducir entre las funciones __() y _e(), generar el archivo .po a partir de una herramienta como gettext y traducir todas las expresiones con la ayuda de algún programa como PoEdit, que también genera el archivo .mo final. No es mi intención explicar este proceso en este artículo (más sobre la herramienta gettext), sino abordar un problema que se me ha planteado y me ha costado mucho de solucionar.

Cuando tenemos el archivo de traducción del tema al español es_ES.mo generado, suele ocurrir que al actualizarlo en Internet el tema sigue apareciendo en inglés. Después de buscar mucho por Internet y no hallar solución, me fijé en algunos temas ya traducidos como mandingo y encontré la causa del problema. Pensaba que por defecto cualquier tema buscaba en la carpeta raíz el archivo de traducción a partir del parámetro WPLANG (en nuestro caso ‘es_ES’), pero no es así, hay que indicárselo.

En primer lugar, hemos de cargar el archivo de localización .mo del tema y esto se hace con la función load_theme_textdomain(‘nombre_tema’), así que hay que poner en algún archivo que se cargue siempre (como header.php) la siguiente línea:

<?php load_theme_textdomain('nombre_tema'); ?>

A continuación, en todos los archivos php del tema donde se utilicen las funciones de traducción __() y _e(), hay que especificarle el tema en todas las llamadas a esas funciones, por ejemplo:

_e('This post was written by ');

cambia a

_e('This post was written by ','nombre_tema');

y eso es todo. Es un poco de trabajo adicional pero así conseguimos que funcione nuestra propia traducción del tema.

Para no tener que hacer esto con todas las llamadas a las funciones __() y _e(), pensé en ir a su definición y modificar directamente el $domain, que por defecto es ‘default’, es decir, en /wp-includes/l10n.php cambiar el tema por defecto:

function __($text, $domain = 'default')

cambia a

function __($text, $domain = 'nombre_tema')

pero esto hace que el panel de control de WordPress pierda la traducción, ya que deja de cargar el archivo es_ES.mo genérico de /wp-content/languages, así que no tendremos más remedio que modificar todas las llamadas a las funciones __() y _e().