Hace unos días (semanas, ya) decidí instalarme en este WordPress el Internet Archive Wayback Machine Link Fixer de (como su propio nombre indica, sí) el Internet Archive. Dice la página del plug-in que sus principales funcionalidades son:
Escanear automáticamente los enlaces salientes de las entradas
Comprobar si hay archivo en la Wayback Machine
Archivar, si no lo hubiese
Redirigir los enlaces rotos o desaparecidos a los archivos
Archivar tus propias entradas y actualizaciones
Todo esto con el obvio objetivo de contribuir a la fiabiliadad a largo plazo del contenido en la web.
En primer lugar, toca felicitar a WordPress y al Archive por la iniciativa, claro (yo hace un tiempo que me instalé el plug in del Archive para Firefox con el objetivo principal de ir archivando a mano las entradas de obm, pero se agradece que te automaticen :-)).
En segundo, animaros a los que tengáis un blog con WordPress a instalaros el plug-in: por los menos de cinco minutos que cuesta configurarlo (hay que obtener una «API Key» (gratuita) del Internet Archive, y es por eso que se tarda algo más) consigues archivar automáticamente todo tu contenido y contribuir al archivado de aquellas páginas que enlazas y que se le podrían haber escapado al bot del Archive.
Y, finalmente, como corresponde a la manía catalogadora de esta casa, toca pasar lista. ¿Cuántos enlaces diríais que hemos lanzado en los tropecientos años que lleva obm funcionando? ¿Mil? ¿Diez mil? ¿Cien mil? Pues nada más y nada menos que trece mil cincuenta y dos (cincuenta y tres o cincuenta y cuatro, diría, una vez que se publique esta entrada O:-)). Se dice pronto, ¿eh? Diez mil doscientos de ellos, por cierto, ya están archivados correctamente (el resto no se han podido archivar, bien porque murieron antes de que se pudieran archivar, bien porque no permiten el archivado, por los motivos que sean). Y, de esos trece mil enlaces, ¿qué porcentaje diríais que se ha roto? Tened en cuenta que el blog lleva en funcionamiento más de veinte años (dios, qué viejo soy). ¿Un 1%? ¿Un 10%? ¿Un 20%? Pues nada más y nada menos que 1301 enlaces o, casi exactamente, el 10%. ¿Y cuántos diríais que se han podido redirigir (con esfuerzo ε/2 por mi parte) a su correspondiente archivo? Los 1301 :-) (confieso que me he creído los números del panel de control y que no he hecho el esfuerzo de investigar más). Si eso no es una recomendación para usar el plug-in (y pasarse por el Archive y hacer una pequeña donación), yo ya no sé…
Me acabo de dar cuenta de que si usas los incrustados de WordPress con un enlace a Amazon, automáticamente les inserta un tag=kp0a0-21 a la URL (o como mínimo me lo hace a mí), y que si la URL que le pegas ya tenía un tag propio, lo sustituye por este… El único uso que conozco yo para el tag en una URL de Amazon es su programa de afiliados, por el que se paga una pequeña comisión a quien promociona el producto que sea a través de un enlace, sin encarecer el producto para quien lo adquiere. Servidor tiene su propio tag (obm-21), que le genera unos «espectaculares» diez o quince euros al año, y acabo de comprobar que al pegar un enlace como https://www.amazon.es/Nada-Volumen-Independiente-Carmen-Laforet-ebook/dp/B009I2UCZ4?&linkCode=ll1&tag=obm-21&linkId=f1552e692fcbcb21b42ab29bfddf52f2&language=es_ES&ref_=as_li_ss_tl el incrustado se come mi tag y lo cambia por el ya mencionado kp0a0-21 😮. Diría que no es ninguno de los plug-ins que le tengo instalado a WordPress, y que no hay ninguna opción para cambiar el comportamiento.
Si el enlace le genera algún beneficio a WordPress.org, no le vería demasiado problema… si se informase bien del tema (y siempre queda la opción, naturalmente, de pasar del incrustado automático). En fin. Lo dejo aquí por si alguien es más capaz de obtener información al respecto que yo (o es alguna obviedad que se me haya pasado por alto, claro).
(Si no habéis pillado la cita del título de la entrada, dad gracias. Si la habéis pillado, disimulad.)
Simple. Que suele ser un elogio.
Pues sí, después de años de hacer «chapucillas WordPress» (pequeños apaños a las plantillas que ha lucido este blog a lo largo de estos últimos ocho años, y a algún otro sitio por el camino), tras unas cuantas (bastantes, de hecho, que uno es lento) horas de trabajo ha salido del horno laiablasco.com, portafolio para la diseñadora del mismo nombre… El diseño no es mío, pero la implementación sí :-). Afortunadamente para un WordPressero sin mucha experiencia como yo, la propietaria del sitio opina que un portafolio debería esconderse y dejar sitio a su contenido, o sea que la cosa ha resultado relativamente sencilla de montar. Aún así, dejo un par de anotaciones que me han resultado importantes…
Maquetado, con Boks
Ya había hablado de Bokshace un tiempo. Y desde entonces no he encontrado ninguna herramienta que supere su combinación de simplicidad y facilidad de uso, ubicuidad (multiplataforma gracias a correr sobre Adobe Air) y precio (gratis, difícil de batir)…
(Las imágenes 'placeholder', por cortesía de dummyimage.com)
Tres cosas más a destacar:
Me incliné por una parrilla de 24 columnas de 40 píxels de ancho, sin ‘gutters’ (los canales de separación entre columnas). Un error: los ‘gutters’ son muy importantes y ahorran bastante trabajo. No me volverá a pasar. Espero.
Cada vez que te casas con una parrilla predefinida te casas también con su familia, que suele componerse de clases poco o nada semánticas que suponen, a la larga, un riesgo de código espagueti poco mantenible. Queda en la lista de cosas por hacer una limpieza de clases, por tanto. Para cuando toque, un recurso: Blueprint’s compress.rb.
De momento, ni código ‘responsive’ ni leches. 960 píxels y tira millas. Diré en mi defensa que los navegadores móviles, en general, sacan algo bastante digno del maquetado tal y como está. Pero queda también en la lista de deberes, al menos, un diseño linealizado a una sola columna de la ‘home’ al bajar de, pongamos, 720 píxels de ancho. Si el CSS es más semántico cuando me ponga (ver punto anterior) no deberia ser complicado.
Alguna cosilla de código
La parrilla tres por tres imágenes implica algún pequeño cambio al bucle de WordPress para poner las clases necesarias a cada primer y tercer ítem. Bastante trivial, de hecho (aunque muy probablemente exista una solución más inteligente). Basta mantener una variable orden_post (o similar) y fijarse en si es 1 o 3 módulo 3 (¿veis como las congruencias servían para algo?):
La última errata siemre se esconde en un título...
Otro punto frecuente al personalizar WordPress es la necesidad de sacar una imagen de cada entrada como destacada a la portada. En este caso (comparad la captura anterior con la que primera de este nanoartículo) podemos querer que en portada aparezca un recorte de la imagen principal, y no un mero escalado. El truco, curiosamente, es no hacer nada, dado que WordPress ya viene preparado por defecto para esta eventualidad (de haberlo sabido antes, la de horas que me habría ahorrado). Sólo hace falta indicar en el functions.php que, por ejemplo, queremos
y después usar adecuadamente las herramientas de edición de imagen de WordPress para indicarle que en el ‘thumbnail’ queremos un recorte diferente:
Fijaos en dos cosas: primero, podemos especificar numéricamente el tamaño del recorte (aunque WordPress ya se encarga de forzar las dimensiones que hayamos establecido); segundo, y más importante, podemos especificar que el recorte sea sólo para la miniatura.
Otro detalle que quizás merece atención es el hacer que tanto el nombre de categoría del h2 como los enlaces de cada ítem vayan en el color de la categoría (diseñadores… (-: ). tanto una cosa como la otra están hechas con parches bastante poco bonitos que buscan sustitutos más elegantes (si sabéis de alguno, para eso están los comentarios ;-) ). Para el título, por ejemplo,
(y definimos, además, en el CSS, clases ‘alineadas’ con los ‘slugs’ de cada categoría, como .category-graphicdesign h2, por ejemplo).
Finalmente, apuntar que los metadatos de cada ítem (técnica, medidas, enlaces y demás) están hechos usando los campos personalizados de WordPress, una solución, que, me da a mí, a la larga será mejor reemplazar con taxonomías o alguna otra solución…
En fin, espero que a alguien le resulte de utilidad en algún momento el tostón. De momento, a mí me ha servido para organizar ideas :-).
Estamos de noche electoral y hay que buscar, aunque sea debajo de las piedras, la estadística que diga que hemos ganado algo, o que al menos no nos la hemos pegado tanto como parecía. La nuestra:
Parece que volvemos a sacar la cabeza, después del batacazo de la cuesta de enero. Tráfico (por semanas) de este blog desde el inicio del año. Fuente: eXTReMe Tracking
El año había comenzado muy bien en esta casa y, pasadas las dos primeras semanas del año, parecía incluso que podríamos dejar el tráfico a la altura del pasado septiembre (la gráfica por meses no la voy a enseñar, que me hace daño) y olvidar el último trimestre de 2010. Y entonces, a media tercera semana, Google nos defenestró (a falta de una palabra más violenta): de más de 700 visitas diarias caímos a 400: una caída de alrededor del 45% que servidor atribuyó al refresco de índice que hizo Google por aquellas fechas. Craso error. Y además innecesario y demostrativo de descuido… Porque si tienes una web lo que deberías hacer, como mínimo, es pasar por www.google.com/webmasters/tools/, registrarte y seguir los pasos indicados para acceder a los datos que el buscador tiene sobre tu web y te ofrece (que no son todos, desde luego). Y eso lo había hecho. Hace meses, si no años. Pero lo único que se me ocurrió fue pasar por www.google.com/webmasters/tools/malware y confirmar que, según Google, mi web estaba libre de ‘malware’. Y creérmelo, maldecir mi suerte y seguir. Y es que Google, como he podido comprobar, no te alerta cuando cree que te estás comportando como un ‘link spammer’: sólo lo hace si cree que estás poniendo en peligro la salud informática de tus visitantes. Cosa que yo no hacía. Pero a fe mía que me tenían en la lista negra. Y con toda la razón. Porque lo que debería hecho justo después de comprobar que Google opinaba que estaba libre de ‘malware’ era (y no fue) pasarme por www.google.com/webmasters/tools/keywords. Si lo hubiese hecho habría comprobado (como hice semanas más tarde) que las ‘keywords’ de obm eran una ensalada de términos spammer, con hasta el último producto farmacéutico ‘de moda’ :-(.
Una vez entendido el problema, la solución es [relativamente] fácil: buscar dónde te han colocado el spam (en mi caso, era bastante burdo y fácil de localizar, una vez sabido que había algo que buscar), borrar y, más importante, averiguar cómo te lo están colocando. En el caso de obm, gracias a la inestimable colaboración de Carlos, la cosa fue rápida y localizamos (localizó, vaya) un img.php de aspecto inocente pero que (i) no tenía ningún motivo para estar donde estaba y (ii) contenía una plataforma de lanzamiento de armas de spam masivo en toda regla (el archivo es como para verlo, de verdad: un miniCMS en un solo archivo). En caso de no encontrar el agujero, el procedimiento habría sido un poco más engorroso pero no mucho más complicado: borrar todos los archivos de WordPress, plugins y temas incluidos, y vuelta a subir desde copias seguras. Y asegurarse que estás actualizado a las últimas versiones tanto de WP como de los plug-ins que tengas instalados, que es la única forma de minimizar los riesgos con ese adorable ‘gruyére’ que es WordPress…
Y a partir de ahí, santa paciencia. Porque Google (comprensiblemente, aunque me pese) no te va a quitar de la lista negra así como así, después de que tú te hayas pasado una buena temporada dando por saco… Y te vas a pasar unas cuantas semanas de tu vida observando con preocupación cómo no desaparecen las palabras clave spammers de la lista, buscando agujeros que, con un poco de suerte, ya no existen, mandando a hacer puñetas a Google, recordando después que la culpa es primero del impresentable que te colocó el paquete, mucho después tuya, después del agujero de turno de WP y/o el plug-in que sea y finalmente de Google… y vuelta a empezar :-S.
En fin. La cosa ‘sólo’ me ha costado cerca de 30.000 visitas. Como mínimo, espero haber aprendido que
Hay que tener el CMS y sus plug-ins actualizados (o, si no estás preparado y/o dispuesto a asumir la responsabilidad, tirar de plataforma de publicación ajena) y
Hay que ser consciente de la necesidad de monitorizar qué pasa y analizar por qué pasa.
Hace un par de días un compañero de trabajo me avisaba de que la web de Mosaic, en la que hago «más o menos» de responsable técnico tenía un problema de XSS (inyección de código) en el formulario de búsqueda.
Alarmado, rápidamente actualicé la versión de WordPress a la 2.9.1, pero no conseguí solucionar el problema. La prueba era fácil, poniendo este sencillo script en el formulario de búsqueda
<script>alert("hola");</script>
Se abría un cuadro de diálogo de alerta.
Hoy, con tranquilidad, me he dedicado a investigar. El error se produce sólo en algunos blogs de WordPress, no en todos. Por tanto no es un problema del gestor de contenidos.
Después de algunas pruebas y algunos cambios, el error ha aparecido. Es un problema de algunos temas de WordPress y es muy fácil de arreglar. En el formulario de búsqueda de los temas que tienen la vulnerabilidad podemos ver algo parecido a esto:
El problema es el echo del código php. Eliminándolo se elimina el problema. Fácil :)
Actualización: Tal como apuntan Javier y Oscar en los comentarios, el problema no es tanto del echo (que permite mostrar la cadena buscada) como el hecho que no se filtre adecuadamente get_search_query().
Por tanto, tal y como propone Javier, en vez de eliminar el echo la solución más elegante es <?php echo htmlentities(get_search_query()); ?>