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]

15 comentarios sobre “lighttpd and WordPress MU (revisited)”

  1. right now it looks like this.

    server.error-handler-404 = «/blog/index.php»

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

  2. Funny, I was going to reply to you just now but you’ve already fixed it yourself. :)

    By the way, bear in mind that this method will give you problems if you need any plugin that uses query string variables. In fact, I’m not using it myself on this blog because I rely on jLanguage for the multi-language posts. If that’s the case with you, you can use this other method here:

    http://www.bisente.com/blog/2007/04/08/lighttpd-wordpressmu-english/

  3. No sé si contestarte porque ya te vas montando la película tu solo… ;)

    Con el error-handler-404 tengo mis dudas porque creo que es lighttpd quien se come los parámetros get al redirigir la petición al fichero, directamente no se los pasa. *Supongo* que si no se los comiera, el index.php ya los estaría interpretando bien. Aunque tal vez si de alguna forma pudiera capturar la URL (alguna variable del servidor) y parsearla… no se.

    La solución más fácil que veo es aplicar los rewrite-once de éste post, de forma que esos casos si que cogerían bien los GET, y al final si la URL no encajara con ninguno, redirigirlo absolutamente todo con otro rewrite al index.php. Sustituir el 404 por otro rewrite. Ahí comprobar en código si el fichero existe y en ese caso devolverlo, y si no, seguir con el código «normal». Pero tiene el problema que tu apuntas: estás tocando un fichero de la distribución original y luego para mantenerlo cuando quieras actualizar WPMU o lo que sea es un coñazo. Aunque supongo que se podría sacar todo a un fichero aparte y simplemente hacer un include desde el index.php con lo que sólo habría que añadir esa línea.

    Hacer un rewrite único, a saco, de todo a algo como el exget2get.php que propones… no lo tengo claro, porque tendrías que de alguna forma «emular» los rewrites en código. Es decir, servir un estático desde un PHP es fácil, pero ¿y cuando tengas que redirigir a otro php distinto, pasándole los parámetros GET que toque, etc? Internamente en PHP no tengo claro cómo se haría (supongo que se podría, pero no es trivial). Siempre podrías recurrir a devolverle un redirect-30X al cliente, pero entonces tendrías dos peticiones para cada una de esas URLs, y además saldría la URL real en lugar de la «clean» en el navegador. :-m

    Si llegas a algo, avisa. :)

  4. Saludos.

    Estoy montando un WP normal (no MU) en un subdominio de un amigo.
    Hasta ahora, con el WP 2.3.2 no he tenido problemas en los permalinks, pero si en el Search.

    Por lo que me contaron, no es apache sino que lighttpd como mencionas arriba. Y tengo ese problema que hablas. Cuando tranto de buscar algo, como que todo lo que envié por GET desaparece.

    Pense que era problema del theme, asi que puse xamp en mi pc y probe denuevo, pero funcionaba correctamente.

    Ahora, tu solución podria aplicarse a un wordpress regular?

    Es lo único que me falta para poder lanzar el openbeta y ya estoy atrasado. No es trabajo, solo un blog comunitario, pero falta poco para el cumpleaños del sitio que es cuando queriamos lanzarlo… y no hay nada peor que dar un regalo atrasado ;(

    Alguna ayudita??

    Gracias de antemano

    Silla!

  5. Mmmm… ¿dices que es un lighty y que no te da problemas con los permalinks? Entonces es que tu amigo le ha configurado ya algo. Los permalinks se basan en el mod_rewrite de Apache y el equivalente de lighty no usa la misma sintaxis ni lee los ficheros .htaccess, por eso éste post y el anterior sobre el mismo tema.

    Y de todas formas, la búsqueda va por POST, no por GET. Me extrañaría que la causa del problema fuera esa. Lo que si que he visto son muchos temas que en el formulario de la búsqueda tienen a saco un action=»/search.php», con la barra apuntando al raíz de la instalación. En esos temas peta la búsqueda cuando estás instalando wp en algún subdirectorio (/blog o lo que sea) porque el action apunta fuera.

    Una cosa que puedes hacer es instalarte la extensión «live HTTP headers» de Firefox, y entre eso y el access.log del servidor ver qué es lo que se pierde y dónde.

    De todas formas si, el método éste para el lighty debería funcionar también sin problemas con un WP normal. De hecho unos comentarios arriba del tuyo hablan de esto y parece que funcionó. Eso si, yo no lo he probado personalmente.

    Suerte!

  6. hi,

    I trying to configure wpmu on lighttpd and was having problem with error 404 and 405. So I searched the net and stumbled upon your blog. Anyway, I have tried your solutions you posted here, but I still have no luck on my wpmu on lighttpd. I guess I’m doing something wrong, can you help me, this is my conf.

    server.modules = (
    «mod_rewrite»,
    «mod_redirect»,
    «mod_access»,
    «mod_fastcgi»,
    «mod_evhost»,
    «mod_accesslog» )
    # files to check for if …/ is requested
    index-file.names = ( «index.php», «index.html»,
    «index.htm», «default.htm» )
    server.error-handler-404 = «/blog/index.php»
    debug.log-request-header = «enable»
    debug.log-response-header = «enable»
    debug.log-request-handling = «enable»
    debug.log-file-not-found = «enable»

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

    $HTTP[«host»] =~ «liteeblog.ph» {

    # # automatic subdomain mapping
    $HTTP[«host»] !~ «www.liteeblog.ph» {
    evhost.path-pattern = «/var/www/virtual/l/li/%0/»
    }
    # rest of conditional (doc roots etc.) goes here…
    }
    $HTTP[«host»] =~ «one.liteeblog.ph» {
    evhost.path-pattern = «/var/www/virtual/o/on/%3.%0/»
    }

    my root docs is at /var/www/virtual/l/li/liteeblog.ph which has a blog symbolic link on /var/www/htdocs/l/li/liteeblog

    i can access my static files like /blog/README.txt but cant access /blog/index.php

    thanks in advance.

  7. here is my error.log

    2008-03-18 18:26:37: (mod_access.c.135) — mod_access_uri_handler called
    2008-03-18 18:26:37: (response.c.205) — splitting Request-URI
    2008-03-18 18:26:37: (response.c.206) Request-URI : /blog/index.php
    2008-03-18 18:26:37: (response.c.207) URI-scheme : http
    2008-03-18 18:26:37: (response.c.208) URI-authority: liteeblog.ph
    2008-03-18 18:26:37: (response.c.209) URI-path : /blog/index.php
    2008-03-18 18:26:37: (response.c.210) URI-query :
    2008-03-18 18:26:37: (response.c.205) — splitting Request-URI
    2008-03-18 18:26:37: (response.c.206) Request-URI : /blog/index.php
    2008-03-18 18:26:37: (response.c.207) URI-scheme : http
    2008-03-18 18:26:37: (response.c.208) URI-authority: liteeblog.ph
    2008-03-18 18:26:37: (response.c.209) URI-path : /blog/index.php
    2008-03-18 18:26:37: (response.c.210) URI-query :
    2008-03-18 18:26:37: (response.c.260) — sanatising URI
    2008-03-18 18:26:37: (response.c.261) URI-path : /blog/index.php
    2008-03-18 18:26:37: (mod_access.c.135) — mod_access_uri_handler called
    2008-03-18 18:26:37: (response.c.375) — before doc_root
    2008-03-18 18:26:37: (response.c.376) Doc-Root : /srv/www/lighttpd/
    2008-03-18 18:26:37: (response.c.377) Rel-Path : /blog/index.php
    2008-03-18 18:26:37: (response.c.378) Path :
    2008-03-18 18:26:37: (response.c.426) — after doc_root
    2008-03-18 18:26:37: (response.c.427) Doc-Root : /var/www/virtual/l/li/liteeblog.ph/
    2008-03-18 18:26:37: (response.c.428) Rel-Path : /blog/index.php
    2008-03-18 18:26:37: (response.c.429) Path : /var/www/virtual/l/li/liteeblog.ph/blog/index.php
    2008-03-18 18:26:37: (response.c.446) — logical -> physical
    2008-03-18 18:26:37: (response.c.447) Doc-Root : /var/www/virtual/l/li/liteeblog.ph/
    2008-03-18 18:26:37: (response.c.448) Rel-Path : /blog/index.php
    2008-03-18 18:26:37: (response.c.449) Path : /var/www/virtual/l/li/liteeblog.ph/blog/index.php
    2008-03-18 18:26:37: (response.c.466) — handling physical path
    2008-03-18 18:26:37: (response.c.467) Path : /var/www/virtual/l/li/liteeblog.ph/blog/index.php
    2008-03-18 18:26:37: (response.c.474) — file found
    2008-03-18 18:26:37: (response.c.475) Path : /var/www/virtual/l/li/liteeblog.ph/blog/index.php
    2008-03-18 18:26:37: (response.c.613) — handling subrequest
    2008-03-18 18:26:37: (response.c.614) Path : /var/www/virtual/l/li/liteeblog.ph/blog/index.php
    2008-03-18 18:26:37: (mod_access.c.135) — mod_access_uri_handler called
    2008-03-18 18:26:37: (response.c.114) Response-Header:
    HTTP/1.1 403 Forbidden
    Content-Type: text/html
    Content-Length: 345
    Date: Tue, 18 Mar 2008 10:26:37 GMT
    Server: lighttpd/1.4.18

  8. TODO MUY BONITO, PERO LO CIERTO ES QUE YO SOLO QUIERO QUE EN MI ORDENADOR SE ALOJEN VARIAS WEBS, ES DECIR QUE CUANDO CUALQUIERA TIPEA http://WWW.EJEMPLO1.COM.AR VEA LA INDEX.HTML ALOJADA EN MI DIRECTORIO /VAR/WWW/EJEMPLO1 ; SI TIPEA http://WWW.EJEMPLO2.COM.AR VEA LA INDEX EN MI /VAR/WWW/EJEMPLO2 Y ASI. LO QUE HICE FUE CREAR LOS DIRECTORIOS DE MIS SITES EN /VAR/WWW Y CREO QUE LOS DE LOS ERRORES EN LOG (YA MI CEREBRO ESTA LIQUADO) EMPECE HACE 5 DIAS CON APACHE 2 Y AHORA ESTOY PROBANDO CON LIGHTTPD EN KUBUNTU 8.0.4 ; SI DEJO EL ARCHIVO LIGHTTPD.CONF TAL COMO VIENE, LEE LA INDEX.HTML EN /VAR/WWW; ES DECIR SOLO PUEDO ALOJAR 1 SITE, ESTO NO ME SIRVE, NECESITO VARIOS Y CON UNA EXPLICACION DETALLADA DE COMO CONFIGURAR TODO ¡¡¡¡¡¡¡¡¡¡¡¡¡SOCORRO!!!!!!!!!!!!!!!!!
    UN ABRAZO,
    JUAN

  9. I was trying out buddypress and looking for solutions again for 404’s, when I found one of my question here, anyway, its been quite sometime, i was able to fix my lighty settings and a long time ago, here is my settings, hope this can help someone too.

    $HTTP[”host”] =~ “(^|.)buddypress.ph$” {

    evhost.path-pattern = “/var/www/virtual/b/bu/%0/blog/”

    server.error-handler-404 = “index.php”

    #fastcgi.server = ( “.php” => ((
    # “bin-path” => “/usr/bin/php-cgi”,
    # “socket” => “/tmp/php.socket”
    # )))

    fastcgi.server = ( “.php” => ((
    “socket” => “/tmp/php-fastcgi-” + var.pid + “.sock”,
    “bin-path” => “/usr/bin/php-cgi”,
    “max-procs” => 1,
    “bin-environment” => (
    “PHP_FCGI_CHILDREN” => “4?,
    “PHP_FCGI_MAX_REQUESTS” => “1000?
    ),
    “bin-copy-environment” => (
    “PATH”, “SHELL”, “USER”
    ),
    “broken-scriptfilename” => “enable”
    )))

    url.rewrite = (
    #for blog
    “^/blog/(.*/)?files/$” => “/blog/index.php”,
    “^/blog/(.*/)?files/(.*)” => “/blog/wp-content/blogs.php?file=$2?,
    “^/blog(/wp-.*)$” => “/blog$1?,
    “^/blog/([_0-9a-zA-Z-]+/)?(wp-.*)” => “/blog/$2?,
    “^/blog/([_0-9a-zA-Z-]+/)?(.*.php)$” => “/blog/$2?,
    # for gallery)
    “^/(.*)/Rewrite.txt$” => “/$1/Works.txt”,
    “^/gallery/v/(?.+| .)?$” => “/gallery/main.php?g2_view=core.ShowItem”,
    “^/gallery/admin[/?]*(.*)$” => “/gallery/main.php?g2_view=core.SiteAdmin&$1?,
    “^/gallery/d/([0-9]+)-([0-9]+)/([^/]+)(?| )?(.*)$” => “/gallery/main.php?g2_view=core.DownloadItem&g2_itemId
    =$1&g2_serialNumber=$2&$3?,
    “^/gallery/v/([^?]+)/slideshow.html” => “/gallery/main.php?g2_view=slideshow.Slideshow&g2_path=$1?,
    “^/gallery/v/([^?]+)(?| )?(.*)$” => “/gallery/main.php?g2_view=core.ShowItem&g2_path=$1&$3?,
    “^/gallery/c/add/([0-9]+).html” => “/gallery/main.php?g2_view=comment.AddComment&g2_itemId=$1?,
    “^/gallery/c/view/([0-9]+).html” => “/gallery/main.php?g2_view=comment.ShowAllComments&g2_itemId=$1?,
    “^/gallery/p/(.+)” => “/gallery/main.php?g2_controller=permalinks.Redirect&g2_filename=$1?
    )

    }

  10. hi,

    this is an old post, i know, but in my wanderings around the web, including the lighty web site, and mediawiki/wikimedia web sites, i found this little bit for query string preservation for mediawiki. please note i’m pasting it in as is, including commented out stuff, but i’ll point out the relevant part that handles the query string.

    url.rewrite-once = (
    «^/wiki/$» => «/w/index.php»,
    # «^/wiki/a/([^?]*)(?:?(.*))?» => «/w/index.php?title=$2&action=$1»
    «^/wiki/a/([a-z]*)/(.*)$» => «/w/index.php?title=$2&action=$1»,
    # «^(.*)$» => «$0»,
    «^(/(?!(index.php|robots.txt|favicon.ico|pgadmin/|images/|js/|css/)).*)» => «/index.php$1»,
    # «^(((/)([^/^?]*)){0,1})(((?)(.*)){0,1})$» => «index.php$1»
    )

    second line above, after «url-rewrite-once»; the «([^?]*)(?:?(.*))?» bit, handles the QS. it’s noted on both mediawiki.org and lighttpd.net sites.

    HTH

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.