Para más información : serie de artículos para conocer las novedades de WordPress 2.5

1. Introducción

   Los usuarios de WordPress llevamos ya unas semanas recibiendo noticias acerca de la nueva versión de nuestro CMS favorito: Worpress 2.3 saldrá en su versión final el 24 de septiembre e incorporará bastantes novedades entre las que se destaca un nuevo filtro para buscar posts en el panel de administración y un nuevo sistema de taxonomías que permite el uso de tags además de las categorías que veníamos utilizando hasta ahora.

   Y claro, como siempre me pasa con estas cosas, al leer esto me he preguntado si realmente era necesario disponer de las dos cosas, si categorías y etiquetas (tags) no eran lo mismo, si las tags (etiquetas) eran palabras clave, si elegir las palabras clave que me dé la gana será una buena idea de cara al futuro … y que conste que no he sido la primera que se hace estas preguntas.

   ¿Cuál es la diferencia entre las categorías y las etiquetas? ¿Por qué ambas se complementan?

   ¿Por dónde empezar? pues, por ejemplo, por esta distinción básica:

2. Indización y clasificación: palabras clave y categorías

   La distinción entre palabras clave y categorías – y por tanto entre indización y clasificación – es una distinción formal. Mientras que las palabras clave asociadas a una unidad de contenido representan sus conceptos más significativos, la categoría asociada describe el tema principal bajo el que se engloba la unidad de contenido.

   Fuente: http://www.nosolousabilidad.com/articulos/descripcion_y_clasificacion.htm
   (La cursiva es mía).
   Es decir, indizar sería describir nuestro artículo utilizando para ello una serie de términos o descriptores significativos: aquellos que hacen referencia a los diversos temas tratados en el artículo. Mientras que clasificar nuestro artículo consistiría en englobarlo dentro de un tema general o categoría.
   Pongamos un ejemplo:
   Supongamos que tengo un artículo que trata del Cercis Chinensis. Palabras clave adecuadas para describirlo serían “cercis”, “chinensis”, “silicastrum”, “jardín”, “botánico” … mientras que, a la vez, lo podría archivar bajo la categoría de Ciencia-Botánica-Árboles que actuaría como el tema del artículo de una forma bastante general …
   Y es que la distinción entre indización y clasificación no radica en que ésta última sea jerárquica o “vertical” y la indización sea un proceso no jerárquico u “horizontal”; para indizar, es decir, para asignar términos descriptivos a un artículo, se pueden utilizar vocabularios libres y abiertos o también vocabularios controlados, formados por conjuntos cerrados de términos y, en el caso de las taxonomías y tesauros, ordenados jerárquicamente. Se puede pues indizar utilizando una jerarquía de términos … y clasificar de forma no jerárquica utilizando estructuras asociativas (o de las dos formas, utilizando también tesauros):
   Hay dos muy buenos artículos acerca de esto:

   1. http://www.hipertexto.info/documentos/clasificacion.htm
   2. http://www.hipertexto.info/documentos/indizacion.htm

   La diferencia entre indizar y clasificar radica en la especificidad: la indización es más específica mientras que la clasificación es más general.
   Reproduzco aquí un dibujo que me parece muy claro:

   
   Fuente: http://www.nosolousabilidad.com/articulos/descripcion_y_clasificacion.htm

   ¿Veis la diferencia entre los temas que se tratan en el artículo y el tema bajo el que éste se engloba?

3. ¿Son la indización y la clasificación complementarias?

   La respuesta es sí, puesto que ambas responden a diferentes formas de búsqueda de información.
   Cuando una persona busca un recurso en Internet (o en una biblioteca), no siempre sabe de antemano y con exactitud qué es lo que está buscando. Los sistemas de recuperación de la información basados en la navegación (browsing) entre las categorías de clasificación, posibilitan que el usuario se haga una idea de los temas disponibles -algo así como “¿Cuáles son los temas que puedo encontrar en este blog?”.
   Ahora bien, puede ocurrir que el usuario sepa con bastante exactitud la temática de los recursos que está buscando; para encontrar estos recursos, acudirá a un buscador en el que tecleará los términos que considere más representativos, iniciando un proceso de querying (pregunta) -algo así como: “¿Hay por ahí algo sobre este tema?”- que resultará mucho más eficaz si previamente se han utilizado palabras clave para describir nuestros artículos y éstas han sido incluidas en su información meta:

   <head>
<title>El titulo de tu pagina</title>
<meta name="description" content="Una descripcion corta de la pagina">
<meta name="keywords" content="palabra clave 1,palabra clave 2,palabra clave 3">
...
</head>

