Para hacer unas pruebas esta tarde necesito un proxy que haga caché sobre los datos descargados; inicialmente iba a instalar Squid sobre un Scientific Linux pero decidí hacerlo sobre ArchLinux, con el cual estoy jugando desde el día de ayer.  Leyendo la documentación del wiki de ArchLinux, que por cierto es muy buena, encontré que hacen referencia a Polipo, un software similar en funciones a Squid pero con mayores limitaciones y destinado a servidores con muy pocos usuarios.  Ese es mi caso, así que procedí a instalarlo en una máquina virtual con VirtualBox y 512MB de RAM.  Espero que aguante.

Instalación de los paquetes.

Desafortunadamente lo paquetes de Polipo no están disponibles en los repositorios, sin embargo estos pueden ser creados utilizando una facilidad interesante del sistema operativo.

Los siguientes pasos deben realizarse como un usuario sin privilegios.

Descargar la versión mas reciente de los archivos (sección de files) de Polipo de la siguiente ubicación.

http://aur.archlinux.org/packages.php?ID=14579

$ wget http://aur.archlinux.org/packages/polipo/polipo/PKGBUILD

$ wget http://aur.archlinux.org/packages/polipo/polipo/polipo.install

$ wget http://aur.archlinux.org/packages/polipo/polipo/polipo

Generar el paquete.

$ makepkg -s

Instalar el paquete recién generado.

$ sudo pacman -u polipo-1.0.4.1-1-x86_64.pkg.tar.xz

Configuración de Polipo.

Crear un archivo básico de configuración a partir de la plantilla.

$ sudo cp /etc/polipo/config-sample /etc/polipo/config

Permitir las conexiones externas, además de localhost.

$ sudo vi /etc/polipo/config

proxyAddress = “0.0.0.0″

Si se desea permitir el uso del caché por equipos diferentes del mismo (localhost)  es necesario especificar las redes autorizadas en la siguiente variable del mismo archivo config.  Nótese que, a diferencia del ejemplo en el mismo archivo, fue necesario remover las comillas dobles que encerraban las direcciones de red.

allowedClients = 127.0.0.1, 10.0.0.0/16, 192.168.1.0/24

Actualizar el archivo de inicio de Polipo.  Nótese en el script que por razones de seguridad se utilizará al usuario nobody para ejecutar el servicio.

$ sudo cp /etc/rc.d/polipo /etc/rc.d/polipo.orig

$ sudo vi /etc/rc.d/polipo

#!/bin/bash
. /etc/rc.conf
. /etc/rc.d/functions
DAEMON=polipo
ARGS="daemonise=true pidFile=/var/run/$DAEMON/$DAEMON.pid"
PID=`pidof -o %PPID /usr/bin/$DAEMON`
case $1 in
    start)
        stat_busy "Starting $DAEMON"
        rm /var/run/$DAEMON/$DAEMON.pid 2> /dev/null
        install -d /var/run/$DAEMON
        ## /usr/bin/$DAEMON $ARGS >/dev/null 2>&1
        sudo -u nobody /usr/bin/$DAEMON $ARGS >/dev/null 2>&1
        if [[ $? != 0 ]]; then
            stat_fail
        else
            add_daemon $DAEMON
            stat_done
        fi
    ;;
    stop)
        stat_busy "Stopping $DAEMON"
        kill $PID >/dev/null 2>&1
        if [[ $? != 0 ]]; then
            stat_fail
        else
            rm_daemon $DAEMON
            stat_done
        fi
    ;;
    purge)
        stat_busy "Purging polipo"
        [[ ! -d /var/run/polipo ]] && mkdir /var/run/polipo
        if ! ck_daemon polipo; then
            kill -USR1 $DAEMON >/dev/null 2>&1 || stat_die $?
            sleep 1
            /usr/bin/$DAEMON -x $ARGS >/dev/null 2>&1 || stat_die $?
            kill -USR2 $PID >/dev/null 2>&1 || stat_die $?
            stat_done
        else
            /usr/bin/$DAEMON -x $ARGS >/dev/null 2>&1 || stat_die $?
            stat_done
        fi
    ;;
    restart)
        $0 stop
        sleep 1
        $0 start
    ;;
    *)
        echo "usage: $0 {start|stop|restart|purge}"
    ;;
esac

Ajustes al sistema operativo.

Crear un proceso cron para purgar el servicio.

