Mientras que en producción mostrar al usuario final la información relacionada con el error producido es un riesgo de seguridad demasiado alto, durante el desarrollo del software es una condición necesaria para entender que está pasando con el código que se está probando.

En la mayoría de despliegues de Apache/PHP vienen ahora con esta opción desactivada, redireccionando por defecto los mensajes de error al archivo de registro habitualmente ubicado en /var/log/apache2/error.log.

Procedimiento

Es posible activar la opción de mostrar los errores de PHP en pantalla a tres diferentes niveles de acuerdo con el alcance que se le desee dar a este comportamiento.

A nivel global, esta modificación aplica a todo el servidor o sitios web publicados bajo esa configuración.

$ sudo vi /etc/php5/apache2/php.ini

error_reporting = E_ALL
display_errors = On

A nivel de un directorio o una aplicación, esta modificación afecta a los scripts ubicados bajo un directorio específico.

$ vi /var/html/un/directorio/especifico/.htaccess

<IfModule mod_php5.c>
    php_value error_reporting E_ALL
    php_value display_errors on
</IfModule>

A nivel de una sección de código específico, esta modificación afecta sólo una parte de un script.

$ vi /var/html/un/script.php

error_reporting(E_ALL);
ini_set('display_errors','On');

Aclaración adicional

Para que los ajustes de configuración de los últimos dos niveles sean tenidos en cuenta, el directorio donde del sitio web publicado deberá tener por lo menos activa la siguiente opción.

AllowOverride Options