4. ¿Son los tags lo mismo que las palabras clave?

   Bueno, pues esa es para mí la pregunta del millón. He estado mirando por aquí y por allá y he sacado las siguientes conclusiones que no sé si son correctas del todo pero que para mí tienen sentido y me ayudan a organizar la cosas:

   1. Para empezar, “tag” significa “etiqueta” en español y puede ser considerado sinónimo de “label”, aunque hay quien discrepa de esto:
      http://deakialli.bitacoras.com/archivos/2005/08/17/categorias-palabras-claves-etiquetas.
      El uso de “label”, en este artículo que cito, se asemejaría más a lo que en los recursos que he encontrado en español se designa como “tag temático” … o sea un tag al fin y al cabo ¿no?
   2. Un tag o etiqueta no es nada por sí mismo. En realidad una etiqueta no es más que un término privilegiado que lo podemos usar como palabra clave, como categoría o de ambas formas.
   3. Un tag se encuentra así a medio camino entre las palabras clave y las categorías:
      http://www.veaseademas.com/archivos/2006/04/qua_son_los_tag.html
   4. Cuando llevamos a cabo un proceso de tagging (etiquetado) de nuestros artículos, estamos privilegiando ciertos términos que ayudarán a la posterior recuperación de la información, bien mediante un buscador (como Google) bien mediante algún sistema de navegación.
   5. El uso de “tags temáticos” no sólo facilita el proceso de búsqueda (querying) de un recurso (si los incluimos en la información meta) sino que también puede dar lugar a otro sistema de navegación temática, complementario y mucho más específico del que proporciona la clasificación mediante categorías: estoy hablando de los tag-clouds.
   6. Existen plugins para WordPress que añaden cómodamente los tags a la información meta de cada post en forma de palabras clave. Usando esta funcionalidad, tendríamos las tres cosas: navegación entre categorías, palabras clave en la información meta para optimizar la información en los buscadores y, en WordPress 2.3, tag-clouds sin necesidad de plugins gracias a la nueva función <?php wp_tag_cloud( ); ?> .

5. Nuevo sistema de taxonomía disponible en WordPress 2.3

   El nuevo sistema de taxonomías de WordPress 2.3 estará formado por tres tablas:

   1. The first table is the terms table.
      La primera tabla es la tabla de los términos.
   2. A term is not a category or tag on its own. It must be given context via the term_taxonomy table.
      Un término no es una categoría o etiqueta por sí mismo. Se le debe dar un contexto por medio de la tabla de taxonomías (que nos dirá a qué taxonomía pertenece).
      Si “retraducimos” esta frase como:
      “Una etiqueta (tag) no es una categoría o palabra clave por sí misma…” yo creo que la cosa queda bastante clara. En WP2.3 se va a utilizar “tag” como sinónimo de Keyword, es decir como una palabra clave. Un término privilegiado podrá ser, así, una categoría (de artículos o de enlaces), una palabra clave (“tag”) o incluso ambas cosas.
   3. The final table, term_relationships, relates objects such as posts or links to a term_taxonomy_id from the term_taxonomy table.
      La tercera tabla de relaciones entre términos, relaciona objetos tales como artículos o enlaces a un término de una taxonomía de la tabla de taxonomías.
      Es decir, es donde se dice a qué categoría(s) pertenece nuestro artículo y qué palabras clave se emplean para describirlo.

6. ¿Qué tags (palabras clave) emplear?

   ¿Es mejor utilizar palabras clave de un vocabulario restringido o utilizar un vocabulario abierto sólo sujeto a la voluntad del autor?
   Bueno, pues como todo en la vida es cuestión de gustos. Si utilizamos etiquetas ya existentes, por ejemplo en Technorati, facilitaremos que otros usuarios de este servicio accedan a la información que proporcionamos. Si, en cambio, decidimos elegir nosotros nuestras propias palabras clave, (“tags”) quizá describamos con más exactitud (¡Y libertad!) nuestro documento, pero a la vez propiciaremos problemas como la polisemia, la duplicación de información …

7. Fuentes:

   Esta es una relación de artículos que he leído sobre el tema y que me han ayudado, de forma directa o indirecta a elaborar este pequeño cuestionario. Las fuentes que aquí se citan van mucho más allá de las pretensiones de este blog por lo que las conclusiones a las que llego yo, y que a mí me sirven y espero que a un usuario de blogs normalito también, no tienen en absoluto porqué coincidir con las de estos autores.

   De Yusef Hassan Montero:

   • Veaseademas: ¿Qué son los tags?
   • http://www.nosolousabilidad.com/articulos/descripcion_y_clasificacion.htm
   • Indización Social y Recuperación de Información
   • Análisis de los diferentes sistemas de recuperación de la información, entre ellos los tag-clouds

   De Maria Jesús Lamarca Lapuente:

   • http://www.hipertexto.info/documentos/indizacion.htm
   • http://www.hipertexto.info/documentos/clasificacion.htm

