After spending an hour helping someone debug a site that had an hidden SiteRoot somewhere that prevented a virtual host monster from working, it was suggested to me that if there's a virtual host monster, it should take precedence (and deactivates) any further SiteRoot. I think it's a good idea. Should I create a patch ? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
On Apr 7, 2005, at 1:45, Florent Guillaume wrote:
After spending an hour helping someone debug a site that had an hidden SiteRoot somewhere that prevented a virtual host monster from working, it was suggested to me that if there's a virtual host monster, it should take precedence (and deactivates) any further SiteRoot. I think it's a good idea.
Wouldn't that fall under "Unexpected new behavior"? VHMs have always been "inert" objects that don't do anything unless you specifically use the Mappings tab or you hand them magic URL path elements. That was their beauty as opposed to the "dangerous" SiteRoot. Now you propose adding magic. Magic is BAD, IMHO. -0 on the trunk, but -1 for any maintenance branch. jens
Am Donnerstag, den 07.04.2005, 01:45 +0200 schrieb Florent Guillaume:
After spending an hour helping someone debug a site that had an hidden SiteRoot somewhere that prevented a virtual host monster from working, it was suggested to me that if there's a virtual host monster, it should take precedence (and deactivates) any further SiteRoot. I think it's a good idea.
Better yet, it should just display a warning (and change its icon/title or so) to display the problem and let the user decide the action to take. Regards Tino
On Apr 7, 2005, at 9:08, Tino Wildenhain wrote:
Am Donnerstag, den 07.04.2005, 01:45 +0200 schrieb Florent Guillaume:
After spending an hour helping someone debug a site that had an hidden SiteRoot somewhere that prevented a virtual host monster from working, it was suggested to me that if there's a virtual host monster, it should take precedence (and deactivates) any further SiteRoot. I think it's a good idea.
Better yet, it should just display a warning (and change its icon/title or so) to display the problem and let the user decide the action to take.
That's an excellent idea, and one that I would +1 on all branches ;) jens
-1 for removing it. I think it's a cool feature :-) I like the ability to use a 'blank' SiteRoot (one with a blank base and path) in conjunction with an access rule to set request variables when I access my site in through a particular point (eg set the plone_skin variable when I access my site through /admin or force a particular language when I access my site through /language-name). This is in addition to using VHM and apache rewrite rules in the standard way. I guess this could be done with more complicated rewrite rules but then I become dependent on accessing the site trough apache and lose some flexibility. Laurence Florent Guillaume wrote:
After spending an hour helping someone debug a site that had an hidden SiteRoot somewhere that prevented a virtual host monster from working, it was suggested to me that if there's a virtual host monster, it should take precedence (and deactivates) any further SiteRoot. I think it's a good idea.
Should I create a patch ?
Florent
On Thu, Apr 07, 2005 at 12:55:09PM +0100, Laurence Rowe wrote:
-1 for removing it. I think it's a cool feature :-)
I like the ability to use a 'blank' SiteRoot (one with a blank base and path) in conjunction with an access rule to set request variables when I access my site in through a particular point (eg set the plone_skin variable when I access my site through /admin or force a particular language when I access my site through /language-name). This is in addition to using VHM and apache rewrite rules in the standard way.
I'm curious, what does the SiteRoot buy you over just doing all that in an access rule? -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
On Thu, Apr 07, 2005 at 12:55:09PM +0100, Laurence Rowe wrote:
-1 for removing it. I think it's a cool feature :-)
I like the ability to use a 'blank' SiteRoot (one with a blank base and path) in conjunction with an access rule to set request variables when I access my site in through a particular point (eg set the plone_skin variable when I access my site through /admin or force a particular language when I access my site through /language-name). This is in addition to using VHM and apache rewrite rules in the standard way.
I'm curious, what does the SiteRoot buy you over just doing all that in an access rule?
Having just read up on REQUEST.setServerURL(SiteRootBASE) and REQUEST.setVirtualRoot(SiteRootPATH). I was about to say "nothing at all - I'm just being ignorant", but it looks like the answer is actually 'flexibility'. From http://www.zope.org/Members/4am/SiteAccess2/vhosting """ If a SiteRooted folder is ever accessed through URLs with a base or path that does not get rewritten to match the Base and Path of the SiteRoot, you should make the SiteRoot's Base and Path blank and dynamically create SiteRootPATH/SiteRootBASE variables. For example, if you made a 'Zope' global-access prefix as described above, then the 'else' part should contain something like <dtml-call "REQUEST.set('SiteRootPATH', '/')">. """ Without the blank site root you lose the flexibility of these methods working when the site is not being virtual hosted, which is quite handy while developing. Laurence
participants (5)
-
Florent Guillaume -
Jens Vagelpohl -
Laurence Rowe -
Paul Winkler -
Tino Wildenhain