Las herramientas de personalización de WordPress continúan proliferando sin medida. Ahora le toca el turno a WordPress Theme Generator, una excelente utilidad para crearte tu propia plantilla si es que no encuentras alguna de tu gusto. Sencilla, intuitiva y eficaz (vía Weblog Tools Collection & Blogpocket).
Los formularios de contacto son bien útiles por dos razones principales:
1. Le provee a los visitantes una manera efectiva de comunicarse con el autor sin tener que utilizar su servicio de email .
2. El autor del blog no tiene que proveer su email .
Desde hace unos días, en los blogs de WordPress.com , se pueden añadir formularios de contacto incluyendo la etiqueta de
en el sitio donde deseas el formulario .
wordpress 
, wordpress.com wordpress, wordpress.com
WordPress Theme Generator: Un generador de themes para WordPress. Ya no hay excusa para fabricarte tu propia plantilla.
Via Digg, he descubierto este artículo en el que afirman que el 80% de los blogs (supongo que escritos en inglés) contienen contenido ofensivo.
En mi experiencia por la blogosfera española e inglesa, he visto de todo, pero no tanto como para afirma que el 80% de los blogs contengan un contenido innapropiado.
¿Que opinais? ¿La libertad de expresión está sacando lo peor de nosotros?,
es que un 80% es mucho… Jodxx menuda mixxda de estadistica!!! 
De la mano del creado de WordPress, Matt Mulleweg, nace Random Redirect, un plugin para WordPress que te permitirá redirigir de forma aleatoria a los usuarios de tu WordPress. Para ello únicamente tendremos que pasar el parámetro random por GET a nuestro WordPress y automáticamente no llevará a post aleatorio.
¿Te gustó el artículo? ¡Subscríbete al canal de RSS!tublog.ejemplo.com/?random Hay otros plugins con funcionalidades similares que no debemos olvidar.
InstantUpgrade es un plugin con el cual podemos actualizar nuestro WordPress cada vez que sale un nueva actualización, que ultimamente es muy a menudo.
La instalación tiene algunos pasos que no tienen todos los plugins de WordPress, por eso os pongo abajo un enlace a como instalarlo, que ya me estoy imaginando a alguno diciendome que ha subido el plugin y no le funciona 
Los que os animéis a traducir este magnifico plugin, podéis poneros en contacto con el autor, yo lo mismo lo hago luego.
Este plugin es software libre y esta bajo GNU GPL.
Vía | ScailayHX | Descarga | Instalación
Parece que se ha liado una pequeña discusión a raíz de un email de Matt Mullenweg a la lista de wp-hackers que trata un poco con el tema de las tags que se incorporan o mejor dicho incorporaban en la rama 2.2 de WordPress.
Matt explica varios puntos interesantes para defender su singular esquema de base de datos (wp_categories pasando a wp_terms):
No hay que crear nuevas tablas para las etiquetas (+ post2tag), de otra manera habría que añadir mysql joins en la página frontal y eso les parece que puede ser muy pesado (y si el WordPress ya lo es, a saber qué consideran ellos “pesado”), también piensan que hay múltiples beneficios a largo plazo del hecho que un simple ID les permita mapear un término y un slug.
La idea subyacente es “eliminar” las categorías/etiquetas y usar los “términos”, un término en WordPress tiene un ID, un nombre “humano” y una URL amigable (slug). En las relaciones usan el ID ya que lo encuentran más eficiente y los slugs no tienen porque ser únicos.
Ese “término” puede ser a ojos de un humano una etiqueta, una categoría, un metadato o lo que deseemos pero mantiene la misma lógica en la base de datos y solo hay que crear funciones especificas si queremos tratar de forma diferente esos datos. En ese aspecto Matt cita a Drupal como ejemplo.
Quizá nosotros no notemos diferencia alguna, pero esto puede simplificar mucho las categorías/etiquetas, como ellos dicen si tenemos una categoría “perros” con un ID y una etiqueta “perros” (la cual tiene otro ID) es mucho más difícil de “reunir” esa información si está dividida en diferentes tablas.
¿Consecuencias de ello?. Pues que parece que las etiquetas van a estar deshabilitadas en WordPress 2.2 pero manteniéndose en el trunk y que habrá algunos retrasos hasta que hagan el esquema definitivo.
Lo anuncia Matt Mullenweg en su bitácora, aunque sin mayores explicaciones: el lanzamiento de WordPress 2.2 se retrasa una o dos semanas con respecto a la fecha prevista (el próximo domingo). Matt dice que se pondrá a disposición de los usuarios “cuando esté todo listo”, aunque en Blogging Pro aseguran que al equipo de WP le parece excesivo que el ciclo de actualizaciones del cms se sitúe en los 120 días (la versión 2.1 salió a finales de enero pasado) y parece que tienden a estabilizarlo en 150 días. Casi mejor para todos.
Hoy he recibido un mail de Miguel de EntreGeek (antes BlogR.info), y me comentaba que había cambiado de dominio y que quería volver a cargar la base de datos para disfrutar de los posts y comentarios ya almacenados en el antiguo dominio. Hacer esto es realmente sencillo, ya que mediante herramientas como phpMyAdmin esta tarea es realmente sencilla.
El problema radica en que los enlaces almacenados en la base de datos apunten al servidor antiguo, lo que supone un problema para la consolidación del nuevo servidor ya que los usuarios son redirigidos al antiguo servidor. Para ello podemos hacer uso de una función de SQL que nos permite reemplazar valores almacenados dentro de los campos de nuestra base de datos.
update wp_posts set post_content = replace(post_content,'http://www.antiguo.com','http://www.nuevo.com');
En este ejemplo, vemos que de la tabla wp_posts cambiaremos el contenido de post_content, que es el campo de la tabla que contiene el contenido de los posts, con el mismo contenido al que previamente le habremos cambiado todas las apariciones de http://www.antiguo.com por la ruta http://www.nuevo.com. Si queremos cambiar los enlaces a posts encontrados en los comentarios, tendremos que hacer exactamente lo mismo pero cambiando los datos referentes a la tabla y columna afecta con los relacionados con los comentarios.
Esta propiedad de SQL es muy potente, por lo que es importante usarla con cuidado y hacer que la busqueda ser correcta ya que podemos ocasionar un destrozo en algo muy, pero que muy delicado, nuestra base de datos. Por este motivo, antes de hacer ninguna modificación HAZ UNA COPIA DE SEGURIDAD y asegurate de que el patrón que buscas no sea muy general ya que podría cambiar valores que no deberían ser cambiados.
La idea se la leo a Logadmin que a su vez menciona a Gnucitizen y la “técnica” la ha nombrado bajo un suculento título: “Persistent CSRF and the hotlink hell”.
Un CSRF o Cross-site request forgery — aparte de un término que usa Alex de Buayacorp junto a XSS cinco veces por cada párrafo — es un ataque cruzado entre sitios que intenta aprovechar vulnerabilidades en un sitio para (normalmente) atrapar la cookie de un usuario del cual se sabe que está autentificado en otro sitio.
En el ejemplo de la Wikipedia, “Bob” mira un foro y en el mismo “Alice” (el atacante) publica una imagen con un enlace apuntando al banco de Bob y preparado para el ataque a realizar, si Bob mantiene la cookie/sesión activa al intentar acceder mediante su navegador a la imagen rellenara y enviara con su sesión/cookie lo que el atacante quiera al banco (ej: transferencia de dinero a otra cuenta).
El ataque se basa normalmente en algún tipo de XSS, el poder “inyectar” código (habitualmente javascript) y el saber que el usuario está identificado con el servicio.
En el ejemplo de Logadmin se usa el hotlinking como vector para “inyectar” código mediante URLs:
“A” roba (enlaza directamente) una imagen de “B” para usarla en su sitio pero consumiendo el ancho de banda de “B” — hasta ahí la clásica definición de hotlinking — pero “B” en lugar de cagarse en sus muertos o restringir el acceso decide redirigir la imagen al script de logout de “A” lo cual con htaccess y mod_rewrite es fácil.
Con ello cada vez que el sujeto “A” acceda a la página cerrará la sesión y no podra entrar en su CMS para quitar la imagen “hotlinkeada”. Una táctica muy cabrona, tentado estoy de ponerla en uso.
Una solución para esos casos (una vez “atacado” con esa “broma de mal gusto”) sería redirigir temporalmente el script de logout al de acceder (login) el cual normalmente te lleva al panel de administración.
Aunque lo gracioso (sí: me lo estoy imaginando y lo estoy disfrutando xD) es que a la que entras en la entrada para modificarla y quitar ese hotlinking es que, al menos en WordPress, aparece abajo la entrada previsualizada… por lo que el script te vuelve a echar del CMS… maquiavélico. Pero todo tiene solución (lastima): Kill Preview.
Además, lo anterior es una broma (literalmente) comparado con lo que se puede llegar a hacer si la página que es vulnerable a CSRF lo es también a XSS.
¿Lección del día? Usar hotlinking te expone a ataques CSRF y los BOFH de hoy en día tienen un sentido del humor muy ácido, House se queda en una broma en comparación 
InKiLiNo