Si todavía crees que usar FeedBurner es una buena idea (yo nunca lo tuve claro) la forma más cómoda de configurarlo es modificando el archivo .htaccess, aunque también existen plugins específicos (por ejemplo el FD Feedburner Plugin).

Se trata de añadir lo siguiente al .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} !FeedBurner [NC]
RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
RewriteRule ^feed/(.*)$ http://feeds2.feedburner.com/xxxxxx [R,L]
</IfModule>

Con lo anterior conseguimos que nuestro WordPress únicamente genere el feed para FeedBurner y que el resto de clientes (navegadores, arañas, etc.) sean redirigidos a la URL de FeedBurner.

Teóricamente este es el mejor método para usar FeedBurner ya que seguimos difundiendo la URL del feed original y así siempre podemos dejar de usar este servicio sin muchos inconvenientes. El problema está en que al haber la redirección muchos usuarios siguen el enlace del feed con el navegador y se suscriben a la URL del feed de FeedBurner… o sea que con el tiempo acabaremos con lectores suscritos a ambas URLs.

El método alternativo es modificar el theme de WordPress, o usar algún plugin, para difundir directamente la URL del feed de FeedBurner.

Proxy de Google

Si teníamos una cuenta en FeedBurner y la hemos migrado a Google recientemente, a parte del engorroso cambio de la URL del feed, quizás hemos notado que ahora la URL que difunde tu feed para cada post pasa por un proxy de Google.

En principio esto ya sucedía antes y el cambio únicamente es que ahora en lugar de pasar por feeds.feedburner.com pasa por feedproxy.google.com (aunque en mi caso antes de migrar la cuenta a Google no pasaba por ningún proxy, tengo caché, lo puedo demostrar :)

En cualquier caso si queremos desactivar completamente el proxy de Google hemos de cambiar la configuración de nuestro feed en FeedBurner. Concretamente se trata de desactivar la opción “Item link clicks” de la sección “TotalStats” dentro de la pestaña “Analize”. Con esto seguiremos teniendo estadísticas de número de lectores e ítems vistos (información más que suficiente) pero difundiremos siempre la URL original de cada post, algo muy recomendable para SEO (como bien nos explicaba Armonth hace tiempo).

Así es como debería quedar la configuración en FeedBurner:

Entradas relacionadas:

• Usando mod_rewrite y FeedBurner para las feeds de un blog con WordPress
• Actualizar un WordPress a la última versión
• Internacionalización de temas en WordPress usando gettext

Aunque a simple vista el método __toString() pueda parecer poco importante en PHP éste toma mucha relevancia si trabajamos con symfony o algún otro framework orientado a objetos donde la información de la base datos se encuentra mapeada en un modelo de objetos.

A pesar de que __toString() está disponible desde la versión 5.0.0 del PHP en mi opinión no empieza a ser realmente útil hasta la versión 5.2.0, algo que en el changelog del PHP reflejaron con un tímido:

Changed __toString() to be called wherever applicable. (Marcus)

Hasta entonces __toString() sólo se llamaba cuando se usaba echo() o print() lo que limitaba mucho su funcionalidad. Desde la versión 5.2.0 __toString() se llama siempre que tratemos a un objeto como a un string.

Por ejemplo dada la siguiente definición de clase:

Hasta PHP 5.2.0 sólo podíamos invocar a __toString() con:

Desde la versión 5.2.0 podemos hacer varias cosas interesantes con __toString() sobretodo relacionadas con el manejo de arrays de objetos, algo muy frecuente en los frameworks que corren por ahí hoy en día.

Por ejemplo si obtenemos el típico array de objetos con symfony:

Trabajando directamente con las funciones de PHP entre otras muchas cosas podemos:

• Ordenar el array de objetos con un simple sort()
• Eliminar objetos duplicados del array con un array_unique()
• Generar una lista separada por comas para la presentación con un implode()
• Buscar un objeto determinado dentro del array con array_search()

Alternativas a __toString()

Si no tenemos la suerte de trabajar con PHP 5.2.x, o si queremos poder trabajar con un método distinto de __toString() para determinadas operaciones con arrays de objetos, podemos usar un código parecido al que propongo a continuación:

