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/

En algunos casos puede ser útil obtener desde un fragmento de código PHP utilizando el API oficial, los nodos de un portal basado en Drupal 6 que correspondan con un tipo específico (file, story, event, page, ...).  Esto se puede hacer fácilmente de la siguiente manera.

Procedimiento.

Obtener el listado con la información general de los nodos del tipo específico.  Para esto se consulta la tabla node que contiene la siguiente información de los nodos.

nid         int(10)           # ID del nodo.
vid         int(10)           # ID de la versión del nodo.
type        varchar(32)       # Tipo del nodo.
title       varchar(255)      # Título.
uid         int(11)           # ID del propietario.
status      int(11)           # Estado (publicado = 1; sin publicar/oculto = 0)
created     int(11)           # Timestamp de la creación del nodo.
changed     int(11)           # Timestamp de la modificación del nodo.
comment     int(11)           # Estado de comentarios (desactivados = 0; sólo lectura = 1; activados = 2).
promote     int(11)           # Promocionado a la página principal (no = 0; si = 1).
moderate    int(11)           # Moderado (no = 0; si = 1).
sticky      int(11)           # Pegajoso (no = 0; si = 1).
language    varchar(12)       # Código del idioma.
tnid        int(10)
translate   int(11)

La consulta básica se puede realizar de la siguiente manera.

$sql = "SELECT nid
        FROM {node}
        WHERE type = 'TIPO_DE_NODO' AND
              status = 1
        ORDER BY created DESC";
$results = db_query($sql);

Posteriormente se iteran los resultados obtenidos de la consulta y se carga la información completa de cada uno de los nodos.

while ($result = db_fetch_object($results))
{
    $node = node_load($result -> nid);
}

El contenido del nodo recuperado dependerá en cierta medida de los módulos instalados que alteran su estructura.  Para mostrar por ejemplo el título, la fecha de creación, el mensaje y la fecha de modificación de una noticia se utiliza el siguiente fragmento.

echo 'Titulo: ' . $node -> title . '<br />';
echo 'Fecha: ' . format_date($node->created) . '<br />';
echo 'Mensaje: ' . $node->body . '<br /><br /><hr /><br />';
echo 'changed on: ' . format_date($node->changed, 'custom', 'Y-m-d H:i:s O') . '<br />';

Enlaces.

• Headless Drupal: Using Drupal’s API to Batch Script Your Drupal Site.
  http://www.stonemind.net/blog/2009/01/20/headless-drupal-using-drupals-api-to-batch-script-your-drupal-site/

Los siguientes módulos requieren que los idiomas del sitio se encuentren definidos (?q=admin/settings/language) y que el Language Negotiation (?q=admin/settings/language/configure) deba ser Path prefix only o Path prefix with language fall-back.

• Language Interface
  http://drupal.org/project/languageinterface
• Active Translation
  http://drupal.org/project/active_translation
• Translation overview
  http://drupal.org/project/translation_overview
• Internationalization
  http://drupal.org/project/i18n

Editar el archivo template.php y agregar la siguiente función (el nombre es libre).

function phptemplate_generarFormularioLogin()
{
   $form_id = 'user_login';
   $form = array();
   $form['name'] = array(
      '#type' => 'textfield',
      '#maxlength' => USERNAME_MAX_LENGTH,
      '#required' => TRUE,
      '#attributes' => array('tabindex' => '1',
      'class' => 'registro'),
   );
   $form['pass'] = array(
      '#type' => 'password',
      '#required' => TRUE,
      '#attributes' => array('tabindex' => '2',
      'class' => 'registro'),
   );
   $form['submit'] = array(
      '#type' => 'submit',
      '#value' => t('Log in'),
      '#weight' => 2,
      '#attributes' => array('tabindex' => '3')
   );
   $form['#validate'] = user_login_default_validators();
   $form['#build_id'] = sprintf('form-%s', md5(uniqid(mt_rand(), TRUE)));
   $form_state = array();
   drupal_prepare_form($form_id, $form, $form_state);
   drupal_process_form($form_id, $form, $form_state);
   $out = new stdClass;
   $out->form_start = sprintf("<form method='post' accept-charset='UTF-8' action='%s'>",
                             url('user/login'));
   $out->form_end = "</form>";
   $out->name = drupal_render($form['name']);
   $out->pass = drupal_render($form['pass']);
   $out->submit = drupal_render($form['form_id']) .
   drupal_render($form['form_build_id']) .
   drupal_render($form['submit']);
   return $out;
}

Insertar en el lugar deseado de page.tpl.php el siguiente fragmento de código o su correspondiente personalización.

<?php $login_form = phptemplate_generarFormularioLogin(); ?>
<?php print $login_form -> form_start; ?>
    Usuario &nbsp; <?php print $login_form->name; ?> &nbsp;&nbsp;&nbsp;
    Contraseña &nbsp; <?php print $login_form->pass; ?>&nbsp;&nbsp;
    <?php print $login_form->submit; ?>
<?php print $login_form->form_end; ?>

Enlaces.

• Theming the Drupal 6 User Login Form.
  http://thefaultandfracture.blogspot.com/2009/04/theming-drupal-user-login-form.html
• Customizing the login form.
  http://drupal.org/node/19855
• Modifying Forms in Drupal 5 and 6.
  http://www.lullabot.com/articles/modifying-forms-5-and-6
• 10 tips for theming Drupal 6 forms.
  http://www.advomatic.com/blogs/amanda-luker/10-tips-theming-drupal-6-forms

En algunas ocasiones no es suficiente con el bloque de búsquedas de Drupal y es necesario incluír un formulario de búsquedas en la plantilla del tema con un estilo muy específico.

Las búsquedas en Drupal utilizan un sistema de llaves o claves para impedir que sean consumidas desde fuera del sitio, así que escribir un formulario propio con el action direccionado no es una buena alternativa.

Implementación.

1. Activar el formulario de búsquedas en el tema.
   1. Acceda el menú de administración de temas (?q=admin/build/themes).
   2. Haga clic sobre el enlace Configurar frente al tema elegido.
   3. Seleccione la casilla Bloque de búsqueda.
   4. Presione el botón Guardar configuración.
2. Copie el archivo modules/search/search-block-form.tpl.php a la carpeta del tema con el nombre search-theme-form.tpl.php.
3. Edite page.tpl.php del tema e incluya la etiqueta <?php print $search_box; ?> donde desee que aparezca el campo de búsqueda en el tema.
4. Edite el archivo search-theme-form.tpl.php con el formulario de búsqueda personalizado.
   1. No es necesario incluír las etiquetas <form> ya que estas se incluyen automáticamente.
   2. El ID del formulario generado es search-theme-form.
   3. El ID del campo de las palabras clave deberá ser edit-search-theme-form-1.
   4. El nombre del campo de las palabras clave deberá ser search_theme_form.
   5. Incluya esta etiqueta en cualquier lugar del archivo <?= $search['hidden']; ?>.

Enlaces.

• Customizing the search forms.
  http://drupal.org/node/45295

Las regiones en Drupal permiten la ubicación de los bloques en la página.  Su distribución se realiza generalmente en el archivo page.tpl.php del tema.

Por defecto se incluyen las siguientes regiones.

1. Columna izquierda (left).
2. Columna derecha (right).
3. Contenido central (content).
4. Cabecera (header).
5. Pies de página (footer).

Agregar nuevas regiones al tema.

Es posible según la complejidad del tema que sea necesario agregar nuevas regiones para manipular la distribución del contenido del sitio con mayor precisión y granularidad.

Hasta la versión 5 de Drupal esto se realizaba sobreescribiendo la función phptemplate_regions() del archivo template.php, sin embargo este estilo de configuración fue modificado para las versiones 6 y posteriores.

Ahora la configuración de las regiones se realiza en el archivo TEMA.info de la siguiente manera.

regions[left] = Columna izquierda
regions[right] = Columna derecha
regions[content] = Contenido
regions[header] = Cabecera
regions[footer] = Pies de pagina
regions[menu] = Menu horizontal

Enlaces.

• Regiones, estructura del archivo .info.
  http://drupal.org/node/171205#regions
• Crear nuevas secciones en page.tpl de Drupal.
  http://blog.jorgeivanmeza.com/2007/08/crear-nuevas-secciones-en-pagetpl-de-drupal/

Esto se realiza gracias al objeto $user disponible durante la generación de las vistas de la siguiente manera.

global $user;
if($user -> uid)
{
    // El usuario se encuentra autenticado y en sesión.
}
else
{
    // El visitante del portal es anónimo.
}

Las “migas de pan” o breadcrumbs es aquella sección de los sitios web que lleva un registro jerárquico de los niveles del sitio que se han visitado permiténdonos regresar a través de ellos de manera asíncrona.  Un ejemplo de breadcrumbs podría ser este.

Inicio > Software > Web.

Esto significaría que se está en la sección Web que depende del Software y que pende del inicio del sitio.

Breadcrumbs en Drupal.

Drupal provee automáticamente esta facilidad, él mismo va generando las “migas de pan” y las ubica donde se inserte la siguiente etiqueta, comúnmente en page.tpl.php.

<?php print $breadcrumb ?>

Por defecto Drupal se hace cargo de generar el contenido HTML asociado a las “migas de pan” con un estilo por defecto.  En algunas ocasiones este estilo no se adecúa a las necesidades propias.

Personalizar las breadcrumbs en Drupal.

Para hacer esto es necesario crear o editar el archivo template.php ubicado en el tema activo y agregar o modificar la definición de la función phptemplate_breadcrumb($breadcrumb) donde $breadcrumb es un arreglo y cada una de sus celdas corresponde con un segmento de las “migas de pan”.

/**
 * Return a themed breadcrumb trail.
 *
 * @param $breadcrumb - An array containing the breadcrumb links.
 * @return a string containing the breadcrumb output.
 */
function phptemplate_breadcrumb($breadcrumb)
{
    if (empty($breadcrumb))
        return "";
    $str = "<ul>";
    $length = count($breadcrumb);
    for($i=0; $i<$length; $i++)
    {
        $bc = $breadcrumb[$i];
        $class = ($i < $length - 1) ? "" : "class='ruta_final'";
        $str .= "<li {$class}>{$bc}</li>";
    }
    $str .= "</ul>";
    return $str;
 }

El ejemplo anterior crea las “migas de pan” como un UL donde cada LI corresponde con una sección visitada y cuya última sección tiene además una clase CSS llamada ruta_final.

Cuando se desarrolla un tema la mayoría de las imágenes quedan relacionadas a través de las hojas de estilos (CSS) sus rutas son relativas automáticamente al directorio del tema y se incluyen, al igual que los archivos Javascript, en el archivo *.info del tema.

; $Id: dm.info,v 0.1 2009/08/11 11:11:00 jimezam Exp $
name = miTema
description = Esta es la descripción del tema.
version = 1.0
core = 6.x
engine = phptemplate

stylesheets[all][] = css/style.css
stylesheets[all][] = css/layout.css

scripts[] = js/jquery-1.3.2.min.js

El ejemplo anterior hace que miTema incluya automáticamente las hojas de estilo style.css y layout.css ubicadas bajo css/ y el archivo jquery-1.3.2.min.js ubicado bajo js/.  Esto se hace exactamente donde se inserten las siguientes etiquetas, normalmente ubicadas en el <head> de page.tpl.php.

<?php print $styles; ?>
<?php print $scripts; ?>

Imágenes estáticas directamente del tema.

En otras ocasiones es necesario referenciar imágenes (<img>) u otros recursos estáticos que se encuentran ubicados en el directorio del tema activo.  Para hacer esto se utiliza el método path_to_theme del API de Drupal.

Supongamos que se desea crear una imagen con el archivo Foto.png que se encuentra ubicado en el directorio imagenes/ del tema activo.  Se debe utilizar la siguiente expresión.

<img src="<?php global $base_path; print $base_path.path_to_theme(); ?>/imagenes/Foto.png" />

Otra forma de hacerlo, con una sintaxis un poco mas resumida es utilizando las funciones directas que provee Drupal de la siguiente manera.

<img src="<?php print base_path() . path_to_theme(); ?>/imagenes/Foto.png" />

Solución de problemas.

A pesar de que no se encuentren activos los cachés de Drupal, algunas veces los cambios que se realizan en estos archivos de presentación no se reflejan cuando se refresca el sitio.  Para corregir este comportamiento es necesario limpiar el caché de datos del tema para que se generen nuevas versiones que incluyan los cambios recién realizados.

Para limpiar el caché de datos de Drupal inicie como administrador y acceda a la configuración de desempeño (?q=admin/settings/performance).

Al final de la página presione el botón Clear cached data y al terminar esta página refresque nuevamente el sitio web para observbar los cambios.

Después de actualizada la versión 5 del portal a la 6.12 o la instalación de una versión 6.x fresca, se hace necesario actualizar el portal a la nueva versión disponible, la 6.13.

Procedimiento.

1. Realizar la copia de seguridad de la base de datos del portal.
2. Ingresar al portal con el usuario cuyo id = 1.
3. Modificar  la configuración del sitio poniéndolo en modo administración: ?q=admin/settings/site-maintenance.
4. Actualizar los módulos disponibles según el módulo de update-status: ?q=admin/reports/updates.
5. Desactivar los módulos (?q=admin/build/modules) y temas (?q=admin/build/themes) de terceros.
6. Realizar la actualización de los archivos.
   1. $ wget http://ftp.drupal.org/files/projects/drupal-6.13.tar.gz
   2. $ rm site.old
   3. $ mv site site.old
   4. $ tar zxvf drupal-6.13.tar.gz
   5. $ mv drupal-6.13/ site
   6. $ cp -rf site.old/files site    (si no se utiliza la convención bajo sites/default).
      
   7. $ cp -rf site.old/sites site
   8. (web) $URL/apps/site/update.php
   9. (web) $URL/?q=admin/reports/updates
   10. rm site/install.php site/CHANGELOG.txt site/INSTALL.txt site/INSTALL.mysql.txt site/INSTALL.pgsql.txt site/LICENSE.txt site/MAINTAINERS.txt site/UPGRADE.txt
   11. $ rm drupal-6.13.tar.gz
7. Activar los módulos (?q=admin/build/modules) y temas (?q=admin/build/themes) de terceros.
8. Modificar  la configuración del sitio poniéndolo en línea nuevamente: ?q=admin/settings/site-maintenance.

Con esta actualización se introducen las siguientes modificaciones al esquema de actualizaciones de Drupal que se había estado siguiendo hasta la fecha.

• Los archivos del usuario, diferentes a los de la distribución de Drupal, y a los cuales se les debe realizar copia de seguridad se encuentran en las siguientes ubicaciones.
  • sites/all/libraries.  Librerías que aplican a todos los sitios.
  • sites/all/modules.  Módulos de terceros que aplican a todos los sitios.
  • sites/all/themes.  Temas de terceros que aplican a todos los sitios.
  • sites/default/files.  Archivos de usuario de un sitio específico (default).
  • sites/default/settings.php.  Configuración de un sitio específico (default).
• Si no se utiliza la convención bajo sites los directorios libraries, modules, themes y files se ubicarán en el directorio raíz de la distribución de Drupal, esto debe tenerse muy en cuenta ya que deberán agregarse como pasos durante la copia de seguridad y deberá tenerse extremo cuidado para evitar conflictos con los archivos del núcleo de la distribución que utilizan la mayoría de estos directorios.

Enlaces.

• HowTo: Updating Drupal 6.x to newer minor version.
  http://drupal.org/node/390448
• Upgrading - more sophisticated approach.
  http://drupal.org/node/323089
• Setup of /sites directory for multi-site.
  http://drupal.org/node/53705