1. Seguimos el excelente tutorial de http://www.ruzee.com y editamos los archivos index.php, album.php e image.php según se explica: importando las funciones de WordPress en zenphoto y conectando a las bases de datos de uno u otro gestor según se requiera.
2. Una vez hecho esto, retocaremos la hoja de estilos zen.css de nuestra plantilla de zenphoto para completar la integración y dejarlo más a nuestro gusto.
3. Habilitar comentarios tiene un serio inconveniente de todos conocido: para evitar el odiado spam hemos optado por instalar un sencillo Captcha en nuestra galería: http://www.zenphoto.org/support/topic.php?id=1074 siguiendo, uno a uno, los pasos que se detallan en el paquete de descarga y teniendo cuidado de dotar a la imagen que se genera, code.png, de permisos de escritura.
4. Haciendo estas tres cosas, observamos como, al mostrar cada imagen por separado, se genera un error en el área de comentarios apareciendo siempre este mensaje:There was an error submitting your comment. Name, a valid e-mail address, and a comment are required aunque el funcionamiento sea correcto. Como siempre, no soy la primera a la que le ha ocurrido esto y hay solución en el foro de soporte de zenphoto: http://www.zenphoto.org/support/topic.php?id=824. El error se produce porque la variable $error, que produce el mensaje, es utilizada también por WordPress y la solución pasa por cambiarle el nombre en zenphoto (en mi caso la he llamado $zp_error) pero no en el archivo template-funtions.php como se explica en el foro, sino el archivo functions-controller.php, cosas de la nueva versión.
5. Y ya para terminar, pensé que sería útil incluir un pequeño script en la barra lateral de la galería que permitiera conocer rápidamente si ha habido novedades. Para ello, he incluido el siguiente código que nos muestra cuál ha sido la última imagen que se ha subido a las galerías y los cinco últimos comentarios. Resulta un poco rudimentario ( y prometo pulirlo por si alguien está interesado y lee esto) pero creo que es útil. Ahí va el código:
   <h2>Vida en las Galerías</h2>
<?php db_connect(); // reconnect to zenphoto db ?>
<?php
$last_image = query_single_row(" SELECT * FROM `images` ORDER BY `images`.`id` DESC");
$title = $last_image['title'];
$desc = $last_image['desc'];
$albumid = $last_image['albumid'];
$filename = $last_image['filename'];
$last_image_album = query_single_row("SELECT folder FROM `albums` WHERE id=$albumid");
$last_image_folder =$last_image_album['folder'];
echo "<div class=\"lifeingallery\">";
echo "<h3>Ultima imagen</h3>";
echo "<div class=\"lastimage\"><a href=\""
. (zp_conf("mod_rewrite") ? "../galeria/$last_image_folder/$filename" : "../index.php?last_image_folder=".urlencode($last_image_folder)."
&filename=".urlencode($filename)). "\" title=\"on $last_image_folder / $title\"> $title</a>: $desc </div>";
?>
<h3>Ultimos comentarios</h3>
<ul>
<?php
$comments = query_full_array("SELECT c.id, i.title, i.filename, a.folder, a.title AS albumtitle, c.name, c.website,"
. " c.date, c.comment FROM ".prefix('comments')." AS c, ".prefix('images')." AS i, ".prefix('albums')." AS a "
. " WHERE c.imageid = i.id AND i.albumid = a.id ORDER BY c.id DESC LIMIT 5");
foreach ($comments as $comment) {
$author = $comment['name'];
$album = $comment['folder'];
$image = $comment['filename'];
$albumtitle = $comment['albumtitle'];
if ($comment['title'] == "") $title = $image; else $title = $comment['title'];
$website = $comment['website'];
$comment = truncate_string($comment['comment'], 60);
echo "<li><a href=\""
. (zp_conf("mod_rewrite") ? "../galeria/$album/$image" : "../index.php?album=".urlencode($album)."&image=".urlencode($image))
. "\" title=\"on $albumtitle / $title\">$author</a>: <em>$comment</em></li>";
}
?>
</ul>
</div> <!-- cierra lifeingallery -->
   Comparte este artículo:

   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   ]]> http://sisifodichoso.org/2007/04/06/integrando-zenphoto-en-sisifodichoso/feed/ 16 http://sisifodichoso.org/2007/02/17/mostrar-una-imagen-aleatoria-en-tu-blog/ http://sisifodichoso.org/2007/02/17/mostrar-una-imagen-aleatoria-en-tu-blog/#comments Sat, 17 Feb 2007 10:42:38 +0000 sisi http://sisifodichoso.org/2007/02/17/mostrar-una-imagen-aleatoria-en-tu-blog/ Lo que voy a contar aquí es el código de un script muy sencillo que muestra dos fotos , elegidas aleatoriamente, de mi galería de fotos y cuyo resultado podéis apreciar a la derecha, debajo de los comentarios.

   Este es el código completo:
   <div class="rdimage">
