On 4/29/2012 1:22 PM, Edho Arief wrote:
> 2012/4/30 Daniel L. Miller<dmiller@amfes.com>:
>> Note that I tried to add the "if" construct in php.conf based on a previous
>> post - and I gotta believe there's a better way to do this. With or without
>> the if construct, the above site works - but only for egroupware.
[..]
>> Doesn't work right. Can some kind soul help me not only fix this - but get
>> a better understanding of how to build these generic constructs? Based on
>> experience with other servers, I can't believe folder-based controls in
>> nginx can be as difficult as I seem to be making it!
> Put "location ~ \.php$ { }" inside each "location ^~ /appname/ { }"
> block instead of globally so it looks like this:
>
> location ^~ /egroupware/ {
> # if index.php's path is /opt/egroupware/index.php,
> # use "root /opt" instead
> root /opt/egroupware;
> index index.php;
> # and remove this
> rewrite ^/egroupware/(.*)$ /$1 last;
> # and update this accordingly
> try_files $uri $uri/ /index.php$args;
> location ~ \.php($|/) {
> ...
> }
> }
>

Thank you! - that helped quite a bit. That way of thinking - of
including the php handler inside each location, instead of a global php
handler, just didn't seem as "elegant" to me - but I can see the power
potential.

However - I still don't understand WHY it works - specifically, why I
need to have "root /opt" instead of "root /opt/egroupware". I'm
inferring that the location path is automatically added to the declared
root in processing. But if that's the case, then to be able to declare,
"location ^~ /lam/", and be able to reach a physical path of
"/opt/ldap-account-manager-3.7", I need to add a symlink from the
extended path to "/opt/lam". And while I may in fact do so for other
reasons - I WOULD like to be able to control exactly what nginx is
doing, and better yet - understand the how/why.
--
Daniel

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx