Llosa^2

Fin de semana pasado por agua: sábado y domingo me he ido a bucear a La Llosa, junto a la isla de Benidorm. Un sitio emblemático de la costa alicantina, de éstos a los que nunca te cansas de ir por la belleza del paisaje y la diversidad de vida marina que se suele encontrar.

#GMAP_SIT(«-0.130033@38.501531|15|102760741917115417098.000438ef84432cfc789d4|510|300»)#

La inmersión del sábado bastante bien, aunque el mar estaba picado y había algo de corriente a poca profundidad (hasta los 6-7m), que hacía tanto la entrada como la salida del agua un tanto complicadas. La de hoy de PM, un auténtido 10: agua en plena calma, a buena temperatura, visibilidad muy buena… hemos visto morenas (vairas, Jose las espantaba para que salieran de los agujeros), congrios… ¡¡hasta una langosta!! Sólo he echado de menos ver algún pulpo.

Y con ésta inmersión ya llevo 12, con lo que ya soy buceador de nivel 2. .·.·B-@

Error -203 al instalar extensiones en Firefox

[spanish]

Hace un rato he ido a instalarme unas cuantas extensiones de Firefox y a actualizar otras, y siempre me daba un error tal que:

"Firefox could not install the file because: Unexpected installation error. Review the error Console log for more detail. -203"

La solución ha sido bastante fácil, en ésta página se explica un método bastante engorroso (básicamente cargarse toda la configuración y reinstalar), pero en un comentario se sugiere borrar tan sólo el fichero extensions.rdf. Mano de santo, borrando sólo ese fichero se ha solucionado el problema. :)

Por cierto, en MacOS X está en:

$HOME/Library/Application Support/Firefox/Profiles/PERFIL/extensions.rdf.

[/spanish]

[english]

Just a moment ago, I wanted to install some Firefox extensions and update some others, but every time I tried FF gave this error:

"Firefox could not install the file because: Unexpected installation error. Review the error Console log for more detail. -203"

The fix has been quite easy. First result on a Google search was this page, where they explain a method that seems quite a drag (basically, whipe all the config out and reinstall everything), but some guy suggests in a comment that the only file you need to remove is extensions.rdf. It worked for me, just by deleting that file the problem was gone. :)

By the way, on MacOS X this file is in:

$HOME/Library/Application Support/Firefox/Profiles/PROFILE/extensions.rdf.

[/english]

lighttpd and WordPress MU (revisited)

[spanish]

En mi artículo anterior sobre lighttpd y WordPress MU proponía un script LUA para usar con mod_magnet como alternativa al .htaccess de Apache. Funcionar funcionaba, aunque mucha gente comentó que usar LUA por cada página servida era sobrecargar un poco el servidor (cuestionable, debería estar suficientemente optimizado) y de todas formas, yo también prefería una solución basada en url.rewrite y demás parámetros de configuración de lighty.

Varias personas sugirieron éste otro método basado exclusivamente en server.error-handler-404. El problema es que es para WordPress y no funciona con WPMU si tienes los blogs como subdirectorios, sólo con subdominios. Pero me ha dado una idea. :)

Usando url.rewrite y error-handler-404 es posible redirigir los blogs en subdirectorios donde toca, y el resto al index.php. De todas formas, éste método todavía tiene un problema: las peticiones que se redirijan al index.php vía error-handler-404 NO reciben los parámetros pasados por GET en la querystring. Es decir, si usamos algún plugin que pase parámetros, como p.ej. jLanguage que añade ?lan=XXXXX, éstas variables no le llegarán al index.php con lo que éstos plugins NO FUNCIONARÁN.

Estoy intentando mejorar más éste método, usando la variable $PHYSICAL[«existing-file»] de lighttpd 1.5.0, pero aún no he llegado a nada. Mientras tanto, la configuración sería ésta:

[/spanish]

[english]

On my previous article about lighttpd and WordPress MU I proposed a LUA script to be used via mod_magnet to handle URL rewrites, as an alternative to the Apache .htaccess file. It worked, but many people complained that using LUA for every page request was quite a load penalty for the server, which I don’t fully agree as it should be sufficiently optimized. But anyway, I’d rather use a solution based off config parameters like url.rewrite, too.

Some people suggested this other method which only used server.error-handler-404. The problem is that it’s designed for standard WordPress, and doesn’t handle WPMU directory-based blogs well. But it set me on the right track anyway. :)

By using both url.rewrite and error-handler-404, you can redirect directory-blogs to the base files and all the rest to the index.php file. Anyway this method still has one big problem: all the queries redirected to index.php by the error-handler-404 will lose all the querystring variables, rendering plugins that use them (like jLanguage which uses ?lan=XXXXXX) useless. Other than that, this method seems to work.

I’m string trying to improve this configuration by using the $PHYSICAL[«existing-path»] variable in lighttpd 1.5.0, but still got nothing. In the meantime, the configuration with the querystring problem would be like this:

[/english]

[code lang=»bash»]

url.rewrite-once = (
«^/(.*/)?files/$» => «/index.php»,
«^/(.*/)?files/(.*)» => «/wp-content/blogs.php?file=$2»,
«^(/wp-admin/.*)» => «$1»,
«^/([_0-9a-zA-Z-]+/)?(wp-.*)» => «/$2»,
«^/([_0-9a-zA-Z-]+/)?(.*.php)$» => «/$2»,
)
server.error-handler-404 = «/index.php»

[/code]

Otra más…

Acabo de hacer otra entrevista telefónica, ésta con una empresa española con oficinas en varias ciudades europeas, en EEUU, latinoamérica y oriente medio. La empresa, los proyectos y el puesto tienen buena pinta, y la entrevista me ha dado buen «feeling». Todas las preguntas de Linux las he clavado, aunque si que me han pillado con una de Windows. :-P

Bueno. Dos de dos. A ver con cuál llega antes el siguiente paso…