Lo hice y lo entendí » LAMP/WordPress

Crear los certificados SSL para nuestro servidor web HTTPS con Apache, OpenSSL y Debian Lenny

Vicente Navarro — Sun, 22 Feb 2009 09:53:01 +0000

Cuando escribimos nuestra contraseña para entrar al panel de administración de WordPress, ésta va en texto plano. En una red WiFi, por ejemplo, cualquiera podría ver muy fácilmente nuestra contraseña sólo con capturar la paquetes de la red mientras nos estamos registrando.

Aunque hay soluciones parciales (Semisecure Login Reimagined), la solución definitiva, como siempre, pasa por usar HTTPS o, lo que es lo mismo, HTTP sobre SSL. Desde la versión 2.6, WordPress permite usar SSL fácilmente para el panel de administrador. Así que me puse a hacer pruebas para configurar SSL en mi servidor web.

Sin embargo, ocurre una cosa muy interesante con el protocolo SSL cuando se usa con HTTP: que no se pueden servir fácilmente múltiples sitios virtuales encriptados con SSL desde una misma IP.

En el contexto de los servidores web, hablamos de sitios virtuales (Apache Virtual Host documentation) cuando servimos páginas de diferentes dominios desde un único servidor, en muchos casos compartiendo la IP y en otros, cada dominio con una IP diferente, posiblemente con interfaces virtuales. Cuando usamos HTTP sin SSL, el servidor sabe qué página en concreto estamos solicitando porque el cliente HTTP (el navegador) lo indica en la cabecera Host:

GET /blog/ HTTP/1.1
Host: www.vicente-navarro.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Sin embargo, cuando se usa SSL, la negociación entre los extremos y la encriptación ocurre en una capa inferior, antes de que éstos comiencen a usar el protocolo HTTP. Por ello, no es trivial configurar diferentes certificados para diferentes sitios web virtuales. En la configuración típica, sólo podremos usar un certificado compartido para todas las páginas que se sirvan por HTTPS desde un único servidor web, a menos que usemos una IP diferente para cada sitio: Apache SSL/TLS Strong Encryption: FAQ: Why can’t I use SSL with name-based/non-IP-based virtual hosts?, Apache SSL/TLS Strong Encryption: FAQ: Why is it not possible to use Name-Based Virtual Hosting to identify different SSL virtual hosts?.

Para este inconveniente hay workarounds (TLS Support for name-based virtual servers) y soluciones definitivas con el Server Name Indication (SNI). Apache 2.2 no soporta SNI, pero el módulo de Apache mod_gnutls (incluido en Debian Lenny: libapache2-mod-gnutls) nos permitiría usarlo. Desafortunadamente, aunque Firefox (>=2), Safari, Chrome y Opera soportan esta extensión del protocolo, Internet Explorer 6 e Internet Explorer 7 para Windows XP no soportan SNI, por lo que no podemos usarla de momento por motivos obvios.

Por todos estos motivos, descubrí que con los hostings profesionales no resulta fácil o, mejor dicho, barato, tener un servidor SSL. Es lo que me va a impedir a mí poder configurar SSL para el panel de administración de LHYLE.

Sin embargo, podemos seguir estudiando cómo podríamos hacerlo si lo que tenemos es un Hosting Casero o si le hemos contratado un servidor dedicado a nuestro proveedor de hosting.

(...)