<?php
$elementos1 =array();
$elementos2 =array();
$n1 = 0;
$n2 = 0;
$r1 = 0;
$r2 = 0;
$directorio1 = opendir ('./lomografia/_mg/thumbs/');
while ($elemento = readdir ($directorio1)){
if (($elemento != '.') && ($elemento != '..')){
$elementos1[$n1] = $elemento;
$n1++;
}
}
$directorio2 = opendir ('./mGallery/_mg/thumbs/');
while ($elemento = readdir ($directorio2)){
if (($elemento != '.') && ($elemento != '..')){
$elementos2[$n2] = $elemento;
$n2++;
}
}
$r1 = rand(0,$n1-1);
$r2 = rand(0,$n2-1);
echo '<a href ="/lomografia/index.php" title="lomografias "><img src="/lomografia/_mg/thumbs/'. $elementos1[$r1] . '" alt ="una foto" /></a>';
echo '<a href ="/mGallery/index.php" title="fotos"><img src="/mGallery/_mg/thumbs/'. $elementos2[$r2] . '" alt ="una foto" /></a>';
closedir ($directorio1);
closedir ($directorio2);
?>
</div> <!-- cierra rdimage -->

   Lo explicamos paso por paso:
   
   La idea es abrir dos directorios de imágenes (lo que digo aquí se adapta fácilmente a cualquier otro número), explorar su contenido, almacenar las rutas de las imágenes y luego elegir una imagen de cada directorio al azar .

   Declaramos las variables que vamos a utilizar:

   $elementos1 =array();
$elementos2 =array();
$n1 = 0;
$n2 = 0;
$r1 = 0;
$r2 = 0;
   Donde:

   • $elementos[i] es la matriz donde se almacenan las rutas de nuestras imágenes.
   • $ni es el número de elementos del directorio i.
   • $ri es un número aleatorio (random) elegido del 0 a $ni.

   Abrimos el directorio 1. En este caso, elijo el directorio de thumbnails que ha generado mi galería de fotos gestionada con minimal Galllery:

   $directorio1 = opendir ('./lomografia/_mg/thumbs/');

   Leemos el contenido del directorio y almacenamos las rutas de sus elementos en la matriz $elementos1 siempre y cuando no sean los directorios . y .. (en Unix, los directorios padre y raíz , respectivamente y asumimos que nuestro servidor corre en Unix).

   while ($elemento = readdir ($directorio1)){
if (($elemento != '.') && ($elemento != '..')){
$elementos1[$n1] = $elemento;
$n1++;
}
}

   Hacemos lo mismo con el directorio 2:

   $directorio2 = opendir ('./mGallery/_mg/thumbs/');
while ($elemento = readdir ($directorio2)){
if (($elemento != '.') && ($elemento != '..')){
$elementos2[$n2] = $elemento;
$n2++;
}
}

   Elegimos dos números aleatorios, uno para cada directorio, y mostramos los elementos correspondientes:
   $r1 = rand(0,$n1-1);
$r2 = rand(0,$n2-1);
echo '<a href ="/lomografia/index.php" title="lomografias "><img src="/lomografia/_mg/thumbs/'. $elementos1[$r1] . '" alt ="una foto" /></a>';
echo '<a href ="/mGallery/index.php" title="fotos"><img src="/mGallery/_mg/thumbs/'. $elementos2[$r2] . '" alt ="una foto" /></a>';

   Cerramos los directorios (esto es importante para liberar recursos del sistema y para evitar que el navegador se quede continuamente cargando nuestra página )

   closedir ($directorio1);
closedir ($directorio2);

   Por último, le damos estilo a nuestras imágenes. En mi caso, he creado una clase en mi CSS llamada rdimage:
   #sidebar .rdimage {