$ sudo vi /etc/cron.weekly/polipo

#!/bin/sh
/etc/rc.d/polipo purge >/dev/null 2>&1

$ sudo chmod +x /etc/cron.weekly/polipo

Crear las rutas necesarias para los archivos del proxy.

$ sudo touch /var/log/polipo

$ sudo chown nobody:nobody /var/log/polipo

$ sudo mkdir /var/run/polipo

$ sudo chown nobody:nobody /var/run/polipo

$ sudo mkdir /var/cache/polipo

$ sudo chown nobody:nobody /var/cache/polipo

Configurar el inicio automático de Polipo con el sistema operativo.

$ sudo vi /etc/rc.conf

DAEMONS=(syslog-ng network netfs polipo crond)

Prueba del caché.

Configure el proxy de Firefox o de cualquier otro cliente y acceda a los recursos que desee, estos deberán almacenarse en el caché por lo cual futuros accesos (recuerde limpiar el caché local de ser necesario para hacer mas confiable la prueba) deberían ser más rápidos.  Como ubicación del servidor de caché utilice la IP del servidor donde se instaló Polipo y el puerto -por defecto- 8123.

Enlaces.

• Polipo - a caching web proxy.
  http://www.pps.jussieu.fr/~jch/software/polipo/
• Polipo en ArchLinux.
  http://wiki.archlinux.org/index.php/Polipo

No disponible por mantenimiento programado. Vuelve a comprobarlo en unos minutos. Gracias

O su versión en inglés.

Briefly unavailable for scheduled maintenance. Check back in a minute.

Algunas veces algo falla en la actualización, frecuentemente me ha sucedido durante la actualización de plugins, y el modo mantenimiento no se restaura automáticamente queda el sitio aisaldo.

Para corregir este problema es necesario acceder al sistema de archivos del sitio y remover un archivo llamado .maintenance en la raíz del blog.

La situación es la siguiente, se cuenta con un CMS desarrollado en PHP bajo el framework de CodeIgniter con su propio sistema de autenticación en el que se almacenan los usuarios de la siguiente manera.