Leer el resto de Crear los certificados SSL para nuestro servidor web HTTPS con Apache, OpenSSL y Debian Lenny (3,046 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 5 comentarios
Etiquetas: Apache, Debian, Firefox, GNU/Linux, Internet Explorer, OpenSSL, seguridad, wget

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Comentarios anidados con WordPress 2.7, nueva vista para archivos y otros cambios en la plantilla

Vicente Navarro — Tue, 13 Jan 2009 19:59:13 +0000

He estado trabajando bastante en reformar la plantilla. No ha habido ningún gran cambio estético, sino que en general han sido cambios para añadir funcionalidades. Además de otras muchas pequeñas mejoras, casi imperceptibles, las dos modificaciones más importantes han sido que la plantilla ahora permite los nuevos comentarios anidados (unos comentarios responden a otros) que ha introducido WordPress 2.7 y que ahora, las páginas de Categorías, Etiquetas o Archivos muestran todas las entradas existentes, pero sin nada de texto o extractos, sólo mostrando el título y los metadatos. Esto era algo que tenía muchas ganas de implementar desde que me inicié en esto de escribir un blog, porque la forma que tiene WordPress por defecto de mostrar las Categorías, Etiquetas y Archivos, sacando 10 entradas por página, no te deja hacerte a la idea en un solo vistazo de qué hay exactamente en cada sección.

Comentarios anidados con WordPress 2.7

En relación a los comentarios anidados, para entender cómo funciona el nuevo loop y cómo adaptar nuestra plantilla para mostrarlos como queramos, podemos usar varias excelentes páginas como referencia:

Al final yo no metí la tijera en la actual plantilla directamente para cambiar el sistema de comentarios viejo por el loop actual. Lo hice al contrario: copié el comments.php de la plantilla de por defecto, la Kubrick, y la fui adaptando a mis necesidades para tener una plantilla que soportara ya comentarios anidados sin problemas y con la máxima compatibilidad con cualquier plugin. El resto fue mucho trabajo de ajustar los estilos en CSS. El resultado se puede ver en los primeros comentarios de ejemplo de esta misma entrada.

¡Ah! Y no se nos tiene que olvidar activar los comentarios anidados en el panel de control (Opciones → Discusión).

(...)

Leer el resto de Comentarios anidados con WordPress 2.7, nueva vista para archivos y otros cambios en la plantilla (956 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 9 comentarios
Etiquetas: blog, PHP, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Servir con Apache imágenes con marca de agua (watermark)

Vicente Navarro — Thu, 18 Dec 2008 20:53:41 +0000

A menudo veo páginas (sobre todo blogs y tiendas online) que “firman” las imágenes que muestran con algún logo o con la dirección web de la página para que si les “roban” las imágenes, al menos sea fácilmente visible el origen de la misma. A ese logo/texto/imagen que superponemos sobre otra para identificar su origen se le suele llamar marca de agua o watermark.

Yo no tengo especial interés en hacer lo mismo con las imágenes de este blog. Al principio de tener la página, sí que detecté muchas páginas que “robaban” imágenes sin citar el origen, pero lo grave no era eso, porque que te copien una imagen en un sitio como este no tiene mayor importancia. Lo realmente grave era que yo detectaba el “robo” porque encima hacían hotlinking a las imágenes de mi sitio, sisándome parte del escaso ancho de banda que yo tenía dado que era un hosting casero. De cómo evitar esto en la medida de lo posible ya hablé en: Hosting casero HOWTO.

El “robo” de imágenes normalmente ocurre porque alguien copia un artículo entero (lo cual es totalmente legítimo si se respeta la Creative Commons), incluidas imágenes (si es con hotlinking ya no me parece tan legítimo) o porque alguien la ha encontrado en los buscadores de imágenes. El tráfico que traen los buscadores de imágenes, según la temática de la página, normalmente es muy poco agradecido: Necesito una imagen para un proyecto, la busco, la copio y se acabó… ¿De qué iba la página de donde he cogido la imagen? ¿Y a quién le importa? Por eso yo, en mi robots.txt, prohíbo que se indexen las imágenes (Remove an image from Google Image Search). No es el tipo de visitante que espero para mis entradas.

Sin embargo, en ciertos casos, como el de una tienda online, tiene mucho sentido que sus imágenes se puedan encontrar fácilmente. En varias ocasiones he tenido que buscar un adaptador de algún tipo y lo he localizado mucho más fácilmente en la búsqueda de imágenes que en la textual y casualmente, los sitios suelen ser tiendas que los venden. Todo perfecto.

Ésos son los casos en los que puede resultar más interesante aplicar una marca de agua a las imágenes del sitio. Como decía, no tengo ningún especial interés en hacerlo, pero sí que en su momento me intrigó el cómo hacerlo, y el resultado es el que podéis leer aquí.

Si nos centráramos en WordPress, existe un plugin, el Marekki’s Watermark, que yo he probado, y que me ha dado muy buena sensación. Sin embargo, no me han gustado dos cosas: que sea necesario modificar los ficheros estándar de WordPress para instalar el plugin y que te suba las nuevas imágenes ya con marca de agua sin mantener ninguna copia del archivo original. A mí me gusta mucho más conservar la imagen original fácilmente disponible para así poder variar o eliminar la marca de agua cuando queramos.

Vamos a ver cómo podríamos hacerlo en nuestra página actual que funcione con Apache y con las excelentes herramientas de ImageMagick. Por si alguien no lo conoce, ImageMagick es una colección de utilidades para editar imágenes en la línea de comandos. Sus posibilidades son infinitas y se trata de un software que nunca deja de sorprendernos. Si no existiera, habría que inventarlo. Tenemos un montón de tutoriales en Examples of ImageMagick Usage.

(...)

Leer el resto de Servir con Apache imágenes con marca de agua (watermark) (604 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 4 comentarios
Etiquetas: Apache, GNU/Linux, hosting, ImageMagick, shell, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Desinstalar plugins de WordPress. Los casos de “subscribe to comments”, “WP Ajax Edit Comments” y WP-OpenID.

Vicente Navarro — Mon, 19 May 2008 16:34:39 +0000

A WordPress le queda bastante que evolucionar en el área de la desinstalación de plugins. Primero, en lo que es propiamente el borrado de los ficheros y directorios que se añaden a wp-contents/plugins, ya que sería deseable que se pudiera hacer rápida y fácilmente desde el panel de administración. Pero segundo, y muchísimo más importante, en lo que respecta a la “basurilla” que los diferentes plugins han añadido a la base de datos y que tras borrar el plugin queda ahí por los siglos de los siglos a menos que nos arremanguemos y nos pongamos a borrar esos restos a mano. La verdad es que no sería mucho pedir que cada plugin se encargara de limpiar lo que deja en la base de datos.

En realidad, se podría argumentar que esos datos tienen que permanecer ahí por si alguna vez queremos volver a instalar el plugin, tener ahí disponible la configuración que se ajusta a nuestro entorno. Es decir, como los ficheros y directorios que comienzan por punto del $HOME de nuestros sistemas Linux, que son ficheros de configuración de los diferentes productos y que permanecen ahí aunque desinstalemos un producto, por si algún día decidimos volver a instalarlo. Pero en realidad, la comparación no es justa, ya que no es lo mismo en términos de sencillez hacer “rm -rf $HOME/.mozilla” o “rm -rf $HOME/.gnome” que tener que ir buscando por la base de datos qué se habrá dejado ahí tal o cual plugin.

Bueno, y esto no es que sea algo que piense yo sólo. También opinan así en:

La verdad es que ahora mismo cualquier responsabilidad en el área de la desinstalación de un plugin se deja enteramente en los desarrolladores de los mismos. Pero sin embargo, yo creo que a poco que hubiera una mínima infraestructura en la API de WordPress para fomentar o facilitar la desinstalación de plugins, muchos desarrolladores que hoy en día ignoran completamente el área de la desinstalación, probablente pasaran a considerarla.

(...)

Leer el resto de Desinstalar plugins de WordPress. Los casos de “subscribe to comments”, “WP Ajax Edit Comments” y WP-OpenID. (2,596 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 3 comentarios
Etiquetas: MySQL, SQL, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

OpenID en WordPress.org y cómo usar WordPress.com como proveedor de identidad

Vicente Navarro — Wed, 07 May 2008 17:43:59 +0000

Desde hoy, Lo hice y lo entendí ya soporta OpenID (gracias al plugin WP-OpenID). Para ti, estimado visitante de este blog, eso significa que en el formulario para dejar comentarios, al lado del cuadro de texto para dejar la URL, ahora puedes ver el siguiente símbolo:

Con lo que esa parte del formulario queda así:

Cuando en ese recuadro escribas una URL habilitada como proveedor de identidad OpenID y hagas click sobre el botón de “enviar el comentario”, el navegador te redirigirá a la página del proveedor de OpenID para que allí aceptes enviar la identidad al blog. En el proveedor de OpenID ya hay que haber iniciado la sesión (log on) de antemano, porque si te dejaran hacerlo en ese momento podríamos ser víctimas de phishing. Entre los proveedores de OpenID más conocidos, encontramos a Blogger y a WordPress.com. Sus pantallas de confirmación del envío de OpenID son así:

(...)

Leer el resto de OpenID en WordPress.org y cómo usar WordPress.com como proveedor de identidad (878 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 43 comentarios
Etiquetas: hosting, OpenID, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Cómo servir contenidos comprimidos de forma estática con Apache

Vicente Navarro — Sat, 12 Apr 2008 13:45:22 +0000

Hace unos meses escribí sobre cómo comprimir los contenidos servidos por Apache para no consumir tanto ancho de banda y además, sobre cómo hacerlo cacheando la compresión para que Apache no tenga que comprimir una y otra vez los mismos contenidos consumiendo CPU:

Así, yo venía usando WP Super Cache para comprimir y cachear WordPress y mod_deflate+mod_cache para los ficheros CSS y los JS.

Sin embargo, cuando en Febrero pasé a hospedar el blog en 1and1.es, me encontré con que usan Apache 1.3 (no 2.x) y que el módulo equivalente al mod_deflate de Apache 2.x, el mod_gzip no está disponible.

Cuando el hosting era casero, la preocupación por el ancho de banda era mayormente por los usuarios, para que no tuvieran que esperar demasiado a que los contenidos se cargaran y ahora, con 1and1.es, la preocupación es por no exceder la cuota de transferencia mensual. Por supuesto, con compresión los usuarios siempre salen ganando, ya que con la potencia de las máquinas actuales, la carga de tener que estar descomprimiendo los contenidos descargados es mínima.

Por tanto, ahora el nuevo objetivo es servir los CSS y los JS comprimidos sin tener ni mod_deflate ni mod_gzip a nuestra disposición.

(...)

Leer el resto de Cómo servir contenidos comprimidos de forma estática con Apache (1,617 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 4 comentarios
Etiquetas: Apache, gzip, mod_deflate, wget, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

WordPress y el cambio de hora

Vicente Navarro — Thu, 10 Apr 2008 19:59:39 +0000

El pasado día 30 de Marzo toda Europa (excepto Islandia) se cambió al horario de verano, como sucede todos los últimos domingos de Marzo, y hasta hasta el último domingo de Octubre, periodo en el que se vive con una hora más respecto al horario solar, excepto en algunos países como España y Francia donde el adelanto respecto del Sol es de dos horas debido a que usamos la Hora Central Europea y, por tanto, en Invierno vivimos con una hora de adelanto respecto del Sol, lo que resulta evidente si examinamos el mapa de las zonas horarias.

Mucho se ha criticado la existencia del cambio de hora que hay quien califica de “jet lag colectivo”. Sin embargo, dadas las costumbres y horarios que tenemos en España, mi opinión es de que a corto plazo sería un drama que la quitaran. Por ejemplo, si mantuviéramos el horario de verano todo el año, a las 9 de la mañana en pleno Invierno, cuando los niños van al colegio y mucha gente entra a trabajar… ¡sería de noche! ¡Entrarías a trabajar de noche y también saldrías de noche! Del mismo modo, si no se cambiara la hora en Verano, en pleno periodo estival ¡amanecería sobre las 6 de la mañana! ¿Para qué querríamos que amaneciera tan pronto si nadie se va a levantar a esas horas para aprovechar el Sol? Mucho mejor es tener esas irrecuperables horas de Sol por la tarde. Por tanto, aquí está mi voto a favor del cambio de hora. ¡Que no todo sea echar tierra sobre esta loable iniciativa porque nadie sepa decirnos si se ahorra un 1%, un 5% o un 10% de energía!.

En cualquier caso, esta vez no quería reabrir el debate del cambio de hora. Sólo quería hablar de la opción que hay en WordPress para seleccionar la hora de nuestro blog (Opciones → General):

(...)

Leer el resto de WordPress y el cambio de hora (402 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 9 comentarios
Etiquetas: blog, horario de verano, WordPress, zonas horarias

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Hosting casero HOWTO

Vicente Navarro — Sun, 09 Mar 2008 16:32:42 +0000

En Primer aniversario del blog os contaba que este blog estuvo en un hosting casero durante un año entero. Viendo los comentarios, parece que esto llamó bastante la atención y, de hecho, hubo unas cuantas peticiones de una entrada sobre el “hosting casero” (en adelante HC), así que, desde la mucha o poca autoridad que me da mi año de autohospedaje, ahí vamos:

(...)

Leer el resto de Hosting casero HOWTO (10,593 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 136 comentarios
Etiquetas: Apache, backup, blog, ddclient, Debian, DNS, DynDNS, exim, GNU/Linux, Google, hosting, Internet, modem, MySQL, OpenSSH, PHP, rsync, shell, SMTP, spam, VIA EPIA, wget, WordPress, Zyxel 660HW

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

La licencia Affero (AGPL) y su relación con la GPL

Vicente Navarro — Sat, 01 Mar 2008 14:41:15 +0000

Cuando hace unos días estaba rediseñando el tema del blog me planteé unas cuantas dudas filosóficas sobre la licencias de WordPress, la de los temas para WordPress y la de las aplicaciones web en general.

El tema es el siguiente: Si programamos una aplicación de las convencionales y la distribuimos bajo los términos de la GPL (sea la v2 o la v3), tenemos que facilitar el código fuente a todos aquellos a los que les proporcionemos binarios de la aplicación. Pero si modificamos código GPL sólo para usarlo nosotros (o en el ámbito de nuestra empresa, por ejemplo), no necesitamos ponerlo a disposición de quien nos lo pida:

Does the GPL require that source code of modified versions be posted to the public?

The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.

But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL.

Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.

Pongamos un ejemplo. Imaginemos que modifico el código de Linux, MySQL o bash que son GPL, pero que esas modificaciones sólo las uso yo o en el ámbito de mi empresa. En ese caso, no tengo obligación de proporcionarle dichos cambios a nadie. Pero ahora imaginemos que alguien se entera de mis cambios y está interesado en ellos, tal vez incluso ofreciendo una remuneración y nosotros nos avenimos a ello. En tal caso, no podemos proporcionarle sólo los binarios, sino que también tendremos que proporcionarle el código fuente con las modificaciones y además, esa persona podrá distribuir el código modificado a quien quiera, incluso gratis aunque nosotros sí que le hayamos cobrado. Recordemos que no hay ningún problema en vender software licenciado bajo la GPL, lo único es que no podemos esperar que si esa persona se lo distribuye a otras, esas otras también nos paguen:

(...)

Leer el resto de La licencia Affero (AGPL) y su relación con la GPL (2,174 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 10 comentarios
Etiquetas: Affero, CMS, GPL, licencias, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Primer aniversario del blog

Vicente Navarro — Sun, 17 Feb 2008 09:17:48 +0000

Hoy es un día especial, porque ¡el blog cumple un año! Un año ha pasado ya desde ¡Bienvenido a mi blog!… y yo como que me siento blogger de toda la vida y resulta que sólo llevo un año. No sé si os pasará a vosotros, pero yo a menudo tengo la sensación de llevar mucho tiempo con algo pero que a la vez ese algo ha pasado muy rápido. Es la sensación que tengo con el blog.

Tal vez podría decir que “Lo hice y lo entendí” cumple un año, pero no sería exacto, porque desde el 17 de Febrero hasta el 24 de Mayo, el nombre del blog fue valencia.homelinux.org, igual que su dirección. ¡Qué poco original! De todas formas, el lema del blog había sido “Me lo contaron y lo olvidé, lo vi y lo aprendí, lo hice y lo entendí” desde exactamente la segunda entrada: Lema del blog.

El 11 de Marzo compré el dominio vicente-navarro.com, y el día 14 comenzó a ser el dominio principal del blog, aunque el otro sigue apuntando aquí todavía, pero hasta el 24 de Mayo, el título del blog siguió siendo valencia.homelinux.org.

Por cierto, no sólo es el primer cumpleaños, da la casualidad de que ésta es la entrada número 100, de modo que hay celebración por partida doble. 100 entradas en 365+1 días es una frecuencia de una entrada por cada 3.66 días. No está nada mal, ¿verdad? Yo mismo estoy sorprendido de que sean tantas, porque muchas de las entradas me han supuesto muchas horas de trabajo, de modo que ya está bien, ya…

El tener un blog propio me ha llevado a “integrarme” mucho más en la web. Mientras que antes me comportaba en la mayoría de los casos como mero espectador pasivo de Internet, sin atreverme a participar de forma activa en prácticamente nada, el blog me metió de pleno en la vidilla social de la Web. Viendo que me gustaba que me dejaran comentarios, comencé a dejarlos yo en otros blogs, y poco a poco mi rol de espectador fue pasando al de actor de un diminuto papel del gran espectáculo que es Internet.

(...)

Leer el resto de Primer aniversario del blog (2,753 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 34 comentarios
Etiquetas: blog, Gravatar, hosting, Internet Explorer, paleta de colores, SP8000E, VIA EPIA, WordPress, Zyxel 660HW

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Corrupción en MySQL: ERROR 2006 (HY000): MySQL server has gone away

Vicente Navarro — Sun, 27 Jan 2008 21:42:10 +0000

MySQL es una base de datos que cada vez me gusta más. Noto que no llega al nivel de funcionalidades de Oracle pero me da la sensación de que es una base de datos muy seria y potente para ciertos tipos usos. Sun acaba de comprar MySQL, espero que sea para bien de esta base de datos, aunque hagan lo que hagan con ella, el código GPL siempre quedará ahí disponible.

En esta entrada voy a contar un extraño problema de corrupción que he tenido con MySQL y cómo lo he solucionado a mi manera. Yo estoy aún empezando con MySQL y estoy un poco verde, así que seguro que he hecho alguna barbaridad que si alguno de vosotros detecta me encantaría que mencionara en los comentarios.

Yo tengo en /var/lib/mysql/ tres bases de datos, una de WordPress, otra de pruebas de WordPress y otra para MythTV:

# ll
total 20588
drwxr-xr-x  9 mysql mysql     4096 2008-01-27 20:47 ./
drwxr-xr-x 50 root  root      4096 2008-01-27 14:17 ../
-rw-r--r--  1 mysql mysql        0 2008-01-10 10:20 debian-5.0.flag
-rw-rw----  1 mysql mysql  5242880 2008-01-27 20:48 ib_logfile0
-rw-rw----  1 mysql mysql  5242880 2006-12-20 20:42 ib_logfile1
-rw-rw----  1 mysql mysql 10485760 2008-01-27 20:48 ibdata1
drwx------  2 mysql root      4096 2008-01-27 20:47 mysql/
-rw-------  1 mysql mysql        4 2006-12-20 20:42 mysql_upgrade.info
-rw-------  1 mysql mysql        6 2007-02-26 11:40 mysql_upgrade_info
drwx------  2 mysql mysql    12288 2006-12-23 11:22 mythconverg/
drwx------  2 mysql mysql     4096 2007-11-11 21:10 wordpress/
drwx------  2 mysql mysql     4096 2008-01-27 13:20 wordpress_dev/

También está la base de datos principal “mysql” que contiene información que necesita almacenar MySQL, como usuarios, privilegios y cosas así.

(...)

Leer el resto de Corrupción en MySQL: ERROR 2006 (HY000): MySQL server has gone away (3,051 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 10 comentarios
Etiquetas: Debian, GNU/Linux, MySQL, MythTV, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Comprimir y cachear las páginas generadas por WordPress

Vicente Navarro — Sun, 02 Dec 2007 18:26:34 +0000

Las dos entradas anteriores:

trataban de conseguir optimizar el ancho de banda de nuestro servidor web comprimiendo el documento para que ocupara menos y de cómo lograr que el mismo contenido no se tenga que comprimir una y otra vez malgastando inútilmente ciclos de CPU. Sin embargo, aquella teoría estaba orientada a páginas estáticas… ¿Cómo podemos hacer lo mismo para contenido creado dinámicamente como es el generado por WordPress? ¿Es aplicable?

El contenido generado por WordPress se puede enviar comprimido a través de varios mecanismos. Por un lado, podemos simplemente señalar la opción “WordPress debería comprimir las entradas (gzip) si los navegadores lo requieren” del panel de “Opciones de lectura” de WordPress. Por otro, podemos habilitar la opción zlib.output_compression del php.ini (en /etc/php5/apache2/php.ini en Debian):

; Transparent output compression using the zlib library
; Valid values for this option are 'off', 'on', or a specific buffer size
; to be used for compression (default is 4KB)
; Note: Resulting chunk size may vary due to nature of compression. PHP
;       outputs chunks that are few hundreds bytes each as a result of
;       compression. If you prefer a larger chunk size for better
;       performance, enable output_buffering in addition.
; Note: You need to use zlib.output_handler instead of the standard
;       output_handler, or otherwise the output will be corrupted.
zlib.output_compression = On

Y por supuesto, podemos usar el mod_deflate, que nos comprime la salida generada por WordPress sin problemas si lo tenemos configurado para que nos comprima los ficheros text/html:

AddOutputFilterByType DEFLATE text/html

Es recomendable no usar más de un método de compresión porque pueden chocar entre ellos.

Sin embargo, todos estos métodos necesitan estar comprimiendo una y otra vez las mismas páginas. ¿Podríamos usar el mod_cache con alguno de estos métodos de compresión como hacíamos con contenidos estáticos y el mod_deflate? Pues desafortunadamente la respuesta es un no.

Si tomamos una traza de red para ver qué cabeceras devuelve una petición enviada a un servidor de WordPress:

HTTP/1.1 200 OK
Date: Sun, 02 Dec 2007 10:05:43 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch7
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Sun, 02 Dec 2007 10:05:44 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Keep-Alive: timeout=15, max=97
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

vemos que entre otras cosas, una respuesta con “Cache-Control: no-cache” no es cacheada por defecto en ningún caso, tal y como leemos en la Apache HTTP Server Version 2.2: Caching Guide:

Likewise, if the response includes the “no-store” option in a “Cache-Control:” header, it will not be stored unless the CacheStoreNoStore has been used.

Sin embargo, el contenido de WordPress, aunque se genera dinámicamente, es bastante estático. Una entrada se escribe y a menos que se generen nuevos comentarios o el autor corrija algo, va a permanecer inalterable durante mucho tiempo. Debería de ser fácilmente cacheable… y en realidad así lo es gracias a distintos plugins.

(...)

Leer el resto de Comprimir y cachear las páginas generadas por WordPress (1,234 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 12 comentarios
Etiquetas: Apache, mod_cache, mod_deflate, mod_disk_cache, PHP, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Usando el mod_cache de Apache para que el mod_deflate no incremente la carga del servidor

Vicente Navarro — Sun, 02 Dec 2007 18:26:18 +0000

En la entrada anterior, Probando el mod_deflate de Apache, vimos cómo conseguir que el Apache comprima los contenidos antes de mandarlos.

Sin embargo, parece un despropósito que el servidor web tenga que estar comprimiendo una y otra vez los mismos contenidos. Supone estar forzando al procesador a usar ciclos que pueden sernos necesarios para otra tarea en algo que debería de poder evitarse. Afortunadamente, gracias al módulo mod_cache, podemos conseguir evitar esta sobrecarga inútil para el servidor.

En realidad, este módulo tiene su máxima utilidad para configurar Apache como servidor Proxy o como Proxy Inverso (mediante el mod_proxy), ya que gracias a la caché, podemos evitar que Apache vuelva a pedir el mismo contenido al servidor final repetidas veces. Para un servidor normal, no parece que una caché pueda proporcionarnos una gran mejora de rendimiento, incluso aunque cacheemos en memoria. Sin embargo, si lo combinamos con el mod_deflate, sí que podemos conseguir que los documentos servidos se almacenen ya comprimidos en la caché ahorrándonos así un elevado e inútil uso de la CPU causado por la compresión repetidas veces de lo mismo.

El documento de referencia para conocer cómo Apache cachea a través del mod_cache es el Apache HTTP Server Version 2.2: Caching Guide, y proporciona sus servicios a través de otros tres módulos que dependen de él: mod_disk_cache, mod_mem_cache, mod_file_cache.

El mod_file_cache es el menos flexible de los tres. Sirve para cachear ficheros concretos en disco o memoria, pero si modificamos alguno de dichos ficheros sólo podremos conseguir que Apache sirva la versión actualizada con un reinicio del gestor:

So whenever one of the mapped files changes on the filesystem you have to restart the server. To reiterate that point: if the files are modified in place without restarting the server you may end up serving requests that are completely bogus. You should update files by unlinking the old copy and putting a new copy in place. Most tools such as rdist and mv do this.

El mod_mem_cache nos permite cachear los ficheros en memoria. Sin embargo, lo que teóricamente podría suponer un a gran mejora de rendimiento del servidor, puede quedarse en mucho menos por dos motivos (In-Memory Caching):

Por un lado, forzar a Apache a usar una gran cantidad de memoria para cachear los ficheros del sistema puede causar que el sistema se vaya quedando corto de memoria para otras tareas llegando a swapear y causando que el rendimiento caiga en picado.
Por otro lado, los sistemas operativos modernos hacen un excelente trabajo cacheando ficheros que se usan frecuentemente, especialmente si hay memoria de sobra. Además, saben perfectamente cuándo el fichero se ha modificado y hay que renovarlo en la caché y saben cuando hay que dejar de cachear porque el sistema se va quedando corto de memoria. ¿Realmente necesitamos que Apache cachée esos mismos ficheros?

El mod_disk_cache va almacenando en un directorio los documentos que se van solicitando, así como sus cabeceras. Si el mod_deflate está activo y hay unos clientes que aceptan compresión y otros que no, se cacheará el documento comprimido y sin comprimir. Por supuesto, no debemos olvidar que la caché del sistema operativo está actuando, así que estos ficheros de caché, si hay memoria suficiente, también serán cacheados en memoria por el kernel.

Por tanto, el mecanismo de caché para almacenar el contenido comprimido que parece más conveniente en muchas situaciones es el del mod_disk_cache y en él nos vamos a centrar en lo sucesivo.

(...)

Leer el resto de Usando el mod_cache de Apache para que el mod_deflate no incremente la carga del servidor (1,492 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 3 comentarios
Etiquetas: Apache, Debian, GNU/Linux, HTTP, mod_cache, mod_deflate, mod_disk_cache

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Probando el mod_deflate de Apache

Vicente Navarro — Fri, 23 Nov 2007 17:47:40 +0000

El RFC2616, de 1999, definió el protocolo HTTP 1.1. En el apartado 14.3, el estándar habla de la cabecera para peticiones Accept-Encoding, que le permite al cliente de HTTP (normalmente un navegador) especificarle al servidor que acepta contenido comprimido.

En efecto, si tomamos una traza de red (p.e. con WireShark) de una petición de un navegador (p.e. Iceweasel) a un servidor web, veremos que éste le dice al servidor web que acepta el contenido comprimido por gzip o por deflate (es decir, zlib):

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.8) Gecko/20071004 Iceweasel/2.0.0.8 (Debian-2.0.0.8-1)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

En Firefox, podemos usar el parámetro del about:config network.http.accept-encoding para especificar exactamente qué queremos tener para esa entrada de la cabecera, siendo el valor por defecto “gzip,deflate“.

Por su parte, el servidor web Apache 2 es capaz de atender esas peticiones de compresión por medio del módulo mod_deflate.

En Debian, el módulo ya viene en el paquete estándar de apache2:

# dpkg -S deflate.load
apache2.2-common: /etc/apache2/mods-available/deflate.load

Sin embargo, no viene activado por defecto. Para habilitarlo, tenemos que crear un enlace en el directorio mods-enabled:

# cd /etc/apache2/mods-enabled/
# ln -s ../mods-available/deflate.load deflate.load

Además, tendremos que elegir las opciones de configuración que más nos puedan interesar. Como la compresión de según qué tipos de ficheros con según qué versiones de navegador puede dar problemas, una solución que nos comprime prácticamente todos los ficheros de texto típicos de una página sin crear mayores problemas es usar la directiva AddOutputFilterByType diciéndole que comprima ficheros HTML, CSS, JavaScript y de texto:

AddOutputFilterByType DEFLATE text/html text/plain text/css application/x-javascript

Tras esto, es conveniente revisar que la sintaxis es correcta con un “apache2ctl configtest” y reinciar el servidor para que se use la nueva configuración sin cortar las conexiones existentes al servidor web con un “apache2ctl graceful“.

Tras aplicar estos cambios, la contestación del servidor web a la petición anterior del navegador será ésta, aceptando la compresión y enviando la página comprimida a continuación:

HTTP/1.1 200 OK
Date: Fri, 23 Nov 2007 16:14:42 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch7
X-Powered-By: PHP/5.2.0-8+etch7
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Fri, 23 Nov 2007 16:14:43 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 22266
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

Si queremos comprobar el buen funcionamiento de este módulo, podemos usar el wget, versátil herramienta que nos permite descargar documentos desde línea de comandos mediante HTTP y FTP.

Por defecto, el wget manda unas cabeceras muy sencillas:

GET / HTTP/1.0
User-Agent: Wget/1.10.2
Accept: */*
Host: www.example.com
Connection: Keep-Alive

Vemos que usa HTTP 1.0 y no indica ningún Accept-Encoding. Sin embargo, podemos usar la opción de línea de comandos --header para modificar las cabeceras y aceptar compresión.

Así, vemos que el fichero raíz de un servidor web que ocupa 78 KiB:

$ wget http://www.example.com
--18:10:02--  http://www.example.com
           => `index.html'
Resolving www.example.com... 10.12.34.56
Connecting to www.example.com|10.12.34.56|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]

    [        <=>                          ] 80,206        40.26K/s

18:10:05 (40.18 KB/s) - `index.html' saved [80206]

únicamente ocupa 22 KiB si se pide comprimido:

$ wget --header="Accept-Encoding: gzip" http://www.example.com
--18:13:51--  http://www.example.com
           => `index.html'
Resolving www.example.com... 10.12.34.56
Connecting to www.example.com|10.12.34.56|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 22,143 (22K) [text/html]

100%[====================================>] 22,143        --.--K/s

18:13:55 (5.19 MB/s) - `index.html' saved [22143/22143]

Sin embargo, si examinamos ese fichero descargado, vemos que no es el fichero HTML que esperábamos, sino un fichero comprimido con gzip:

$ file index.html
index.html: gzip compressed data, from Unix

Sería necesario descomprimir el fichero para encontrar que tiene el tamaño y el contenido esperado:

$ mv index.html index.html.gz
$ gzip -d index.html.gz
$ ll index.html
-rw-r--r-- 1 root root 80206 2007-11-23 18:13 index.html
$ file index.html
index.html: HTML document text

Comprimir las páginas web antes de enviarlas supone una gran ventaja en circunstancias de ancho de banda limitado. Sin embargo, no hay que olvidar que el servidor tiene que estar permanentemente comprimiendo ficheros, lo que puede ocasionar que la CPU no dé abasto. Por tanto, hay que tener muy presente, antes de habilitar esta opción, si en situaciones de carga extraordinaria la limitación de nuestro servidor web está en la carga de CPU o en el ancho de banda disponible.

Finalmente, comentar que en la página www.http-compression.com podemos leer sobre qué navegadores soportan la compresión de las páginas, que son prácticamente todas las versiones modernas de los navegadores comunes: Firefox, Konqueror, Opera e Internet Explorer.

Por cierto, ¿sabías que example.com, example.org y example.net son dominios reservados para usar como ejemplo en la documentación?

:wq

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 14 comentarios
Etiquetas: Apache, Debian, GNU/Linux, gzip, HTTP, mod_deflate, wget, zlib

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Notas sobre la función wptexturize de WordPress, sobre los navegadores que convierten el código HTML a UTF-8 y sobre Unicode/UTF-8

Vicente Navarro — Sat, 17 Nov 2007 20:13:22 +0000

Si nos fijamos en la cabecera del código XHTML de este blog, veremos que está codificado en UTF-8:

Con la vistas puesta en un asunto que tal vez trate en una futura entrada, estaba haciendo unas pruebas de guardar el código desde el navegador a un fichero .html y he descubierto algunas cosas interesantes…

La función wptexturize de WordPress

En primer lugar, que WordPress tiene una función/filtro llamado wptexturize (en wp-includes/formatting.php) que nos arregla el aspecto de algunos signos de puntuación. Por ejemplo, si al editar la entrada escribimos:

"prueba"

la función wptexturize, al crear la página final, lo sustituiría por

“prueba”

que es equivalente a

“prueba”

y que, renderizado por el navegador, queda con fancy quotes (comillas de apertura y cierre diferenciadas):

“prueba”

En What is Texturize? encontramos más ejemplos, y si queremos saber exactamente qué y cómo lo hace, podemos consultar el código de la función. También hay que tener en cuenta que hay fuentes que sacan las fancy quotes exactamente igual que las estándar, así que es posible que según la fuente usada no lo notemos.

Algunos navegadores guardan el código HTML codificado

La segunda cosa que he descubierto es que cuando guardas una página codificada en UTF-8 que tienes abierta en Firefox o en Internet Explorer, los códigos HTML como “ o ” (podemos consultar todos los códigos HTML en Character entity references in HTML 4) son sustituidos por sus secuencia de bytes correspondiente para formar el código UTF-8 que corresponde. Konqueror no lo hace así y deja los códigos tal y como van en la página.

Por ejemplo, supongamos que creamos un fichero HTML con el siguiente código:




Prueba


Una palabra “entrecomillada” como ejemplo.

(...)

Leer el resto de Notas sobre la función wptexturize de WordPress, sobre los navegadores que convierten el código HTML a UTF-8 y sobre Unicode/UTF-8 (751 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: Firefox, GNU/Linux, Icewesel, iconv, internacionalización, Internet Explorer, ISO-8859, juegos de caracteres, Unicode, UTF-8, WordPress, wptexturize

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Hojas de estilo CSS para imprimir

Vicente Navarro — Wed, 07 Nov 2007 00:06:07 +0000

Hace unos días patata dijo en un comentario que le gustan tanto algunos de los artículos de este blog que se los imprime, pero que le quedan muy mal y que si podría poner alguna hoja de estilo para imprimir. A cambio, yo no puedo hacer menos que agradecer tales halagos atendiendo su petición, ya que, por otro lado, es algo muy fácil de hacer, siempre y cuando el HTML esté muy estructurado y no se mezcle contenido con estilo, algo que muchas veces se tiende a hacer, especialmente si se usan herramientas automatizadas de creación de páginas web. Yo procuro evitarlo, aunque reconozco que en ocasiones muy determinadas y concretas lo hago.

El HTML está para el contenido y el CSS para el estilo. Idealmente, el HTML no debería de tener ninguna referencia a colores, fuentes, tamaños, alineamiento del texto, etc. Eso nos permite cambiarle muy fácilmente la hoja de estilo y tener otra página de aspecto radicalmente distinto pero con el mismo contenido. Alguna vez le querido explicar esto a alguien y me ha resultado muy fácil hacerlo apoyándome en CSS Zen Garden: The Beauty in CSS Design, una página en la que partiendo del mismo contenido, multitud de autores le dan un aspecto radical y sorprendentemente distinto únicamente cambiando el CSS, la hoja de estilo.

Para especificar una hoja de estilo diferente para impresión, deberíamos de tener en la cabecera del documento HTML (entre y ) una entrada de CSS para el diseño en pantalla (media="screen") y otra para el diseño para imprimir (media="print"):

Podemos consultar los tipos de media que podemos usar en el estándar CSS 2.1, capítulo Media Types. Vemos que también existe el media handheld para especificar hojas de estilos adecuadas para PDAs y teléfonos móviles.

Para la hoja de estilo de impresión de este blog, yo he decidido intervenir lo mínimo posible. Únicamente escondo todos los elementos que no deberían aparecer en la página impresa: los comentarios, el formulario para introducir comentarios, las cajas laterales, los enlaces de navegación (entrada anterior, entrada siguiente), etc. e intervengo mínimamente en un par de aspectos más.

(...)

Leer el resto de Hojas de estilo CSS para imprimir (592 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 8 comentarios
Etiquetas: blog, CSS, Firefox, Google, HTML, impresión, PHP, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

¡Ya se pueden revisar los comentarios!

Vicente Navarro — Thu, 01 Nov 2007 23:13:45 +0000

Hace unos días Ringmaster se lamentaba en un comentario (que ya corregí con sus indicaciones) de no tener una función de “Vista Previa” en los comentarios para revisar el contenido y el formato de sus trabajados comentarios antes de enviarlo definitivamente.

La verdad es que muchos de los blogs que suelo visitar están en Blogger y una de las cosas que siempre me ha dado envidia ha sido la función de preview o Vista Previa.

Hasta ahora había sido muy reacio a instalar plugins de WordPress, entre otras cosas para no atarme a ninguno y que no me dejaran libertad para migrar a futuras versiones de WordPress con las que pudieran no ser compatibles. Además, algunos meten datos propios en la base de datos que después a ver cómo los borras si quieres dejar de usarlo. Sin embargo, esto era algo absolutamente necesario. Por un lado, por Ringmaster y otros visitantes como él, que con los comentarios tan detallados que nos regalan de vez cuando, es lo mínimo que se merecen, que los puedan escribir y revisar en condiciones. Pero por otro lado, es que hay veces que los comentarios llevan una ortografía desastrosa y quiero pensar que en muchos casos son errores que si existiera la posibilidad de revisarlos, sus autores querrían corregirlos.

Que yo pueda instalar un plugin para WordPress o no, en condiciones normales no hubiera merecido una entrada. Sin embargo, la lamentable ortografía, gramática y expresión al más puro estilo hoygan de ciertos comentarios llega a dañar la vista. Y eso sí se merece una reflexión. Y no es sólo aquí, por supuesto. En este humilde blog en realidad se nota bastante poco. Pero a poco que te das un paseo por la blogosfera española, si te consideras un poco respetuoso de la lengua de Cervantes, te puedes quedar absolutamente alucinado con lo que te encuentras. ¿Es de verdad ese el nivel educativo que tenemos en España? ¿Y lo es también el de los países de Sudamérica, que no parece precisamente mejor?

Podría poner y señalar ejemplos concretos, pero no lo voy a hacer, porque se dice el pecado, y no el pecador y lo último que se merecería un amable lector que pasa por aquí y decide dejar un comentario, es que se le ridiculizara.

Y que no se me entienda mal, por favor: prefiero mil veces que un lector deje un comentario, esté escrito como esté, que que no deje ninguno. Yo soy el primero que puedo tener errores por despiste o por ignorancia. La primera vez que una noticia mía salió publicada en la portada de Barrapunto hice el ridículo más espantoso posible poniendo “hoy a salido” en vez de “hoy ha salido“. Sin embargo, hasta donde puedo, trato de ser meticuloso con la ortografía y la gramática.

Por otra parte, también es muy fácil que ocurra que alguien cometa una pequeña equivocación y al releer se dé cuenta de un error que desearía que no estuviera ahí. Esto me ha ocurrido a mí en ocasiones en blogs WordPress que no tienen Vista Previa. Es en estos casos en los que más falta hace una función como esta.

Por todo ello, tengo el gusto de anunciar que he incorporado el plugin WP Ajax Edit Comments a este blog. El autor del plugin ha creado un vídeo que muestra perfectamente cómo se usa, pero es muy sencillo. Durante 10 minutos (así lo he configurado) después de enviar el comentario, es posible hacer click sobre el comentario o sobre el nick del usuario y modificarlo. Además, aparece un mensaje avisando de que es posible editar la entrada y un contador de tiempo mostrando el tiempo que falta de los 10 minutos.

Creo que está muy bien y no ensucia mucho la base de datos. Sólo mete algunas entradas en wp_postmeta para poder seguir los comentarios que se pueden editar:

mysql> select meta_value from wp_postmeta where meta_value like 'wpAjax%';                                                                                                      
+--------------------------------------------------------------------------------------------------------+
| meta_value                                                                                             |
+--------------------------------------------------------------------------------------------------------+
| wpAjax75bfb832b13b8233462531bb34f12bbeb48f6d51a9066cb3470dcbac6960069c364e0d1dbe06c510f0c3735b9dea964e | 
| wpAjax4740ec477fad9cff90b0a8dc1b7c99003cb06da3684bded96018c7f23b7d8096c1fad451916120e01d277a27775ac371 | 
+--------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

Pero como dichas entradas se pueden eliminar muy fácilmente desde la GUI de WordPress, no tienen mayor importancia. Si no tuviéramos la GUI a mano, podríamos hacerlo así:

delete from wp_postmetadata where left(meta_value, 6) = 'wpAjax';

Otro plugin que he probado y he estado a punto de instalar es el Live Comment Preview. Es muy sencillo. Es sólo un fichero .php que consigue mostrarnos debajo del cuadro de introducción del comentario una previsualización de cómo quedará el comentario al mismo tiempo que lo vamos escribiendo. También muy aconsejable para aquellos que no quieran complicarse mucho la vida.

Si quieres probar el plugin, ya sabes: ¡Deja un comentario!

Actualización 21/11/07:

El WP Ajax Edit Comments también guarda su configuración en la tabla wp_options. Para ver los valores almacenados podemos hacer:

mysql> select * from wp_options where option_name="WPAjaxEditComments";

Y para eliminarlos si queremos desinstalar el plugin:

mysql> delete from wp_options where option_name="WPAjaxEditComments";

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 14 comentarios
Etiquetas: AJAX, blog, Castellano, hoygan, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Las categorías no son etiquetas

Vicente Navarro — Mon, 29 Oct 2007 19:14:14 +0000

¡Vale! ¡Vale! ¡Ya lo tengo claro! Las categorías no son lo mismo que las etiquetas:

Pero la verdad es que yo las estaba utilizando como si lo fueran, lo que me estaba ocasionando que el árbol de categorías creciera a demasiada velocidad, algo que no es lo que se espera de las categorías. Por ello, últimamente estaba siendo muy reticente en crear nuevas categorías, perdiendo así mucha flexibilidad en la clasificación de las entradas, lo que me estaba generando cierta frustración. Así que la reciente salida de WordPress 2.3 con soporte nativo de etiquetas me ha venido como anillo al dedo para racionalizar las categorías, algo que debería de haber ocurrido ya hace tiempo, y para ponerme como loco a ponerle etiquetas a las entradas… y esta vez sin ninguna limitación.

De las páginas anteriores extraigo una recopilación de aspectos, bastante informales algunos de ellos, que ayudan a entender la diferencia entre categorías y etiquetas:

Las categorías se pueden usar como etiquetas pero las etiquetas como categorías, no.
En una comparación con un supermercado, las categorías son como los grandes carteles que indican las secciones (droguería, charcutería, congelados, limpieza, etc.) y las etiquetas son como la propia etiqueta de cada producto que nos lo describe.
Las categorías organizan jerárquicamente, las etiquetas, no.
Las etiquetas proporcionan meta-información (información sobre la información), las categorías, no.
Las categorías pueden tener nombres únicos. Las etiquetas tienen que tener nombres conocidos.
Las categorías pueden tener nombres largos. Las etiquetas tienen que tenerlos cortos, de una, dos o, a lo sumo, tres palabras.
Las categorías no ayudan a los buscadores a buscar información. Las etiquetas, sí, y además, los directorios de etiquetas pueden catalogar tu página.
Las entradas estarán normalmente en pocas categorías, pero puede tener muchas, muchas, etiquetas.
Las categorías ayudan a los visitantes a buscar información relacionada en la página. Las etiquetas ayudan a los visitantes a buscar información relacionada en tu página y fuera de tu página.
Las categorías existen antes de que se cree la entrada que se quiere categorizar, mientras que las etiquetas se crean al crear la entrada: ad hoc.
Las categorías normalmente tienen una granularidad constante, mientras que las etiquetas pueden ser muy generales, como “Linux”, o muy específicas, como “ext3″.
Las categorías se planifican, las etiquetas son espontáneas, fruto de un brainstorming momentáneo: Como ver una foto y escribir las palabras que te sugiere en ese momento.
Las categorías se relacionan como en un árbol. Las etiquetas se relacionan como en una red.
Las categorías son algo que eliges. Las etiquetas salen casi espontáneamente del contenido.
Las categorías ayudan a clasificar aquello de lo que hablo. Las etiquetas ayudan a compartirlo y extenderlo.

Por cierto, también estrenamos nube de etiquetas.

:wq

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 20 comentarios
Etiquetas: blog, categorías, etiquetas, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Deshabilitar los comentarios en todas las entradas de WordPress

Vicente Navarro — Sun, 02 Sep 2007 18:54:10 +0000

En algunos casos puede interesar que la base de datos de WordPress no cambie durante algún tiempo para cualquier tarea de mantenimiento. Nuevas entradas, si tú eres el único que escribe el blog, no va a haber, claro. Pero te puede interesar que nadie haga el esfuerzo de escribir nuevos comentarios si luego podría ocurrir que se fueran a perder.

Para ello, puedes cerrar los comentarios y los pings en todas las entradas fácilmente entrando en mysql:

mysql -u usuario_mysql_wordpress -p nombre_base_de_datos_wordpress

y ejecutando la siguiente sentencia SQL:

UPDATE wp_posts SET comment_status = 'closed', ping_status = 'closed' WHERE comment_status = 'open';

Para volver a permitir los comentarios después:

UPDATE wp_posts SET comment_status = 'open', ping_status ='open' WHERE comment_status = 'closed';

Encontrado en: Enable or Disable WordPress Comments on all posts in one step

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Recuperar una entrada perdida de WordPress. MySQL Point-in-Time recovery: mysqlbinlog.

Vicente Navarro — Thu, 30 Aug 2007 20:52:48 +0000

Estaba ayer finalizando la entrada Los Linux de mi vida en el editor de WordPress cuando en un momento dado quise deshacer lo último que había escrito y pulsé Control+Z. Vi algo raro en la pantalla (aparecía todo el texto seleccionado y hubo unos movimientos raros de texto) pero no le di mayor importancia. Le di a guardar y refresqué la página para ver cómo iba quedando el borrador.

Cuando vi que únicamente me aparecían unos cuantos párrafos del principio me dio un vuelvo el corazón. ¡No sé cómo, había borrado casi todo el texto y lo había guardado!

Y bueno, no es que la pérdida fuera brutal. Supongo que algún empleado de banca que pierda todas las transacciones de un día tiene más motivos de qué preocuparse, pero el cabreo y el disgusto no te lo quita nadie por un rato. Por supuesto, pasé por todas las fases que se requieren en estos casos. A saber:

Negación: ¡No puede ser! ¡No ha ocurrido! ¡Es un mal sueño!
Enfado: ¡Me ca%$ en tó lo que se menea!
Discusión: ¡Pues ahora la entrada esta la va a escribir Rita la Cantaora!
Depresión: ¿Por qué a mí? ¿Qué he hecho yo para merecer esto?
Aceptación: ¡En fin! ¿Qué voy a hacer? Reescribiré la entrada… como ya la había escrito una vez y tenía las ideas claras, igual ahora sale mejor.

Cuando se me fue despejando la mente pensé que si en Oracle existían los Redo Logs (Oracle: Managing the Online Redo Log) y la posibilidad de indagar en ellos con el LogMiner (Oracle 10g: Using LogMiner to Analyze Redo Log Files, Oracle Magazine: Mining for Clues), y la capacidad de dejar la base de datos como estaba en un momento dado en el pasado o Point-In-Time Recovery (Oracle 10g: Performing Database Point-In-Time Recovery), igual había algo similar para MySQL que me permitiera deshacer los últimos cambios.

(...)

Leer el resto de Recuperar una entrada perdida de WordPress. MySQL Point-in-Time recovery: mysqlbinlog. (994 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 5 comentarios
Etiquetas: Debian, MySQL, mysqlbinlog, Oracle, SQL, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Guardar las imágenes subidas al servidor fuera del árbol de directorios de WordPress

Vicente Navarro — Sun, 11 Mar 2007 22:27:16 +0000

Desde que uso el excelente WordPress, hay algo que nunca me ha gustado: El no poder guardar las imágenes subidas al servidor desde el editor de entradas fuera del árbol de directorios de WordPress cuando la Dirección de WordPress es distinta de la Dirección del blog. Por ejemplo, tenemos el blog en http://www.ejemplo.com, el WordPress en http://www.ejemplo.com/wp y queremos tener las imágenes subidas en http://www.ejemplo.com/img.

Es en Opciones → Miscelánea donde podemos elegir en qué directorio debajo de la estructura de WordPress queremos tener las imágenes subidas, pero si tenemos el WordPress en, por ejemplo, /wordpress, nunca podríamos tener las imágenes en /img.

Buscando si había alguna forma estándar de cambiar esto, encontré a mucha gente que preguntaba lo mismo, pero pocas respuestas. Finalmente llegé a una entrada en el foro de soporte de WordPress que me daba pistas, pero para mi versión actual, la 2.1.2, la solución propuesta no se podía aplicar directamente.

(...)

Leer el resto de Guardar las imágenes subidas al servidor fuera del árbol de directorios de WordPress (551 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: MySQL, patch, PHP, WordPress

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

El PATH del cron. Avisos de mail. Sesiones interactivas y de login de Bash.

Vicente Navarro — Mon, 26 Feb 2007 07:35:10 +0000

En El Efecto Barrapunto comentaba que el siguiente script para rotar el access.log del apache no me funcionaba en el crontab y sí desde la línea de comandos:

#/bin/bash
cd /var/log/apache2
BAKFILE=access.log.`date +%g%m%d%H%M`
mv access.log $BAKFILE
apache2ctl graceful
sleep 600
gzip $BAKFILE

Aparte de que el logrotate está mucho más indicado para este propósito, el misterio se ha desvelado gracias a un amable lector de barrapunto. Resulta que el apache2ctl está en /usr/sbin, no en /usr/bin ni en /bin, que son los únicos directorios que vienen en el PATH del cron por defecto ya que ni el /etc/profile ni el .bashrc ni similares se ejecutan en ningún momento antes del comando.

(...)

Leer el resto de El PATH del cron. Avisos de mail. Sesiones interactivas y de login de Bash. (650 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: Apache, bash, cron, Debian, exim, GNU/Linux

Entradas relacionadas

Feed enhanced by Better Feed from Ozh