margin-left:30px;
margin-top:0px;
width:75px;
background-color:#000;
border: 4px solid #000;
border-bottom: 15px solid #000;
}
#sidebar .rdimage img{
width:75px;
height:75px;
}

   Y ya está …

   Comparte este artículo:

   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   ]]> http://sisifodichoso.org/2007/02/17/mostrar-una-imagen-aleatoria-en-tu-blog/feed/ 6 http://sisifodichoso.org/2007/01/24/problemilla-con-el-calendario-en-wordpress-21/ http://sisifodichoso.org/2007/01/24/problemilla-con-el-calendario-en-wordpress-21/#comments Wed, 24 Jan 2007 18:26:43 +0000 sisi http://sisifodichoso.org/2007/01/24/problemilla-con-el-calendario-en-wordress-21/ Pues eso, que actualicé ayer el blog a WordPress 2.1 y el calendario me mostraba sólo las iniciales de los meses y no las abreviaturas como hasta ahora:

   

   Haciendo caso del artículo sobre el calendario del codex de WordPress, el código de mi sidebar.phpera:
   <?php get_calendar(2); ?>


   Estuve mirando a ver si era cosa de la traducción pero todo parecía estar correcto.
   La solución vino al echar un vistazo al código de la función get_calendar () en el archivo general-template.php
   El código que pongo ahora en mi sidebar.php es:

   <?php get_calendar(false); ?>


   también vale :

   <?php get_calendar(0); ?>

   y ya funciona correctamente (o como yo quiero que lo haga… )

   Comparte este artículo:

   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   ]]> http://sisifodichoso.org/2007/01/24/problemilla-con-el-calendario-en-wordpress-21/feed/ 0 http://sisifodichoso.org/2007/01/21/campos-personalizados-ii/ http://sisifodichoso.org/2007/01/21/campos-personalizados-ii/#comments Sun, 21 Jan 2007 18:33:57 +0000 sisi http://sisifodichoso.org/2007/01/21/campos-personalizados-ii/ Hace ya tiempo que os hablaba de los campos personalizados y de una forma de mostrarlos, mediante un plugin, en la barra lateral del blog:
   http://sisifodichoso.org/2006/08/09/campos-personalizados/
   Pero como creo que entonces no quedó claro qué son realmente los campos personalizados y cómo se utilizan en WordPress, voy a contar aquí mi experiencia y lo que he ido aprendiendo yo al respecto.
   
   Los campos personalizados forman parte de una información de cada post llamada metadatos. Cada post tiene asociada una serie de metadatos que se almacenan en una tabla de la base de datos de WordPress llamada wp_postmeta.

   

   En esta imagen se aprecia la estructura de la tabla: cada campo tiene un nombre, meta_key, y tiene un valor, meta_value, que varía de un post a otro, post_id, en función de si lo hemos cambiado o no al editar o escribir el post.
   Supongamos que quiero que la gente que lee mi blog se vaya enterando de mis progresos en las carreras al mismo tiempo que leen entradas sobre otros temas. Creo, al escribir o editar el post, un campo llamado “corro” que, lo voy cambiando de valor según vaya progresando o cambiando de entrenamiento. Además creo otro campo llamado “leo” para que sepáis qué libro estoy leyendo.

   Para acceder a los metadatos de cada post, se acude a una función llamada the_meta() tal y como se explica aquí:

   • http://codex.wordpress.org/Using_Custom_Fields
   • http://codex.wordpress.org/Template_Tags/the_meta.

   o bien se utiliza algún plugin que nos facilite la tarea.

   En realidad, no hay más que incluir este código en nuestro index.php, dentro del loop:
   <p><strong>Mientras escribo este post:</strong></p>