CREATE TABLE IF NOT EXISTS `core_usuario` (
`id_usuario` int(11) unsigned NOT NULL auto_increment,
`estado` enum(‘activo’,'inactivo’) NOT NULL,
`_username` varbinary(16) NOT NULL,
`_password` varbinary(32) NOT NULL,
`nombres` varchar(50) NOT NULL,
`apellidos` varchar(50) NOT NULL,
`fecha_nacimiento` date default NULL,
`tipo_documento` enum(‘cc’,'ce’,'ti’,'nit’) NOT NULL,
`documento_identidad` varchar(12) NOT NULL,
`genero` enum(‘m’,'f’) NOT NULL,
`correo` varchar(255) NOT NULL,
`pagina` varchar(255) default NULL,
`observaciones` varchar(255) default NULL,
`fecha_creacion` datetime NOT NULL,
`fecha_actualizacion` datetime NOT NULL,
PRIMARY KEY  (`id_usuario`),
);

En el sitio se ha instalado un foro basado en la versión 1.1.11 de Simple Machines el cual comparte la base de datos con el CMS.  Se necesita encontrar la forma de unificar los nombres de los usuarios y las contraseñas para tener una única identificación para la autenticación en los dos sistemas.

Para hacer esto se utiliza el API de SSI de SMF de la siguiente manera.

Hooks de integración.

SMF provee una facilidad para alterar el ciclo de flujo del software mediante la manipulación de hooks que se agregan a etapas específicas del programa para modificar su comportamiento por defecto.  En este caso nos interesa crear un hook sobre el punto integrate_validate_login ya que ese es el punto exacto en que SMF va a realizar la validación de los usuarios durante su autenticación.

Para implementar esto se crea un archivo llamado jimhook.php (el nombre es arbitrario) con el siguiente contenido inicial.

<?php
define('SMF_INTEGRATION_SETTINGS', serialize(array(
    'integrate_validate_login' => 'user_validate',
)));

require_once('SSI.php');

function user_validate()
{
    // Implementación de la lógica de la nueva autenticación.
}
?>

Estos hooks deben asociarse al sistema de foros agregando la siguiente línea al inicio del archivo index.php.

include_once("jimhook.php");

Conexión a la base de datos.

Como se mencionó inicialmente el CMS fue desarrollado en CodeIngniter y en este caso, comparte la base de datos con los foros.  El primer paso es obtener la información de conexión a la base de datos desde los archivos de configuración del CMS.

define('BASEPATH', 1);
include('../pt/system/application/config/database.php');

Teniendo esta información se realiza una conexión global a la base de datos utilizando las funciones de PDO.

$pdo = null;

try
{
    $pdo = new PDO("mysql:host={$db['default']['hostname']};dbname={$db['default']['database']}",
                   $db['default']['username'],
                   $db['default']['password'],
                   array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8")
    );
}
catch (PDOException $e)
{
    print "Error!: " . $e -> getMessage() . "<br/>";
    die();
}

Funciones de apoyo del CMS.

Se crean algunas funciones básicas que servirán de soporte para el nuevo procedimiento de autenticación.

function existeUsuarioEnPlataforma($usuario)
{
    global $pdo;

    $stmt = $pdo -> prepare("SELECT id_usuario FROM `usuarios` WHERE user=?");

    $results = $stmt -> execute(array($usuario));

    return ($stmt -> rowCount() > 0);
}

Verifica si el usuario identificado por el nombre de usuario ($usuario) existe o no registrado en el CMS.  Retorna true o false según se encuentren o no efectivamente registrados.

function autenticarUsuarioEnPlataforma($usuario, $contrasena)
{
    global $pdo;

    $stmt = $pdo -> prepare("SELECT id_usuario FROM `usuarios` WHERE user=? AND pass=?");

    $results = $stmt -> execute(array($usuario, MD5($contrasena)));

    return ($stmt -> rowCount() > 0);
}

Verifica que el usuario identificado con el nombre de usuario ($usuario) tenga efectivamente a $contraseña como clave de usuario.  Retorna true en caso de coincidir, false de lo contrario.

Nótese como el CMS almacena sus contraseñas en MD5 motivo por el cual es necesario realizar esta conversión antes de realizar la comparación en la consulta SQL.

Funciones de apoyo de los foros.

De manera análoga, estas funciones facilitan la manipulación de la información en las tablas del sistema de foros, las cuales tienen configurado el prefijo foros_ en sus tablas.

function existeUsuarioEnForos($usuario)
{
    global $pdo;

    $stmt = $pdo -> prepare("SELECT ID_MEMBER FROM foros_members WHERE memberName = ?");

    $results = $stmt -> execute(array($usuario));

    if($stmt -> rowCount() == 0)
        return false;

    $fuente = $stmt -> fetch();

    return $fuente['ID_MEMBER'];
}

Verifica si el usuario identificado por el nombre de usuario ($usuario) existe o no registrado en el foro .  Retorna el identificador del usuario si existe o false de lo contrario.

function traerUsuario($usuario, $contrasena)
{
    global $pdo, $sourcedir, $modSettings;

    if(!existeUsuarioEnPlataforma($usuario))
        return false;

    $stmt = $pdo -> prepare("SELECT * FROM `usuarios` WHERE user=?");

    $results = $stmt -> execute(array($usuario));

    $fuente = $stmt -> fetch();

    require_once($sourcedir . '/Subs-Members.php');

    $regOptions = array('username' => $fuente['user'],
                        'password' => $contrasena,
                        'password_check' => $contrasena,
                        'email' => $fuente['email'],
                        'posts' => '0',
                        'ID_GROUP' => '0',
                        'ID_POST_GROUP' => '4');

    $memberID = registerMember($regOptions);

    return ($memberID > 0);
}

Obtiene la información del usuario de plataforma identificado por $usuario y $contrasena, y lo agrega en la base de datos del foro a través de su API interno.  A este nivel no se realiza ninguna verificación de autenticación.

function activarUsuarioForo($usuario, $estado='1')
{
    global $pdo;

    $stmt = $pdo -> prepare("UPDATE foros_members SET is_activated = ? WHERE memberName = ?");

    $control = $stmt -> execute(array($estado, $usuario));

    return $control;
}

Activa al usuario del foro recién creado, el cual por defecto siempre queda en espera de confirmación (is_activated = 3).

function actualizarContrasenaForo($usuario, $contrasena)
{
    global $pdo;

    $passwd       = sha1(strtolower($usuario) . $contrasena);
    $passwordSalt = substr(md5(mt_rand()), 0, 4);

    $stmt = $pdo -> prepare("UPDATE foros_members SET passwd = ?, passwordSalt = ? WHERE memberName = ?");

    $control = $stmt -> execute(array($passwd, $passwordSalt, $usuario));

    return $control;
}

Actualiza la $contrasena del $usuario en el sistema de foros.  Nótese como la $contrasena se recibe de manera plana y se almacena en la base de datos de SMF en SHA1.

Acerca del comportamiento del login de SMF.

Algo que se debe tener en cuenta acerca del comportamiento del login de SMF es que desde el cliente (navegador del usuario) se envía la contraseña ya en su propia representación SHA1 así que si la contraseña con que se va a comparar no está en la misma representación, como en este caso, el CMS la almacena en MD5, se tiene entonces un problema.

Para solventar esto, el sistema de foros permite solicitar nuevamente la contraseña al usuario (retry) y en este segundo intento la envía totalmente plana para su manipulación libre.  En este punto es donde la aprovechamos para verificar la autenticación del usuario contra la información del CMS, crear el usuario en el foro si no existe y actualizar la contraseña en el foro previniendo que haya sido actualizada antes en el CMS.

Implementación del nuevo proceso de autenticación.

function user_validate()
{
    $user = $_REQUEST['user'];
    $id   = 0;

    // Verificar un usuario proveniente de plataforma.

    if(existeUsuarioEnPlataforma($user))
    {
        $id = existeUsuarioEnForos($user);

        // Nueva lógica de autenticación.
    }

    // El usuario no existe en plataforma, verificar los nativos del foro.

    return false;
}

La base de la nueva autenticación es entonces la definición de la función user_validate que corresponde con la especificada inicialmente durante la configuración de los hooks.

En ella se verifica inicialmente si el usuario que intenta acceder al sistema (login) se encuentra presente o no en la base de datos de usuarios del CMS.  En caso de no estar presente el control de la autenticación se libera para que el sistema verifique sus usuarios propios, esto permite definir también usuarios internos del foro que no estén presentes en el CMS.

El paso siguiente consiste en determinar si el usuario existe previamente o no en el foro, es decir, no es su primer ingreso al mismo.  A partir de esta respuesta se toma uno de los siguientes caminos.

• Si no está disponible la contraseña plana (primer login) se solicita nuevamente (segundo login).
• Si el usuario no existe en el foro entonces ...
  • Se verifica que el nombre de usuario y la contraseña coincidan.
  • Se crea el usuario en el foro.
  • Se activa al nuevo usuario.
• Si el usuario ya existía previamente en el foro entonces ...
  • Se verifica que el nombre de usuario y la contraseña coincidan.
  • Se actualiza la contraseña en el foro por si ha sido actualizada previamente en el CMS.

La implementación de estas acciones se detalla a continuación.  En el caso en que el usuario no exista previamente en el foro se ejecuta la siguiente lógica del negocio.

if($id === false)
{
    // Esta disponible la contrasena (2do. login).

    if(isset($_REQUEST['passwrd']) && !empty($_REQUEST['passwrd']))
    {
        $auth = autenticarUsuarioEnPlataforma($user, $_REQUEST['passwrd']);

        if($auth)                           // La informacion del usuario es valida.
        {
            $id = traerUsuario($user, $_REQUEST['passwrd']);

            activarUsuarioForo($user);

            return false;                   // La autenticacion tiene EXITO.
        }
        else                                // La informacion del usuario NO es valida.
            return true;                    // La autenticacion FALLA.
    }
    else                                    // No esta disponible la contrasena (1er. login).
        return "retry";                     // Vuelva a solicitar el login para confirmar.
}

En el caso en que el usuario si exista previamente en el foro, el procedimiento es mas simple y se ejecuta la siguiente lógica del negocio.

// El usuario existe en el foro.

if($id !== false)
{
    // Esta disponible la contrasena (2do. login) -> actualizar la contraseña en el foro.

    if(isset($_REQUEST['passwrd']) && !empty($_REQUEST['passwrd']))
    {
        $auth = autenticarUsuarioEnPlataforma($user, $_REQUEST['passwrd']);

        if($auth)                           // La informacion del usuario es valida.
        {
            actualizarContrasenaForo($user, $_REQUEST['passwrd']);

            return false;                   // La autenticacion tiene EXITO.
        }
        else                                // La informacion del usuario NO es valida.
            return true;                    // La autenticacion FALLA.
    }
    else                                    // No esta disponible la contrasena (1er. login).
        return "retry";                     // Vuelva a solicitar el login para confirmar.
}

Conclusiones.

Hasta ahora, con poca experiencia en su uso, SMF parece ser un sistema de foros útil y práctico.  El proceso de determinar esta unificación de la autenticación fue largo y doloroso debido a la poca documentación que pude encontrar acerca del API, la cual en su mayor parte se encuentra diseminada en los foros de su sitio web.

En términos de su código parece tener un nivel decente de flexibilidad, el concepto de hooks permite realizar modificaciones interesantes al flujo normal del software, sin embargo es difícil formalizarlo al no contar con información suficiente de su lógica de funcionamiento.  Algunas partes del software, en especial los temas, adolecen de separación MVC por lo que se hace necesario editar funciones, entre comillas, que retornan el código HTML que se desea modificar siendo esto molesto, difícil y propenso a errores, sobretodo si se compara con tener archivos PHP separados con la lógica y HTML con la presentación como sería una mejor opción.

Finalmente, después de varios días de luchas y de pruebas, la unificación de la autenticación está funcionando y se ve bien, de todas maneras es mi primer acercamiento a este software por lo que no puedo garantizar que sea la mejor aproximación.  Como siempre, estoy abierto a sugerencias constructivas.

Enlaces.

• Simple Machines.
  http://www.simplemachines.org/
  • A guide to the SMF integration hooks.
    http://www.simplemachines.org/community/index.php?topic=173483.0
• CodeIgniter.
  http://codeigniter.com/

Estos se ubican entre el usuario y la aplicación.  Su función es la de controlar la comunicación entre los modelos y la vistas según la solicitud (requerimiento) que ha hecho usuario.

Su clase base es CController y en ellos se implementan Acciones (definen la lógica de la aplicación) y Filtros (establecen validaciones o controles antes y después de la ejecución de las acciones).

El usuario invoca indirectamente a los controladores especificando un ruta a través del controlador frontal o Application.

La ruta del requerimiento.

El URL solicitado determina que controlador y que acción se van a ejecutar para resolver el requerimiento del usuario.

Los URL tienen el siguiente formato.

Sin URL limpias (por defecto).

http://servidor/index.php?r=ControladorId/AcciónId

Con URL limpias.

http://servidor/ControladorId/AcciónId

Si se utilizan módulos (y URL limpias para este ejemplo).

http://servidor/MóduloId/ControladorId/AcciónId

• El archivo fuente del controlador se ubica en protected/controllers/ControladorIdController.php.
• El nombre de la clase allí contenida deberá ser ControladorIdController.
• Se invoca a la acción (ver mas adelante) AcciónId.  En caso de no haberse especificado una se considera la acción por defecto del controlador, comúnmente index.

Las acciones.

Pueden implementarse de dos maneras.

• Como métodos del mismo controlador.
• Como clases que heredan de CAction.

Acciones implementadas como métodos del controlador.

• El nombre del método deberá ser actionAcciónId.

En el siguiente ejemplo se muestra al controlador User que implementa la acción add como un método suyo.

class UserController extends CController
{
    public function actionAdd()
    {
        // Implementación ...
    }
}

Acciones implementadas como clases independientes.

• Los objetos acción heredan de CAction.
• El nombre de la clase es AcciónIdAction (por convención, no es obligatorio).
• Se almacena en un archivo bajo la ruta protected/controllers/controladorId/AcciónIdAction.php.
• Su ubicación puede referenciarse mediante alias de esta manera: application.controllers.controladorId.AcciónIdAction.
• Es obligatorio sobreescribir el método run() de la acción para definir allí su implementación.

En el siguiente código se muestra la acción remove del controlador User implementada como una clase independiente.

class RemoveAction extends CAction
{
    public function run()
    {
        // Implementación ...
    }
}

Esta clase se almacena entonces en el archivo protected/controllers/user/RemoveAction.php.

Como paso final de su implementación, es necesario indicarle al controlador de la existencia de la acción.  Para hacer esto es necesario sobreescribir el método actions del controlador de la siguiente manera.

class UserController extends CController
{
   public function actions()
   {
       return array(
           'remove' => 'application.controllers.user.RemoveAction'
       );
   }
}

Los filtros.

• Permiten realizar verificaciones y validaciones antes y después de la ejecución de las acciones.
• Una acción puede tener asociados múltiples filtros.
• Los filtros se ejecutan en el orden en que fueron especificados.
• Un filtro puede abortar la ejecución de los demás filtros y de la acción misma.
• De manera análoga a las acciones, los filtros pueden implementarse de dos maneras también.
  • Como métodos del mismo controlador.
  • Como clases que heredan de CFilter.

Filtros implementados como métodos del controlador.

• El nombre del método debe empezar por la palabra filter.
• Deberá recibir como parámetro a $filterChain.

En el siguiente ejemplo se muestra al controlador User que implementa al filtro checkUser como un método suyo.

class UserController extends CController
{
    public function filterCheckUser($filterChain)
    {
        // Implementación ... invocar $filterChain -> run()
        // para continuar con el próximo filtro
    }
}

Filtros implementados como clases independientes.

• Los objetos acción heredan de CFilter.
• El nombre de la clase es FiltroIdFilter (por convención, no es obligatorio).
• Se almacena en un archivo bajo la ruta protected/filters/FiltroIdFilter.php.
• Su ubicación puede referenciarse mediante alias de esta manera: application.filters.FiltroIdFilter.
• Es obligatorio sobreescribir los métodos preFilter($filterChain) y postFilter($filterChain) del filtro para definir que hacer antes y después de ejecutar la acción.

En el siguiente código se muestra al filtro isValid del controlador User implementado como una clase independiente.

class IsValidFilter extends CFilter
{
    public $admin;

    public function preFilter($filterChain)
    {
        // Se aplica antes de ejecutarse la acción.
        // Si retorna true continúa el proceso, false lo
        // aborta y no se ejecuta la acción solicitada.

        return $exito;
    }

    public function postFilter($filterChain)
    {
        // Se aplica después de ejecutarse la acción.
    }
}

Esta clase se almacena entonces en el archivo protected/filters/IsValidFilter.php.

Como paso final de su implementación, es necesario indicarle al controlador de la existencia del filtro y determinar su alcance sobre las acciones del mismo.  Para hacer esto es necesario sobreescribir el método filters del controlador de la siguiente manera.

class UserController extends CController
{
   public function filters()
   {
       return array(
           'checkUser + add, remove',

           array(
               'application.filters.IsValidFilter - add, remove',
               'admin' => false
           )
       );
   }
}

• checkUser es un filtro basado en un método del controlador.
• isValid es un filtro basado en una clase externa.
• Es posible especificar los filtros con una notación de arreglo para determinar valores específicos para los atributos del filtro.

Los operadores + y - actúan como determinadores del alcance de los filtros sobre las acciones especificadas de la siguiente manera.

• + determina exactamente a cuales acciones se les debe aplicar el filtro.  De esta manera, el filtro checkUser se aplicará a las acciones add y remove únicamente.
• - determina a cuales acciones NO se les debe aplicar el filtro.  Así, el filtro isValid se aplicará a todas las acciones EXCEPTO a add y remove.
• Si no se especifica ninguno de los dos modificadores, el filtro aplicará a todas las acciones del controlador.

Enlaces.

• Yii Documentation: controllers.
  http://www.yiiframework.com/doc/guide/basics.controller
• Yii PHP Framwork.
  http://www.yiiframework.com/

Algo que extrañamente no había notado hasta el día de hoy es que Wordpress reemplaza, a manera de característica y en total contra de mi voluntad, los guíones dobles (--) por simples (-) en el momento de generar la presentación de los artículos.  Esto es altamente incoveniente ya que ciertos comandos, especialmente de UNIX, requieren de opciones que inician con doble guión, como por ejemplo --help.

El método que encontré para evitar este problema no es probablemente el mas elegante de todos, sin embargo funciona muy bien.  Debe tenerse muy en cuenta en el momento de actualizar el núcleo de Wordpress ya que, al modificar un archivo de la distribución, probablmente deba aplicarse la modificación cada vez que se instale una nueva versión.

Procedimiento.

Edite el archivo responsable del formateo de los artículos.

$ vi wp-includes/formatting.php

Ubique las variables $static_characters y $static_replacements que se encuentran en las líneas 56 y 57 de la versión 2.9 de Wordpress (pueden variar en otras versiones).

$static_characters = array_merge(array('---', ' -- ', '--', ' - ', 'xn–', '...', '``', '\'s', '\'\'', ' (tm)'), $cockney);
$static_replacements = array_merge(array('—', ' — ', '–', ' – ', 'xn--', '…', $opening_quote, '’s', $closing_quote, ' ™'), $cockneyreplace);

Remueva o comente (mucho mejor) los primeros cinco elementos de cada uno de los arreglos.

$static_characters = array_merge(array(/* '---', ' -- ', '--', ' - ', 'xn–', */ '...', '``', '\'s', '\'\'', ' (tm)'), $cockney);
$static_replacements = array_merge(array(/* '—', ' — ', '–', ' – ', 'xn--', */ '…', $opening_quote, '’s', $closing_quote, ' ™'), $cockneyreplace);

Grabe el archivo.

Listo!

Estaba reutilizando un formulario complejo en un nuevo módulo de mi aplicación.  Todo iba bien hasta que descubrí que uno de los códigos Javascript que actualiza parte del formulario a través de AJAX no me era útil ya que debía mostrar una vista diferente a la estándar.   Como el código estaba escrito en funciones procedimentales no podía acceder a la sobreescritura de la orientación a objetos, sin embargo encontré un par de detalles interesantes de Javascript que me permitieron hacer algo similar.

Determinar existencia de funciones.

if(typeof miFuncion == 'function')
    // Si existe la función
else
    // No existe la función

El código anterior determina si la función miFuncion ha sido definida o no en el espacio de ejecución de la aplicación Javascript.

Redefinir una función.

window['miFuncion'] = function()
{
    // Nueva implementación de la función
};

El código anterior permite redefinir la implementación de la función miFuncion la cual obviamente fue especificada anteriormente.  Lo interesante de esta sintáxis de Javascript es que esta redefinición puede realizarse de manera dinámica, es decir, en un segundo archivo *.js que se cargue después del original o inclusive dentro de un condicional.

Chromium Browser (Chrome) es el navegador web de Google que desde hace un tiempo puede ser descargado y utilizado en la plataforma Windows.  Desafortunadamente aún no hay una versión (release) oficial para la plataforma Linux, sin embargo es posible instalarlo en Ubuntu mediante un PPA de frecuente actualización.

Instalación.

Agregar el repositorio.

$ sudo add-apt-repository ppa:chromium-daily/ppa

Instalar los paquetes.

$ sudo aptitude update

$ sudo aptitude install chromium-browser chromium-codecs-ffmpeg

Ejecución.

Ejecutar la aplicación desde el menú de programas a través de la siguiente ruta.

Applications > Internet > Chromium Web Browser.

O desde la línea de comando como se muestra a continuación.

$ /usr/bin/chromium-browser &

Enlaces.

• Instalación y puesta a punto de Chromium en GNU/Linux.
  http://bitelia.com/2009/11/instalacion-y-puesta-a-punto-de-chromium-en-gnulinux

No había podido probar la nueva interfaz de Google en Colombia ya que el procedimiento que circulaba por Internet aplicaba al dominio google.com y cuando intentaba acceder a él soy redirigido a google.com.co por lo cual la prueba no tenía efecto.  Por suerte ya encontré como superar esta situación y es en realidad muy sencillo.

Procedimiento.

Abra un navegador web.

Escriba el siguiente código en la barra de direcciones y presione Enter.

javascript:void(document.cookie=”PREF=ID=20b6e4c2f44943bb:U=4bf292d46faad806:TM=1249677602:LM=1257919388:S=odm0Ys-53ZueXfZG;path=/; domain=.google.com”);

Visite la página http://google.com/ncr.  Aparecerá la página de búsqueda con la nueva interfaz.

Realice cualquier búsqueda y podrá apreciar la nueva presentación de los resultados con una barra izquierda que facilita el acceso a los servicios de Google y algunos filtros para la información.

Para volver a la interfaz convencional es necesario remover la cookie del sitio.

De manera análoga a como hace poco había mostrado como manejar el evento de inicio y terminación de AJAX con jQuery para realizar algún tipo de acción específica como el mostrar un indicador de carga, ahora experimentaremos como hacerlo con el framework de Prototype el cual nuevamente estaré utilizando en el proyecto de los próximos meses.

Procedimiento.

Ajax.Responders.register({
    onCreate: function()
    {
        // An AJAX request has been initialized!
    }, 

    onComplete: function()
    {
        // An AJAX request has been completed!
    }
});

Adicionalmente hay otros eventos que pueden manejarse de igual manera onUninitialized, onLoading, onLoaded, onInteractive y onException, además de los ya mencionados onCreate y onComplete.

Enlaces.

• Prototype API - Ajax Responders.
  http://api.prototypejs.org/ajax/ajax/responders.html

Intentando recuperar mis neuronas que saben de Prototype para continuar por fin con uno de los proyectos que se encontraba en pausa permanente, el día de hoy me día a la breve tarea de recordar un poco la invocación asíncrona y la manipulación del DOM utilizando esta librería.  Para hacer una pequeña práctica decidí modificar el ejemplo de la calculadora que se basaba en jQuery y PHP para migrar su código de acuerdo con la especificación de Prototype.

Las modificaciones necesarias se centraron en la inclusión de la librería javascript en la página web (frontend) y en reescribir la invocación asíncrona de la aplicación web en PHP (backend).

Procedimiento.

Reemplazar la inclusión de la librería de jQuery por la de Prototype.  Para este caso se continúo utilizando el API de Google AJAX.

<script src="http://www.google.com/jsapi"></script>
<script>google.load("prototype", "1.6");</script>

Posteriormente se asoció el manejo del evento de presión del botón igual a la invocación de la función procesar, esto se realiza tan pronto como la estructura de la página (código HTML) se encuentra cargada completamente por el navegador.

/* Código a ejecutarse tan pronto como la
   página ha sido cargada por el navegador */

document.observe('dom:loaded', function()
{
    /* Asociar el evento de clic del botón 'igual'
       con la lógica del negocio de la aplicación */

    Event.observe('igual', 'click', procesar);
});

Finalmente se implementa la función procesar que realizará la invocación asíncrona del cálculo matemático.  Esta función consta de las siguientes partes.

1. Información básica del requerimiento.
2. Que hacer en caso de éxito.
3. Que hacer en caso de fracaso.

El requerimiento incluye la siguiente información básica de conexión.

• El URL de la aplicación remota a invocar (backend).
• El método HTTP a utilizar.
• Los parámetros de la página web a enviarse.

function procesar()
{
    new Ajax.Request('calcular.php',                                         /* URL a invocar asíncronamente */
    {
        method:       'post',                                                /* Método utilizado para el requerimiento */
        parameters:   $('formulario').serialize(true),                       /* Información local a enviarse con el requerimiento */

En caso de que la invocación asíncrona tenga un resultado exitoso se deberán realizar los siguientes pasos.

• Mostrar un mensaje de éxito en color verde.
• Desplegar el valor del resultado obtenido en el campo definido para tal fin.

        /* Que hacer en caso de ser exitoso el requerimiento */

        onSuccess: function(transport)
        {
            /* Cambiar el color del texto a verde */

            $('mensaje').setStyle('color: #0ab53a');

            /* Mostrar un mensaje informando el éxito sucedido */

            $('mensaje').update("Operación realizada exitosamente");

            /* Mostrar el resultado obtenido del cálculo solicitado */

            $('resultado').update(transport.responseText);
        },

En caso de que fracase el proceso de invocación asíncrona se deberán realizar los siguientes pasos análogos.

• Mostrar el mensaje de error proveniente del servidor, en color rojo.
• Limpiar cualquier resultado previo para evitar confusiones con la operación.

        /* Que hacer en caso de que sea fallido el requerimiento */

        onFailure: function(transport)
        {
            /* Cambiar el color del texto a rojo */

            $('mensaje').setStyle('color: #ff0e0e');

            /* Mostrar el mensaje de error */

            $('mensaje').update('Error: ' + transport.responseText);

            /* Limpiar cualquier resultado anterior */

            $('resultado').update('Error');
        }
    });
}

Enlaces.

• Demostración & descarga del código fuente.
  http://demo.jorgeivanmeza.com/Prototype/AjaxSimpleRapido-Calc/
• Prototype Javascript Framework.
  http://prototypejs.org/
• Prototype Introduction to Ajax.
  http://www.prototypejs.org/learn/introduction-to-ajax
• Prototype's AJAX Request API.
  http://api.prototypejs.org/ajax/ajax/request.html
• Prototype's Element API.
  http://api.prototypejs.org/dom/element.html
• Ejemplo de AJAX rápido y simple con PHP y jQuery.
  http://blog.jorgeivanmeza.com/2009/10/ejemplo-de-ajax-rapido-y-simple-con-php-y-jquery/