Esta se deberá modificar bajo /etc/apache2/mods-enabled/userdir.conf para los sitios personales de los usuarios (public_html) o /etc/apache2/sites-enabled/* para los virtualhosts existentes.

Instalando Apache+PHP+MySQL en mi equipo con GNU/Linux Mint 12 encuentro el siguiente problema después de instalar el soporte para SQLite (php5-sqlite).

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/sqlite.so' – /usr/lib/php5/20090626+lfs/sqlite.so: cannot open shared object file: No such file or directory in Unknown on line 0

La situación

Aparentemente el uso de SQLite versión 2 ha sido desestimado en pos del uso exclusivo de la versión 3, sin embargo extrañamente la configuración por defecto de PHP sigue intentando cargar su librería.

La solución

Remover la configuración de SQLite2 de PHP y utilizar la versión 3 únicamente.

$ sudo mv /etc/php5/conf.d/sqlite.ini /etc/php5/conf.d/sqlite.ini.old

Una vez evitado que este archivo de configuración sea tenido en cuenta el funcionamiento de PHP vuelve a la normalidad.

$ php -v

PHP 5.3.6-13ubuntu3.3 with Suhosin-Patch (cli) (built: Dec 13 2011 18:37:10)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

Enlaces

• PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/sqlite.so' en Ubuntu Launchpad
  https://bugs.launchpad.net/ubuntu/+source/php5/+bug/875262

FuelPHP es un framework para el desarrollo de aplicaciones que a pesar de su muy reciente aparición es muy interesante y prometedor para el entorno del desarrollo de aplicaciones web con software libre.  Este framework es similar a Codeigniter o Kohana en términos de su simplicidad, sin embargo no se basa directamente en ninguno de ellos sino que por el contario, toma los conceptos e ideas de diseño exitosas de los principales frameworks y los integra en una única base para la implementación de aplicaciones web.

Teniendo una relativa corta edad, su desarrollo ha sido veloz y su versión 1.0 se encuentra muy próxima a publicarse.  La documentación también ha evolucionado rápidamente y se encuentra en contínua actualización.  Esta se presenta por secciones que se pueden revisar directamente siendo esto muy apropiado para las consultas rápidas de la misma sin embargo -en mi opinión personal- no es tan útil cuando se está aprendiendo del framework por primera vez ya que no es posible realizar una revisión o búsqueda líneal de los temas ni mucho menos imprimirlos.

Dado lo prometedor del framework decidí tomarme un par de minutos para desarrollar una solución que me permitiera consolidar fácilmente la documentación en un único documento para poder imprimirlo y estudiar de él.  Terminé con una pequeña herramienta basada en Javascript con jQuery que realizar esta tarea.  Debido a las limitaciones de seguridad impuestas por los navegadores es necesario que se descargue en un servidor web local la documentación para que pueda ser procesada por esta herramienta.

Debe tenerse en cuenta que los documentos generados o impresos no recibirán las contínuas actualizaciones que si recibe la versión en línea, por este motivo prefiero no distribuír el documento completo con la versión del día sino compartir el método para que pueda ser creado frecuentemente.

Instalación.

Crear una carpeta en el árbol de directorios (DOCUMENT_ROOT) públicos del servidor de páginas.

Descomprimir la distribución de la herramienta en el directorio web.

Descargar la distribución actual de FuelPHP y descomprimirla en el directorio web al mismo nivel de la herramienta. 

Los archivos contenidos en la carpeta de mas alto nivel serán similares a los mostrados a continuación en la cual se utilizó la versión 1.0-RC3 del framework.

Contenidos de la carpeta web

Configuración.

El único paso necesario para configurar la herramienta consiste en editar el archivo FuelPHPOneDoc/FuelPHPOneDoc.js y modificar apropiadamente el valor de la variable baseUrl la cual deberá contener la dirección absoluta en la cual se publicó localmente la documentación de FuelPHP.  De esta manera en el ejemplo anterior, si la carpeta pública web corresponde con la dirección http://localhost/onedoc/ entonces el valor de baseUrl será http://localhost/onedoc/v1.0-rc3/docs/.

Ejecución.

Acceder al URL de la herramienta utilizando un navegador web.  En el caso del ejemplo anterior sería a la dirección http://localhost/onedoc/FuelPHPOneDoc/FuelPHPOneDoc.html.

Documentación de FuelPHP en un unico documento

Requerimiento: servidor de páginas web.

Por la razón que se mencionó anteriormente, es necesario contar con un servidor de páginas web para publicar tanto el contenido de la documentación original de FuelPHP como la herramienta para modificar su presentación.

En caso de no contarse con un servidor de páginas instalado, este podrá obtenerse de diferentes maneras: Apache (todas las plataformas), Internet Information Service (sólo Windows), XAMPP (todas las plataformas) y nginx (todas las plataformas) entre muchos otros.

Si no se cuenta con ninguno de estos servidores de páginas web pero se cuenta con soporte para el lenguaje Python, es posible utilizar temporalmente el servidor web de desarrollo que incluye este lenguaje.  Para utilizarlo será necesario abrir una terminal y ubicarse en el directorio que se convertirá en público a través de web e invocar la aplicación.

$ cd /home/jimezam/tmp/FuelPHP

Si cuenta con soporte para Python 2.x:

$ python -m SimpleHTTPServer

En cambio, si se cuenta con soporte para Python 3.x, la instrucción a ejecutar será la siguiente.

$ python -m http.server 8000

En ambos casos el puerto que se utilizará para lanzar el nuevo servidor web será el 8000 así que este tendrá que ser tenido en cuenta durante la determinación del respectivo URL.  En este caso, el URL que deberá ser consultado será http://localhost:8000/FuelPHPOneDoc/FuelPHPOneDoc.html.

WordPress tiene una característica que consiste en reemplazar ciertos carácteres o cadenas en sus correspondencias mas bonitas, por ejemplo reemplaza los guiones dobles por un único guión mas largo que el normal.  Esto lo hace para embellecer los textos que se publican.

Este loable objetivo puede ser interesante en la mayoría de los casos pero es un total infortunio para quienes publicamos código fuente o textos para ejecutarse en la línea de comando los cuales deberán transcribirse de manera fiel o simplemente fallarán debido a que cualquier variación como las propuestas les harán perder su validez sintáctica.

Hace un tiempo encontré como solución modificar las líneas exactas en las cuales WordPress realiza esta inoportuna conversión, sin embargo estas líneas pertenecen a un archivo del núcleo de WordPress y desafortunadamente es sobreescrito durante las actualizaciones de WordPress y por ende las modificaciones se pierden con la misma regularidad.

Para solventar esto he encontrado una solución similar que se basa en la adaptación de un plugin ya existente, así que las modificaciones perdurarán a las actualizaciones de WordPress y sólo deberán repetirse ante una posible actualización del plugin, las cuales por supuesto suceden con una frecuencia mucho menor.

Procedimiento.

Instalar y activar el plugin de WordPress llamado untexturize.

Editar el contenido del archivo wpuntexturize.php.  Por facilidad se recomienda utilizar el mismo editor de Plugins que provee WordPress.

Identificar el código fuente de la función c2c_wpuntexturize y modificar su contenido de la siguiente manera.

$char_codes = array( '‘', '’', '“', '”', '′', '″',
                     '—', ' — ', '–', ' – ', 'xn--');   // nuevo.
$replacements = array( "'", "'", '"', '"', "'", '"',
                       '---', ' -- ', '--', ' - ', 'xn–');    // nuevo.
return str_replace( $char_codes, $replacements, $text );

Si se nota, las líneas marcadas con el comentario nuevo han sido agregadas con respecto al código fuente original del plugin, estas líneas corresponden con la información de los reemplazos de los guíones facultando al plugin a regresarlos a su presentación original mas allá de sólo las comillas dobles las cuales son la funcionalidad propia del complemento.

A partir del momento en que se realicen estas modificaciones, las entradas del blog mostrarán correctamente las comillas y guíones dobles en sus textos.

Enlaces.

• Plugin de WordPress wpuntexturize.
  http://coffee2code.com/wp-plugins/wpuntexturize/

Esta es una aplicación muy sencilla que se desarrolló en PHP para el sexto Congreso Colombiano de Computación.  Todo comenzó cuando no me resultó cómoda la manera como el sitio web desplegaba la programación del evento: por bloques de auditorios siendo las filas conferencias y las columnas los días de las mismas.

Programación del 6CCC (versión original)

Este estilo de presentación no es conveniente ya que no me permite visualizar fácilmente que conferencias se están realizando en un momento dado para poder decidir a cual de ellas asisto, es decir, el estilo idóneo de presentación de las conferencias debería ser en el que cada bloque representa un día del evento, cada fila un rango de tiempo específico y cada columna un auditorio donde se estén realizando las conferencias.  De esta manera, una vez ubicado el rango de tiempo que se desea consultar sólo será necesario revisar las columnas para determinar las conferencias a las que se puede asistir.

Ya que manipular manualmente esta información  para poder determinar cuales eran las conferencias que quería ver era demasiado engorroso decidi implementar una solución computacional muy simple.  Inicialmente la iba a desarrollar en Javascript por completo manipulando el árbol DOM pero me dí cuenta que podría serle de utilidad a otras personas también y preferí no sobrecargar al navegador del cliente con las operaciones de transformación del contenido del programa.  El resultado final fue el siguiente.

Programación del 6CCC (versión mejorada)

El prototipo.

Las premisas eran las siguientes.

• No sobrecargar al cliente con cálculos en Javascript para facilitar la consulta desde móviles.
• No requerir que se ingrese la información de la programación nuevamente, se debería tomar de la programación existente directamente.
• Actualizarse automáticamente a la par de la programación original (esta última debería respetar su estructura HTML).
• Facilitar la lectura de la información.
• Facilitar la consulta de las conferencias presentándose en un momento específico del día y cuales se están presentando en este mismo momento.
• Permitir la personalización de la presentación (esto se obtuvo mediante la implementación de una vista independiente de la lógica de procesamiento y de clases CSS).

El prototipo se implementó en PHP sin ningún tipo de framework especializado y utilizando la técnica de web scraping para obtener directamente la información de la página web original de la programación, de ahí que fuera necesario que esta respetara su estructura HTML durante las actualizaciones.  Para esto se utilizó la librería phpQuery la cual permite entre otras cosas obtener secciones de código HTML mediante rutas de selectores CSS de manera similar a jQuery.

Conclusiones.

• El uso de phpQuery para las necesidades del prototipo no fue tan simple ni intuitivo como lo es el uso de jQuery, sin embargo una vez entendida su implementación, permitió desarrollar la funcionalidad necesaria.
• La programación original contaba con múltiples inconsistencias: diferentes formatos de fecha, la presencia de un día adicional en la programación general, la presencia de las temáticas generales de los bloques de conferencias en el mismo contenido de las conferencias, conferencias sin hora específica y, filas y columnas vacías para generar espacios en las tablas.  Por este motivo el prototipo incluye varias validaciones para solventar estos problemas que dificultan la adquisición de la información.
• El prototipo toma la fecha y hora del sistema para determinar las conferencias que se están presentando actualmente (tanto para resaltarlas en el listado como para mostrarlas al inicio de la programación).  No se tuvieron en cuenta diferencias en la zona horaria.
• El prototipo no pudo ser incluído en el sitio web del congreso ya que fue desarrollado utilizando PHP 5.3 (utiliza una función anónima en PHP) mientras que el hosting utilizado por la página era 5.2 y no se contaba con la información necesaria para convertir la sintáxis de la función anónima al estilo antiguo.
• El código fuente del prototipo fue liberado bajo la licencia Creative Commons Attribution 3.0.

Enlaces.

• Demostración del prototipo, versión 0.1.
  http://demo.jorgeivanmeza.com/PHP/6CCCProg/0.1/
• Obtener el código fuente del prototipo.
  http://demo.jorgeivanmeza.com/PHP/6CCCProg/
• Librería phpQuery.
  http://code.google.com/p/phpquery/
• Sexto Congreso Colombiano de Computación (6CCC).
  http://www.6ccc.org/

Preparé el prototipo de esta aplicación web muy simple para experimentar con algunas librerías que tenía por revisar, que a pesar de ser muy sencillas de utilizar es bueno ir conociendo para determinar mas adelante cual de todas las disponibles es la idónea.

Esta es de manera resumida la funcionalidad del prototipo.

• Obtiene cierta cantidad de tweets de ciertos usuarios predefinidos.
• Los tweets son alamcenados en caché por una cantidad específica de tiempo.
• El acceso a la página no requiere de ningún tipo de autenticación por parte del usuario.
• Cuando el usuario accede al sitio web, el sistema elige un tweet azar y lo muestra.
• La elección del tweet se realiza sobre los almacenados en el caché.  Si no hay caché o este es demasiado viejo, entonces se renueva automáticamente.
• Los mensajes que no se encuentran escritos en español son traducidos automáticamente a este idioma.
• Se prepara un enlace corto a la información del tweet.
• Se presenta un QRCode con el enlace corto al tweet para ser fácilmente consultado por dispositivos móviles.

Herramientas.

Estas fueron las herramientas utilizadas durante el desarrollo del prototipo.

1. Netbeans (IDE).
2. SQLite (persistencia del caché).
3. Blueprint CSS Framework (framework para la presentación).
4. PHP (lenguaje de programación).
5. Yii PHP Framework (framework de desarrollo web).
6. Extensión de CURL para Yii (acceder al servicio REST fácilmente).
7. API REST de Twitter (obtener los mensajes).
8. Google Translate Service (servicio de traducción de textos).
9. jquery-qrcode para la generación de los códigos QR.
10. jquery-urlshortener que utiliza el servicio de bit.ly (acortador de URLs).

Prototipo.

Prototipo de Give Me a Tweet

Instalación.

El código fuente del protitpo puede obtenerse desde la siguiente ubicación.

https://github.com/jimezam/Give-Me-a-Tweet/tree/v1.0

Para la ejecución de la aplicación web se requiere que se cuente además de la infraestructura web, con PHP con soporte para SQLite y CURL, y la distribución del Yii PHP Framework (1.1.7 o similar) en una ubicación conocida.

Finalmente se deberán modificar los siguientes archivos para ajustarlos a la infraestructura local.

index.php:

$yii=dirname(__FILE__).’/../../yii-1.1.7.r3135/framework/yii.php’;
$config=dirname(__FILE__).’/protected/config/main.php’;

Ajustar estas rutas a la ubicación real del framework.

protected/views/tweet/show.php:

$.shortenUrl.settings.login  = ‘USUARIO‘;
$.shortenUrl.settings.apiKey = ‘LLAVE DEL API‘;

Modificar estos valores para que correspondan con la información del propietario del servicio.  Esta información se puede obtener de manera gratuita en el sitio web de bit.ly para desarrolladores.

Enlaces.

• Netbeans.
  http://netbeans.org/
• SQLite.
  http://sqlite.org/
• jQuery.
  http://jquery.org/
• Blueprint CSS Framework.
  http://www.blueprintcss.org/
• PHP.
  http://php.net/
• Yii PHP Framework.
  http://www.yiiframework.com/
• Extensión CURL para Yii.
  http://www.yiiframework.com/extension/curl/
• Introduction to developing with @twitterapi.
  http://dev.twitter.com/pages/intro-to-twitterapi
• Twitter, get statuses and user timeline.
  http://dev.twitter.com/doc/get/statuses/user_timeline
• Plugin jquery.qrcode.js.
  http://jeromeetienne.github.com/jquery-qrcode/
• Plugin jquery-urlshortener.
  https://bitbucket.org/jiaaro/jquery-urlshortener/wiki/Home

Es necesario reemplazar el nombre de la versión Lucid Lynx de Ubuntu por la actual Maverick Meerkat en la siguiente línea.

grep ‘main restricted’ /etc/apt/sources.list|grep -v “#”| sed s/lucid/karmic/g | sudo tee /etc/apt/sources.list.d/karmic.list > /dev/null

De esta manera.

grep ‘main restricted’ /etc/apt/sources.list|grep -v “#”| sed s/maverick/karmic/g | sudo tee /etc/apt/sources.list.d/karmic.list > /dev/null

Descargue el script modificado y continúe con las instrucciones mencionadas en el artículo anterior.

Si desea instalar el módulo de Apache correspondiente ejecute el siguiente comando y no acepte la versión 5.3 para que sea instalada la anterior.

$ sudo aptitude install libapache2-mod-php5

The following NEW packages will be installed:

libapache2-mod-php5{b}

0 packages upgraded, 1 newly installed, 0 to remove and 20 not upgraded.
Need to get 0B/3,105kB of archives. After unpacking 8,704kB will be used.

The following packages have unmet dependencies:
libapache2-mod-php5: Depends: php5-common (= 5.3.3-1ubuntu9.1) but 5.2.10.dfsg.1-2ubuntu6.5 is installed and it is kept back.

The following actions will resolve these dependencies:

Keep the following packages at their current version:
1)     libapache2-mod-php5 [Not Installed]

Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

Install the following packages:
1)     libapache2-mod-php5 [5.2.10.dfsg.1-2ubuntu6.5 (karmic-security, karmic-updates)]

Accept this solution? [Y/n/q/?] y

The following NEW packages will be installed:
libapache2-mod-php5

0 packages upgraded, 1 newly installed, 0 to remove and 20 not upgraded.
Need to get 2,643kB of archives. After unpacking 6,189kB will be used.
Do you want to continue? [Y/n/?] y

Desde hace un tiempo había decidido probar otros servidores de páginas diferentes de Apache en busca de uno que consumiera menos recursos, especialmente para la etapa de desarrollo.  Después de una revisión a la oferta de servidores web y a los comentarios encontrados en los foros los mas opcionados son: Nginx, Cherokee y Lighttpd.  En esta ocasión estoy probando al primero de ellos.

Instalar los paquetes necesarios.

$ sudo aptitude install php5-cgi php5-cli php5-common php5-curl php5-gd php5-json php5-mcrypt php5-sqlite php5-mysql

$ sudo aptitude install spawn-fcgi

$ sudo aptitude install nginx

Crear un directorio para el virtualhost.

En este caso se va a utilizar el sitio web por defecto (default) y se va a ubicar en /home/www/public, los virtualhosts adicionales se crean siguiendo los mismos pasos.

$ sudo mkdir -p /home/www/public

$ sudo mkdir /home/www/logs

$ sudo chown -R www-data:www-data /home/www

Establecer la configuración del virtualhost.

$ sudo vi /etc/nginx/sites-available/default

server {
    listen       80 default;
    server_name  localhost;
    access_log   /home/www/logs/localhost.access.log;
    location / {
        root   /home/www/public;
        index  index.html index.htm;
    }
    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /home/www/public$fastcgi_script_name;
        include fastcgi_params;
    }
}

Tenga en cuenta que las rutas asignadas a las variables access_log, root y fastcgi_param se relacionan con los directorios creados en el paso anterior.

Activar el virtualhost.

En este caso se utiliza el sitio por defecto, sin embargo pueden crearse nuevos simplemente utilizando un nombre diferente para el enlace.

$ sudo /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default

Crear un recubrimiento para spawn-fcgi.

$ sudo vi /etc/init.d/php-fastcgi

#!/bin/bash
BIND=127.0.0.1:9000
USER=www-data
PHP_FCGI_CHILDREN=5 #15
PHP_FCGI_MAX_REQUESTS=1000
PHP_CGI=/usr/bin/php-cgi
PHP_CGI_NAME=`basename $PHP_CGI`
PHP_CGI_ARGS="- USER=$USER PATH=/usr/bin PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND"
RETVAL=0
start() {
      echo -n "Starting PHP FastCGI: "
      start-stop-daemon --quiet --start --background --chuid "$USER" --exec /usr/bin/env -- $PHP_CGI_ARGS
      RETVAL=$?
      echo "$PHP_CGI_NAME."
}
stop() {
      echo -n "Stopping PHP FastCGI: "
      killall -q -w -u $USER $PHP_CGI
      RETVAL=$?
      echo "$PHP_CGI_NAME."
}
case "$1" in
    start)
      start
  ;;
    stop)
      stop
  ;;
    restart)
      stop
      start
  ;;
    *)
      echo "Usage: php-fastcgi {start|stop|restart}"
      exit 1
  ;;
esac
exit $RETVAL

$ sudo chmod +x /etc/init.d/php-fastcgi

Iniciar manualmente los servicios.

$ sudo /etc/init.d/nginx start

$ sudo /etc/init.d/php-fastcgi start

Configurar el inicio automático de los servicios (opcional).

$ sudo update-rc.d nginx defaults

$ sudo update-rc.d php-fastcgi defaults

Probar el servicio.

$ vi /home/www/public/test.php

<?php phpinfo(); ?>

Acceder a la página web http://localhost/test.php desde el equipo local.

PHPList es un software libre para la gestión del envío de correos masivos, muy útil para realizar campañas de mercadeo, promoción o boletines.  Es un aplicativo con una amplia funcionalidad pero su interfaz no es la mas intuitiva, por lo que algunas veces no es rápido su aprendizaje.

En su sitio web definen a PHPList de la siguiente manera.

phplist is the world's most popular open source email campaign manager. phplist is free to download, install and use, and is easy to integrate with any website. phplist is downloaded more than 10,000 times per month.

La solución que se documenta en el presente artículo es la de configurar a PHPList para que permita adjuntar imágenes a los mensajes HTML.  Esto es diferente a insertar imágenes provenientes de otros sitios web ya que en este caso sólo se envían referencias externas en los mensajes, mientras que con esta nueva aproximación las imágenes se incluyen físicamente en el mensaje enviado a los clientes.

Procedimiento.

Configurar el uso de FCKEditor

Es necesario utilizar FCKEditor en lugar de TinyMCE como editor WYSIWYG para los mensajes.  Para esto es necesario realizar los siguientes ajustes en la configuración.

$ vi <ruta>/lists/config/config.php

define("USEFCK",1);

define("USETINYMCEMESG", 0);

Definir el directorio para almacenar las imágenes cargadas.

El primer paso es crear el directorio bajo el directorio de PHPList.

$ mkdir <ruta>/lists/uploadimages

$ chmod 777 <ruta>/lists/uploadimages

El siguiente paso es informarle a PHPLists que utilice efectivamente el directorio recién creado.

$ vi <ruta>/lists/config/config.php

define("FCKIMAGES_DIR","uploadimages");

Verificación.

Después de desarrollado este procedimiento ya es posible acceder al módulo para cargar imágenes en el servidor mediante el ícono y presionando el botón Browse Server.

Subir imágenes al servidor para ser incluídas en mensajes de PHPList

Solución de problemas.

Problemas con el XML generado por el servidor.

Si se obtiene el mensaje "The server didn't reply a with proper XML data. Please check your configuration." cuando se accede a las imágenes almacenadas en el servidor, es necesario realizar el ajuste descrito a continuación.

Mensaje de error de PHPList

Para solucionar este bug es necesario realizar la siguiente modificación en la configuración del conector con el FCKEditor.

$ vi <ruta>/lists/admin/FCKeditor/editor/filemanager/connectors/phplist/config.php

Las líneas 28 y 29 (versión 2.10.12 de PHPList) contienen las siguientes rutas incorrectas.

} elseif (is_file('../../../../../../../../config/config.php')) {
include "../../../../../../../../config/config.php";

Deben corregirse de la siguiente manera: eliminando dos niveles inexistentes.

} elseif (is_file('../../../../../../config/config.php')) {
include "../../../../../../config/config.php";

Después de hecha la corrección del error, acceda o refresque el sitio y acceda al plugin normalmente.

Enlaces.

• PHPList.
  http://www.phplist.com/
• UsingFCKEditor.
  http://docs.phplist.com/UsingFCKEditor
• v 2.10.10 Upload XML Error.
  http://forums.phplist.com/viewtopic.php?f=17&t=24547#p62700

La versión mas reciente de Ubuntu, Lucid Lynx (10.04), incluye en sus repositorios por defecto la versión 5.3 de PHP la cual trae consigo una serie de modificaciones considerables que hacen que muchas de las aplicaciones requieran algún tipo de modificaciones para funcionar correctamente.

Mientras se realizan estas modificaciones para actualizar las aplicaciones sea hace necesario continuar utilizando las aplicaciones existentes y para esto se debe reemplazar la versión instalada de PHP por la versión mas reciente de la serie anterior (5.2.x).  La migración no es trivial debido a que los paquetes vienen directamente de los repositorios, sin embargo si se utiliza el script provisto opr KAndy el proceso se simplifica enormemente.

Instalación de PHP.

Si aún no cuenta con PHP instalado en el equipo puede realizar una instalación básica mediante la ejecución de la siguiente instrucción.  Instale los demás paquetes que considere necesarios.

$ sudo aptitude install apache2 php5 php5-cli php5-mysql

En este punto el equipo tendrá instalado PHP 5.3 y es el momento de degradarlo a su versión anterior.

$ php -v

PHP 5.3.2-1ubuntu4.2 with Suhosin-Patch (cli) (built: May 13 2010 20:03:45)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

Degradar PHP.

Tomar nota de los paquetes relacionados con PHP que se encuentran actualmente instalados.

$ php_installed=`dpkg -l | grep  php| awk  ‘{print $2}’ |tr “\n” ” “`

Descargar el script de KAndy de la siguiente ubicación y almacenarlo con el nombre de downgradePHP.sh.

http://mrkandy.wordpress.com/2010/04/16/install-php-5-2-x-in-ubuntu-10-04-lucid/

Ejecute el script en la máquina que se desea degradar.

$ chmod +x downgradePHP.sh

$ ./downgradePHP.sh

Recuperar los demás paquetes instalados.

$ sudo apt-get install $php_installed

Verificar la nueva versión de PHP.

$ php -v

PHP 5.2.10-2ubuntu6 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 16:28:03)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

Enlaces.

• Install (downgrade) php 5.2.x in Ubuntu 10.04 Lucid.
  http://mrkandy.wordpress.com/2010/04/16/install-php-5-2-x-in-ubuntu-10-04-lucid/
• Ubuntu 10.04 and Drupal.
  http://civicactions.com/blog/2010/may/26/ubuntu_1004_and_drupal