<?php the_meta(); ?>

   para mostrar el resultado:

   

   Sencillo ¿no? pero volvamos a nuestra base de datos …

   

   … vemos que en el post 119 corrí 27′ y en el 123 hice series.
   Ha sido muy importante para mí entender que en esta tabla, wp-postmeta, se almacenan todos los valores que ese campo personalizado ha ido tomando a lo largo del tiempo. Así por ejemplo, si yo en el post 120 estaba leyendo el libro A y en el post 150 el libro B, ambos valores se conservan en la base de datos de tal forma que siempre que se acuda al post 120 aparecerá que entonces leía el libro A y en el 150 leía el libro B. Yo estaba errada en esto: pensaba que sólo se almacenaba el último valor. Y lo pensaba así, porque al ver los campos en la barra lateral y no en cada post, se veía siempre el último valor de cada campo.
   Teniendo esto en cuenta, no sorprende ver cómo nuestra tabla de metadatos va creciendo y creciendo a lo largo del tiempo, conforme crece el número de posts de nuestro blog y actualizamos el valor de nuestros campos.

   

   Los campos personalizados son enormemente versátiles y se utilizan ampliamente, no sólo por los usuarios de WordPress, sino también en el funcionamiento de muchos plugins de muy diversa índole. Y esto tiene grandes ventajas pero también algún inconveniente. Supongamos que queremos prescindir de un plugin que llevamos tiempo utilizando y que hace uso de los campos personalizados: con esto quiero decir que el plugin ha creado una serie de campos personalizados en mi base de datos que, por regla general, no se borrarán cuando lo desactive.
   En la imagen tenéis un ejemplo de “campo residual” que se ha quedado en mi base de datos aunque ya no utilice el plugin que lo creó:

   

   Llegamos pues a la cuestión ¿Cómo borro un campo personalizado de todos los posts?.
   Evidentemente no soy el primer usuario de WordPress que se hace esta pregunta, http://wordpress.org/support/topic/96356, y la solución aportada en este enlace, acceder a tu base de datos mediante phpMyAdmin por ejemplo y ejecutar esta orden de SQL:

   DELETE FROM wp_postmeta WHERE meta_key = 'NOMBRE_CAMPO';

   es, podríamos decir, la canónica pero, desde luego, no es la más cómoda. Sobre todo para aquellos que no se sienten muy seguros al manejar su base de datos (queda pendiente un post sobre ciertas inseguridades “necesarias” que evitan muchos desastres mayores).

   Bien pues, todo esto me animó a hacer mi propio plugin que borrara los campos personalizados de las entradas que queramos de forma rápida y sencilla. El plugin tiene el originalísimo nombre de “DeleteCustom” y podéis encontrar más información sobre su funcionamiento aquí: http://sisifodichoso.org/proyectos/deletecustom/.
   Por supuesto que no me hago responsable de los daños irreparables que se pudieran producir por su utilización y, en cualquier caso, sea cual sea el método empleado, siempre es buena idea, antes de nada, hacer una copia de seguridad válida de la base de datos

   Comparte este artículo:

   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   ]]> http://sisifodichoso.org/2007/01/21/campos-personalizados-ii/feed/ 12 http://sisifodichoso.org/2007/01/16/wordpress-21-beta-js-comprimido-y-etiquetags/ http://sisifodichoso.org/2007/01/16/wordpress-21-beta-js-comprimido-y-etiquetags/#comments Tue, 16 Jan 2007 15:55:43 +0000 sisi http://sisifodichoso.org/2007/01/16/wordpress-21-beta-js-comprimido-y-etiquetags/ Parece ser¹ que la versión definitiva de WordPress 2.1 aparecerá el 22 de enero, así que ando haciendo pruebas con las versiones beta para comprobar la plena funcionalidad de etiquetags en esta nueva versión.
   Para el que tenga curiosidad por saber si sus queridos plugins funcionarán en WP 2.1 pueden
   comprobar las compatibilidades de los plugins aquí .
   No voy a exponer el resultado de un análisis exhaustivo de las novedades de WordPress 2.1 , pues eso excede con mucho mis capacidades. Sólo quiero destacar aquí, un par de novedades que afectan a etiquetags directa o indirectamente.
   

   1.- Compresión de archivos JS

   (Actualización: 23-01-2007) Lo que se dice aquí sólo es válido para las ediciones beta. En WordPress 2.1 “Ella” se utilizan, como siempre, los archivos sin comprimir
   Ha sido decisión del equipo de desarrollo de WP, la inclusión, como siempre en el directorio wp-includes/js , de dos versiones del mismo script: una comprimida del tipo nombrescript.compressed.js y otra sin comprimir, nombrescript.js.
   La razón para comprimir los scripts está clara: se trata de optimizar la carga y optimizar el rendimiento de unos scripts que van siendo cada vez de mayor tamaño y más pesados en su ejecución. Por otro lado, en el blog de Matt Mullenweg se explica que, dado que este proceso de compresión da como resultado un archivo prácticamente ilegible por un humano, se ha decidido mantener las dos versiones, comprimida y sin comprimir, siguiendo el espíritu de una aplicación de código abierto: http://photomatt.net/2005/05/29/javascript-compression/
   Puesto que el objetivo no es ocultar el código a nadie y no parece que los algoritmos de cifrado de algunos programas de compresión no estén exentos de problemas, basta, para llevar a cabo la compresión, con quitar los espacios en blanco, saltos de línea, tabulaciones y comentarios.
   Existen por ahí bastantes herramientas online que comprimen e incluso “ofuscan” el código javascript.
   En el artículo de Matt se nombran algunas y he encontrado una comparativa aquí: http://blogs.pathf.com/agileajax/performance/index.html
   De todas las que se nombran, he probado dos de ellas que me parecieron las más sencillas en cuanto al resultado:

   1. CSS & JavaScript Compressor
   2. ShrinkSafe

   El resultado ha sido el siguiente:

   	Tamaño	Funciona con Firefox	Funciona con IE	Funciona con Opera
   Archivo original	33.4 Kb	Sí	Sí	Sí
   Comprimido con creativyst	23.5 Kb	Sí	Sí	Sí
   Comprimido con shrinksafe	20.6 Kb	Sí	Sí	Sí

   Echemos un vistazo al código resultante:

   Código original:
   // *************** OPTIONS *************//