Lo anterior es más una propuesta de código que algo decente para ser distribuido. Simplemente se trata de trabajar con un array temporal para almacenar los valores del método solicitado, correr la función PHP y, si es necesario, volver a construir el array de objetos.

Algunos ejemplos de uso:

Fácilmente se pueden añadir tantos métodos de tratamiento de arrays como se necesiten... o mucho mejor hacer un método que simplemente reciba como variable la función PHP a ejecutar. En mi caso de momento sólo necesito estos en concreto y también así los puedo controlar individualmente.

Aunque estos métodos de objectTools nacieron como "parche" rápido dado que no tenía PHP 5.2.x para un proyecto symfony, ahora, una vez solventando el problema con los servidores, los sigo encontrando útiles en múltiples situaciones. Por supuesto se ha de tener presente el poco rendimiento de este código frente a realizar queries a medida usando el objeto Criteria, pero si ya tenemos un array de objetos en memoria sí que será más óptimo trabajar con él en lugar de lanzar varias queries contra la base de datos.

Entradas relacionadas:

• Un error handler que lance exceptions en PHP
• URLs limpias y amigables con PHP y Apache
• Carga automática de clases en PHP con autoload

Una de las funciones que para mi resulta más útil del SSH a parte de lo evidente que es poder iniciar sesión en nuestro servidor, es poder ejecutar comandos remotamente y así fácilmente poder escribir scripts (PHP y/o de shell) que interactúen entre máquinas. Por ejemplo para subir la última release de nuestra web a producción, borrar cachés de disco, reiniciar algún que otro Apache que se ha quedado tonto, etc.

Algo que resulta muy útil en estos casos es poder usar SSH entre distintas máquinas sin necesidad de ir introduciendo la contraseña. Para conseguirlo, y entendiendo bien el riesgo de seguridad que puede suponer, hemos de seguir los siguientes pasos:

[1] Iniciamos sesión en el servidor A con el usuario que queremos dejar libre de contraseña y ejecutamos:

$ ssh-keygen -t rsa

[2] Añadimos la clave publica generada (.ssh/id_rsa.pub) al archivo de claves aceptadas del servidor B, por ejemplo vía SCP:

$ scp .ssh/id_rsa.pub usuario@B:.ssh/authorized_keys

Se ha de tener en cuenta que el anterior comando sobreescribe el archivo y podemos tener más de una clave aceptada en authorized_keys.

[3] Listos! Desde el servidor A ya podemos entrar en B sin contraseña. Si estamos logueados con el usuario correcto sólo será necesario ejecutar:

$ ssh B

Al programar en PHP por supuesto que siempre tienes la alternativa de realizarlo todo vía peticiones HTTP aunque para determinadas tareas y situaciones los scripts CLI son una gran alternativa (y los puedes hacer muy chulos usando ncurses).

Entradas relacionadas:

• Instalar clases PEAR en un hosting compartido
• HostGator, un servicio de hosting con acceso SSH y soporte de PHP5
• Instalación del APC (Alternative PHP Cache) sobre FreeBSD

Si nuestra intención es hacer borrón y cuenta nueva con nuestro blog eliminando todos los archivos pero conservando la base de datos los pasos a seguir son los siguientes:

[1] Como siempre antes de empezar cualquier tarea parecida backup de todo. Incluso es buena idea montar el blog entero en otro sitio para después poder comparar el viejo con el nuevo.

[2] Desactivamos todos los plugins y seleccionamos el tema por defecto. Aunque en nuestro caso como tenemos intención de borrar todos los archivos el nuevo WordPress desactivará todo lo que no encuentre.

[3] Borramos todos los archivos anteriores. Si tenemos el wordpress mezclado con otras cosas el comando en cuestión es algo como:

$ rm -rf index.php license.txt readme.html wp-* xmlrpc.php

[4] Descomprimimos la última versión de WordPress en el mismo sitio donde teníamos la anterior.

[5] Editamos el nuevo wp-config.php y añadimos los datos de conexión y nombre de la BD.

[6] Comprobamos en qué codificación está trabajando nuestro WordPress. Por ejemplo con:

mysql> show create table wp_posts;

Nos fijamos en el CHARSET utilizado y definimos DB_CHARSET con el mismo valor. En el caso de ser "utf8" no tenemos que tocar nada pero si estamos con "latin1" es necesario indicarlo en wp-config.php con:

[7] Iniciamos el programa de actualización apuntando el navegador a la URL habitual del dashborad (p.e. http://tublog.es/wp-admin/)

[8] Automáticamente aparecerá un mensaje diciendo que debemos proceder con la actualización de la BD. Hacemos clic en "Siguiente" y cruzamos los dedos... si todo va bien te aparecerá algo como "Update successful".

[9] WordPress casi actualizado!

Digo casi porque casi seguro vamos a necesitar realizar alguno de lo siguientes pasos adicionales:

• Si habíamos subido archivos al WordPress utilizando su dashboard hemos de copiar la anterior carpeta wp-content/uploads a la nueva instalación.
• Si trabajábamos con algún plugin para los tags debemos lanzar la importación manualmente desde el dashboard, por ejemplo en el caso del UTW desde "Herramientas" -> "Importar" -> "Ultimate Tag Warrior".
• Si ha pasado mucho tiempo desde la última actualización no es mala idea repasarse las opciones de configuración de WordPress y comprobar que todo está ok, especialmente la sección de Permalinks.
• Como hemos empezado de nuevo en lo que a código PHP se refiere es necesario volver a instalar los plugins que echemos en falta y un tema que nos guste. Por supuesto descargando las últimas versiones de todo y no aprovechando nada del anterior WP para así sacar el máximo partido de las nuevas funcionalidades (en parte uno de los objetivos del procedimiento descrito en este post).

Entradas relacionadas:

• Internacionalización de temas en WordPress usando gettext
• Títulos un poco más SEO y en español para WordPress
• WordPress con el FeedBurner de Google y su maldito proxy

Una de las principales diferencias de HTML Purifier comparada con otras librerías de filtrado HTML es que descompone por completo el HTML y verifica que cada uno de los elementos se encuentre dentro de una whitelist de elementos permitidos en lugar de limitarse a buscar elementos prohibidos en una blacklist (normalmente desfasada). A la vez que elimina el código no deseado también hace algo poco común en librerías de este tipo, valida que el HTML cumpla el estándar correspondiente y si no lo cumple realiza las modificaciones necesarias para corregirlo.

Puedes usar HTML Purifier tanto para filtrar datos de entrada, en el caso de que sea posible recibir código HTML, como el HTML de salida de tu aplicación. Lo más frecuente es usarla para filtrar datos de entrada como comentarios, emails, el resultado de algunos editores WYSIWYG, etc.

Se ha de tener presente que dado su funcionamiento interno es una librería muy potente pero pesada y lenta, no es para nada recomendable filtrar la salida de tu aplicación cada vez que generas código HTML. Mucho mejor filtrar la entrada y asegurar que el contenido de tu sistema está limpio. En todo caso para filtrar la salida se convierte en algo obligatorio trabajar con algún sistema de cache (generar páginas estáticas, un reverse proxy, en BD capturando el output-buffer, etc.)

A continuación explico brevemente su instalación y uso.

Instalación

[1] Descargar el archivo htmlpurifier-3.0.0.tar.gz y descomprimirlo en el servidor. No es necesario que esté accesible para los usuarios, puedes colocarlo fuera del DocumentRoot. Ten en cuenta que la última versión (la 3.0) sólo es compatible con PHP5.

[2] Poner los permisos adecuados a los directorios que HTML Purifier usará para cachear algunos archivos. Los directorios en cuestión son DefinitionCache/Serializer y todos sus subdirectorios. Si tenemos acceso por shell al servidor lo solucionamos con un:

chmod -R 0777 HTMLPurifier/DefinitionCache/Serializer

Utiliza 0777 o 0775 según convenga, el objetivo es permitir al servidor web escribir en estos directorios.

[3] Es necesario tener instalada la extensión iconv si quieres trabajar con un enconding distinto de UTF-8 y si quieres una salida más bonita del HTML también es necesaria la extensión tidy.

[4] Para mayor comodidad puedes incluir el directorio de la HTML Purifier en tu include_path a pesar de que es recomendable sólo hacer require() cuando vayas a usarla, es una librería bastante grande.

Usando la librería

En el ejemplo se incluye el archivo HTMLPurifier.auto.php indicando la ruta completa, si has añadido el directorio de la librería en tu include_path puedes incluir HTMLPurifier.php directamente (usa la línea comentada).

En este ejemplo simple se está configurando HTML Purifier para que trabaje con 'HTML 4.01 Transitional' codificado en 'ISO-8859-1'. Por defecto la librería trabaja con 'XHTML 1.0 Transitional' en 'UTF-8', si este es el único tipo de documento y codificación que necesitas puedes eliminar las llamadas a set() y no es necesario crear el objeto $config. Existen muchos otros parámetros de configuración que se merecen una ojeada aunque para un funcionamiento normal no es necesario tocar casi nada.

También existen plugins para varios CMS conocidos para empezar a usar HTML Purifier de una forma todavía más fácil. Entre ellos está el plugin HTML Purified para WordPress y el módulo HTML Purifier para Drupal.

Entradas relacionadas:

• Capturando los fatal errors del PHP con nuestro handler
• El mes de los bugs y nueva versión de PHP
• Transfiriendo datos con la librería cURL en PHP

Acerca de este tema existe mucha documentación y en el apartado correspondiente del manual puedes encontrar varias alternativas. Después de haber trabajado con varias wikis en estos últimos años la que encuentro mejor es la siguiente.

Modificar LocalSettings.php

Se debe sustituir el valor de la variable $wgArticlePath por:

y si no tienes definida esta variable se debe añadir en un lugar cercano a la definición de $wgScriptPath.

Modificar .htaccess

Añadir las siguientes lineas a tu .htaccess:

RewriteEngine On
RewriteBase /
RewriteRule ^$ http://www.ejemplo.com/Portada [R=301,L]
RewriteRule ^[^:]*\. - [L]
RewriteRule ^[^:]*\/ - [L]
RewriteRule ^(.+)$ /mediawiki/index.php?title=$1 [L,QSA]

Las URLs resultantes tienen la forma:

http://www.ejemplo.com/Portada para la Home.
http://www.ejemplo.com/Prueba para una página llamada "Prueba".

Consideraciones

Este método funciona correctamente en distintos escenarios aunque se han de tener en cuenta algunas consideraciones:

[1] La wiki debe estar instalada en el directorio "mediawiki". Si la tienes en otro directorio sustituye "mediawiki" por el nombre apropiado en las anteriores reglas de mod_rewrite.

[2] Si alguien accede a la raíz del dominio es redirigido a "/Portada" con una redirección permanente (301).

[3] Si el nombre de tu wiki contiene un punto (p.e. Ejemplo.com) fallarán los accesos a algunas páginas especiales. Para forzar que las páginas especiales que usan el nombre de la wiki en la URL se procesen correctamente es necesario añadir la siguiente regla justo después de la redirección a la Portada:

RewriteRule ^Ejemplo\.com(.+)$ /mediawiki/index.php?title=Ejemplo.com$1 [L,QSA]

Entradas relacionadas:

• Usando mod_rewrite y FeedBurner para las feeds de un blog con WordPress
• URLs limpias y amigables con PHP y Apache
• Como interactuar con Google desde PHP usando Zend Framework

Actualmente podríamos decir que es una cuestión de gustos usar o no la WWW para nuestras URL, te encuentras con partidarios del NO, como la iniciativa no-www.org, y otros que exponen interesantes motivos de porque SÍ, como en HM2K.

Lo que sí es recomendable para SEO, y en mi opinión también para temas de Marketing, es decidirse por con o sin WWW y sólo usar un formato de URL. Siempre deberíamos difundir nuestra URL de la misma forma: en los enlaces de nuestra web, en enlaces de otras webs (las que podamos controlar), en anuncios en prensa e inet, etc. También se debería redirigir el tráfico que llega por el formato no deseado al bueno.

El comportamiento por defecto de muchos servidores de servir el mismo contenido en una URL con o sin WWW sin usar ninguna redirección es un error para SEO ya que crea contenido duplicado. Lo usual es que los buscadores interpreten las URL con o sin WWW como sitios web distintos.

Personalmente también encuentro importante la unificación del formato de las URL de cara a la comunicación, imagen de marca, difusión de contenidos, etc. Normalmente uno de nuestros objetivos es que los usuarios recuerden nuestra URL, ahora hablar con WWW ahora sin, no ayuda, a parte de la imagen que transmite.

Si por ejemplo decidimos que nuestras URL llevan WWW (como yo en este blog) podemos redirigir todo el tráfico que llega a URLs sin WWW con un .htaccess como:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^phpbsd\.net$ [NC]
RewriteRule ^(.*)$ http://www.phpbsd.net/$1 [R=301,L]

Como complemento a la redirección Google también nos permite indicar nuestra preferencia en las Webmaster Tools.

Mis conclusiones:

• Imprescindible la unificación a un formato determinado (con o sin WWW) vía redirección tanto para SEO como para Marketing.
• Normalmente siempre sin WWW a excepción de si se trata de una web dirigida a un público no muy técnico y más aún si pretendemos hacer campañas de publicidad en medios convencionales (tv, prensa, etc.), en estos casos encuentro mejor usar la WWW para indicar claramente que nos estamos refiriendo a una URL. Quizás si usamos TLDs comunes (.com, .net, .org y en nuestro caso .es) cada día es menos necesario, si usamos cualquier otro encuentro muy recomendable usar la WWW.

¿y tú de quién eres? ¿con o sin?

Entradas relacionadas:

• URLs limpias y amigables con PHP y Apache
• MediaWiki con URLs cortas usando mod_rewrite
• Administrar servidores web vía SSH sin contraseña

Se trata de sustituir el código para los Title Tags que normalmente será algo parecido a esto:

por esto si tenemos WordPress 2.3:

o por esto si tenemos versiones anteriores:

Con esta modificación conseguimos los siguientes tipos de títulos:

• En la home: "NOMBRE_DEL_BLOG » DESCRIPCIÓN_DEL_BLOG"
• En las categorías: "Archivo de NOMBRE_CATEGORÍA en NOMBRE_DEL_BLOG"
• En las etiquetas: "Archivo de etiquetas de NOMBRE_ETIQUETA en NOMBRE_DEL_BLOG"
• En los resultados de búsqueda: "Resultados de búsqueda de TEXTO_BUSCADO en NOMBRE_DEL_BLOG"
• Para todos los posts y páginas: "TÍTULO_ENTRADA en NOMBRE_DEL_BLOG"

Lo anterior está extraido del tema K2, traducido al español y con algún retoque. Podría haber hecho un plugin, pero es tan sencillo y como igualmente sería necesario modificar el tema para llamar al plugin, que mira, modificas el tema y directamente introduces el código de lo que sería el plugin.

Si quieres tomarte más en serio la generación de los títulos o si eres perezoso existen plugins muy avanzados como SEO Title Tag y All in One SEO Pack, este último también sirve para gestionar los Meta Tags "description" y "keywords" también muy importantes para SEO pero no tanto como los Title Tags.

Entradas relacionadas:

• Internacionalización de temas en WordPress usando gettext
• Falta poco para la International PHP Conference 2006
• Un poco de música para FreeBSD

La Transferencia de Estado Representacional (Representational State Transfer) o REST describe una interfaz web simple utilizando peticiones HTTP y datos XML pero sin capas adicionales como SOAP, frecuentemente usadas en los servicios web. Precisamente el otro día estuve charlando con mi colega Manuel Aguilar acerca de las ventajas de usar servicios REST en muchos escenarios frente a los clásicos servicios web basados en SOAP o basados en protocolos propios, tema que se trato en la pasada PHP Conference 2007 spring edition celebrada en Stuttgart a la que Manuel asistió.

Sin ánimo de entrar en más detalles de lo que es REST (puedes consultar la definición de la wikipedia que enlazo, está muy bien) vamos a ver como trabajar con del.icio.us desde PHP usando la clase Services_Delicious.

Services_Delicious es una clase todavía en fase beta que no implementa todo lo que nos ofrece el servicio web de del.icio.us, pero que ya permite hacer todas las operaciones básicas cómodamente, como guardar y borrar enlaces, listar los tags, cambiarles el nombre, etc. Son poco más de 400 lineas bastante bien escritas, aunque en PHP4, donde se utiliza HTTP_Request para realizar las peticiones HTTP y XML_serializer para trabajar con los datos XML.

A continuación describo como hacer una nube de tags de una cuenta determinada de del.icio.us y como guardar un nuevo enlace. Esto son sólo dos ejemplos de utilización de algunas de las funciones que nos proporciona Services_Delicious, puedes ver todas las funciones disponibles en el siguiente listado:

1. getTags()
2. renameTag($old, $new)
3. getDates()
4. getPosts($tags, $date)
5. getRecentPosts($tags, $max)
6. getAllPosts()
7. addPost($url, $description, $extended, $tags, $date, $shared)
8. deletePost($url)

Instalación de Services_Delicious

Asumiendo que tenemos las PEAR disponibles lo primero que hemos de hacer es instalar la clase en cuestión:

$ pear install --onlyreqdeps Services_Delicious-beta

Si estamos trabajando con la versión estable de las PEAR, lo más habitual, será necesario añadir "-beta" al nombre del paquete o cambiar la variable de configuración preferred_state. La instalación con el frontend web de las PEAR es igualmente sencilla, lo único a tener en cuenta es que necesita el paquete XML_Serializer que no se instalará automáticamente si tenemos preferred_state=stable ya que también se encuentra en fase beta.

Guardando un enlace en del.icio.us

El código necesario para guardar un enlace es el siguiente:

Con los nombres de las variables se entiende perfectamente como funciona el tema.

Generando una nube de tags

A continuación una utilización un poco más divertida, generar una nube con todas las etiquetas de una cuenta determinada:

Lo anterior sólo es un ejemplo rápido, dependiendo de la cantidad de etiquetas y enlaces se debería hacer algo más con el font-size. Puedes ver funcionando el anterior código sobre mi cuenta en del.icio.us en este ejemplo de nube de tags.

Con Services_Delicious se ha de tener en cuenta que aunque podemos enviar datos con la clásica codificación iso-8859-1 las respuestas vienen en UTF-8, hemos de trabajar con UTF-8 o usar las funciones utf8_encode() y utf8_decode() según convenga, otra opción es modificar Services_Delicious y cambiar la forma de trabajar con XML_Serializer.

Aplicaciones

Aunque la API es muy sencilla nos permite añadir tags a prácticamente cualquier tipo de aplicación PHP, por ejemplo con el anterior código fácilmente nos curramos un pluguin para WordPress que cada vez que colgamos un post lo guarde en del.icio.us, que permita generar una nube de tags, etc. (si es que todavía no existe). Otro ejemplo es con una aplicación de comercio electrónico con stock online como un supermercado o una web de viajes, podemos hacer un script que recorra la BD de turno guardando todos los productos en del.icio.us y permitiendo trabajar con tags, que los usuarios puedan actualizarlos, generar nubes con ellos, etc.

Si a pesar de disponer de tu aplicación PHP en tus servidores o en tu servicio de hosting te gusta sacarte el trabajo de encima con servicios como FeedBurner para los RSS, Flickr para las imágenes, YouTube para los Vídeos... ¿porque no usar del.icio.us para tus tags?

Trabajar con del.icio.us para los tags de tu web tiene la ventaja de que del.icio.us en si es un buen sistema de promoción, mucha gente anda suscrita a RSS de determinados tags, se busca bastante directamente en del.icio.us, etc., y también tiene su efecto en SEO, cada nuevo tag representa un backlink hacia nosotros desde la página de dicho tag. El inconveniente de trabajar con un tercero está claro, que el usuario se pierda por del.icio.us y no vuelva a nuestra tienda o a nuestro blog, aunque siempre podemos usar del.icio.us y no enlazarlos.

A parte de añadir la dimensión de "tag" a nuestra aplicación otro ejemplo de uso de la API de del.icio.us es acceder a nuestros bookmarks de una forma totalmente personalizada y poder mostrarlos como queramos. Un ejemplo de esto es lo que hace Pau Iglesias en la sección de enlaces de su blog, aunque usando otra clase para acceder a la API de del.icio.us que también está muy bien, de hecho es un proyecto más maduro que Services_Delicious.

Esta otra clase es una modificación del mismo Pau Iglesias de la clase original de Dietrich Ayala, autor de las conocidas NuSOAP. En comparación Services_Delicious me gusta más porque básicamente me gusta trabajar con PEAR y usa XML_Serializer/HTTP_Request que, a parte de que ya me las conozco, hacen que el código sea muy limpio y fácilmente adaptable a tus necesidades, pero si no te gustan las PEAR el proyecto del.icio.us PHP API de Pau Iglesias se merece una ojeada, proporciona más o menos las mismas funcionalidades que Services_Delicious pero con el añadido de un interesante sistema de cache.

Entradas relacionadas:

• Leyendo XML desde PHP con SimpleXML
• Envío de emails desde PHP usando varios métodos (PEAR Mail_mime, mail y error_log)
• Como interactuar con Google desde PHP usando Zend Framework

Instalación por consola

Si disponemos de acceso SSH, Telnet, o directo a la consola del servidor este es el procedimiento a seguir.

[1] Iniciamos la sesión de usuario.

[2] Creamos una configuración por defecto para las PEAR:

$ pear config-create $HOME .pearrc

[3] Creamos un directorio temporal en nuestra cuenta para evitarnos problemas de permisos en el directorio "/tmp" del sistema:

$ mkdir $HOME/tmp

[4] Cambiamos las variables necesarias para que trabajen con nuestro directorio temporal:

$ pear config-set download_dir $HOME/tmp/download
$ pear config-set temp_dir $HOME/tmp

[5] Verificamos la correcta configuración:

$ pear config-show

[6] Instalamos el sistema base:

$ pear install -o PEAR

[7] Instalamos las clases PEAR que necesitemos:

$ pear install <clase>

o si queremos instalar alguna versión beta:

$ pear install <clase>-beta

Instalación vía web

Si sólo disponemos de acceso por FTP o Web (como yo con HostGator) o si no queremos trabajar con comandos estos son los pasos necesarios para realizar una instalación vía web.

[1] Vamos a http://go-pear.org/ y guardamos el script PHP que aparece como go-pear.php.

[2] Creamos un directorio en nuestro servidor, por ejemplo "pear", y copiamos go-pear.php dentro.

[3] Abrimos con un navegador la URL correspondiente, por ejemplo:
http://ejemplo.com/pear/go-pear.php

[4] Seguimos los pasos que nos aparecen por pantalla, las opciones por defecto son válidas en la mayoría de ocasiones.

[5] Posteriormente podremos gestionar las clases PEAR instaladas abriendo:
http://ejemplo.com/pear/
Allí nos encontraremos el Web-based PEAR Frontend que nos permitirá instalar, desinstalar y actualizar clases, buscar nuevas clases, cambiar la configuración, etc.

[6] Es importante proteger el directorio de las PEAR para que no sea accesible al público. Al estar dentro del DocumentRoot del servidor Apache cualquiera podrá acceder a la configuración de nuestras PEAR a no ser que protejamos el directorio con usuario+contraseña y/o filtrando por IP.

Snapshot del frontend web de las PEAR:

Configuraciones finales

Una vez completado con éxito cualquiera de los dos procedimientos anteriores sólo nos faltará añadir el directorio que contiene las clases PEAR, en el ejemplo "pear/PEAR", al include_path del PHP para que funciones como include() y require() puedan encontrar las nuevas clases:

Se ha de cambiar "/home/usuario" por la ruta física a tu home de usuario. En el último paso del proceso de instalación vía web se muestra la ruta física a las clases, si has realizado una instalación por consola teclea pwd en tu home y añade "pear/PEAR".

Entradas relacionadas:

• Nuevo blog para las “nuevas” PEAR
• Datos XML bonitos y más leíbles en PHP usando PEAR XML_Beautifier
• Envío de emails desde PHP usando varios métodos (PEAR Mail_mime, mail y error_log)