var IconDir = '/wp-includes/js/iconos/'; //Icons Directory.
var FormDir = '/wp-includes/js/forms/'; //Forms Directory
// *************** END OPTIONS *************//
// ***** CREATING BUTTONS *****//
var edButtons = new Array();
var edLinks = new Array();
var edOpenTags = new Array();
function edButton(id, display, ico, tagStart, tagEnd, access, onClick, title, open) {
this.id = id; // used to name the toolbar button
this.display = display; // label on button
this.ico = ico; // button icon source
this.tagStart = tagStart; // open tag
this.tagEnd = tagEnd; // close tag
this.access = access; // accesskey
this.onClick = onClick; //onclick button
this.title = title; // button title
this.open = open; // set to -1 if tag does not need to be closed
} ...

   Código comprimido con creatyvist
   var IconDir = '/wp-includes/js/iconos/'; var FormDir = '/wp-includes/js/forms/'; var edButtons = new Array(); var edLinks = new Array(); var edOpenTags = new Array(); function edButton(id, display, ico, tagStart, tagEnd, access, onClick, title, open) { this.id = id; this.display = display; this.ico = ico; this.tagStart = tagStart; this.tagEnd = tagEnd; this.access = access; this.onClick = onClick; this.title = title; this.open = open;}

   Código comprimido con shrinksafe
   var IconDir="/wp-includes/js/iconos/";
var FormDir="/wp-includes/js/forms/";
var edButtons=new Array();
var edLinks=new Array();
var edOpenTags=new Array();
function edButton(id,_2,_3,_4,_5,_6,_7,_8,_9){
this.id=id;
this.display=_2;
this.ico=_3;
this.tagStart=_4;
this.tagEnd=_5;
this.access=_6;
this.onClick=_7;
this.title=_8;
this.open=_9;
}

   Se aprecia que shrinksafe comprime un poco más el código a costa de cambiar nombres de funciones y variables y me da en la nariz (después de utilizar el complicado método de abrir los archivos comprimidos y ver su aspecto) que éste ha sido el programa empleado por el equipo de WordPress para llevar a cabo la compresión. Yo, sin embrago, he elegido el compresor de creatyvist que lo único que hace es quitar saltos y comentarios.
   (Corrección: 23-01-2007) Y ahora viene la pregunta del millón: ¿Hace falta comprimir etiquetags para que funcione con wordpress2.1? La respuesta es claramamente no; etiquetags funcionará igual de bien sin más que renombrándolo como quicktags.compressed.js y cambiando la llamada al script en las ventanas de formularios. Es decir abrimos /wp-includes/js/forms/formimg.html y donde pone
   ponemos
   y lo mismo para formlink.html.
   Pero la solución de aportar un paquete nuevo con quicktags.js y quicktags.compressed.js y los formularios ya corregidos, me parece simplemente más estilosa y elegante. Los paquetes estarán listos, espero, antes de que liberen la versión estable de WP 2.1.

   2.-Nueva interfaz de administración

   Pues me ha hecho ilusión verla: la nueva versión de WP viene con la misma interfaz de administración que ya veníamos disfrutando en los blogs de wordpress.com Me estoy refiriendo a shuttle ; ahora ya no hace falta deshabilitar el editor WYSIWYG para poder disfrutar de etiquetags porque podemos utilizar ambos editores al tiempo para editar nuestros posts.
   Cuando vi hace unos meses esta posibilidad en los blogs de worpress.com, la envidié inmediatamente y resultó ser la fuente de inspiración para el mundialmente conocido botón-de-previo-en-el-mismo-textarea de etiquetags1.1.
   Me parece simplemente la solución ideal: ¿Por qué renunciar a nada pudiendo tenerlo todo?

   

   

   Aunque yo, me he decidido por uno de ellos y he optado por deshabilitar el otro

   Notas

   1. http://www.diarioaborbo.com/2007/01/10/wordpress-21-beta-2/, [volver]
   Comparte este artículo:

   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   ]]> http://sisifodichoso.org/2007/01/16/wordpress-21-beta-js-comprimido-y-etiquetags/feed/ 3 http://sisifodichoso.org/2007/01/14/evitando-el-hotlinking/ http://sisifodichoso.org/2007/01/14/evitando-el-hotlinking/#comments Sun, 14 Jan 2007 20:23:32 +0000 sisi http://sisifodichoso.org/2007/01/14/evitando-el-hotlinking/ Pues nada, que estaba leyendo este interesante artículo: Como evitar el hotlinking de imágenes cuando me he dado cuenta, casi al mismo tiempo, de que mi blog estaba sufriendo hotlinking aunque no de una imagen, sino de un reproductor flash … y es que las conexiones internáuticas son inexcrutables.
   No voy a revelar aquí el nombre del malandrín que cometió tamaña felonía , porque estoy segura de que ha sido una cuestión de simple ignorancia de lo que significa arramplar (perdón por este término tan técnico) con el ancho de banda de los demás sin ni siquiera citar la fuente o dar un enlace, ni nada parecido.
   
   La verdad es que esta cuestión se zanjó solita, porque ayer mismo cambié (aún sin haberme enterado de nada … ) de reproductor de audio y las rutas a los archivos, aprovechando que ahora tengo más espacio en este servidor. Pero claro, cabe la posibilidad de que a alguien se le ocurra hacer algo parecido con otros archivos o imágenes de este blog.
   Así pues, he decidido seguir las indicaciones del artículo y he modificado mi archivo .httaccess que, en mi caso, al utilizar links “bonitos” para las entradas, queda así:
   <IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php
RewriteCond %{REQUEST_FILENAME} \.(png|gif|jpeg|JPG|jpg|swf)$ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !TUSITIO\.org [NC]
RewriteCond %{HTTP_REFERER} !DOMINIOAMIGO\.com [NC]
RewriteCond %{HTTP_REFERER} !bloglines\.com [NC]
RewriteCond %{HTTP_REFERER} !google\. [NC]
RewriteCond %{HTTP_REFERER} !search\?q=cache [NC]
RewriteRule \.(png|gif|jpeg|JPG|jpg|swf)$ /images/nohotlinking.jpp [NC,L]
</IfModule>

   Como veis, he incluido, además de las imágenes, los archivos swf.
   Este es un muy buen artículo para entender las reglas del archivo: http://aeoris.net/escritos/apache/reescribir-direcciones-con-mod_rewrite.html

   A partir de ahora, si alguien hace un hotlink a una imagen de mi blog se encontrará con esto … o eso espero, al menos:
   

   La imagen la he copiado de aquí: http://tec.fresqui.com/como-evitar-el-hotlinking-de-imagenes

   Comparte este artículo:

   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   ]]> http://sisifodichoso.org/2007/01/14/evitando-el-hotlinking/feed/ 15 http://sisifodichoso.org/2007/01/03/cerrar-todos-los-comentarios-en-wordpress/ http://sisifodichoso.org/2007/01/03/cerrar-todos-los-comentarios-en-wordpress/#comments Wed, 03 Jan 2007 12:16:09 +0000 sisi http://sisifodichoso.org/2007/01/03/cerrar-todos-los-comentarios-en-wordpress/ Situación:

   Quieres, por las razones que sean, cerrar tu blog a todos los comentarios, pings y tracks.

   Podrías:

   1. Ir editando de una en una todas las entradas, cerrando comentarios en cada una de ellas … Ni a Sísifo le molaría algo así.
   2. Quitar el formulario para poner comentarios en el blog … Pero eso no impide los pings y los tracks tan habituales en el Spam nuestro de cada día.

   Lo mejor que he encontrado:

   Este plugin que con un simple click cierra todo el blog a comentarios y pings:
   Extended Comment Options for WordPress
   Hay plugins más complejos (aunque éste tiene bastantes opciones), pero yo me quedo con Extended Comment Options que ha sido perfecto para el traslado del blog y además me ha funcionado a la primera.

   Comparte este artículo:

   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   ]]> http://sisifodichoso.org/2007/01/03/cerrar-todos-los-comentarios-en-wordpress/feed/ 0