[Tickets #657] RESOLVED: HTML editing broken if services/editor not a subdirectory of Horde webroot

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=657
-----------------------------------------------------------------------
 Ticket     | 657
 Updated By | kyrian at ore.org
 Summary    | HTML editing broken if services/editor not a subdirectory of Horde webroot
 Queue      | IMP
 Version    | 4.0-ALPHA
 State      | Resolved
 Priority   | 1. Low
 Type       | Bug
 Owners     | Horde Developers
-----------------------------------------------------------------------


kyrian at ore.org (2004-10-08 08:35) wrote:

Ah... The concept of "webroot" is an interesting one here...

What I mean is, if you want something to be inside a CMS system, it has to
have a URL of, say:

http://www.mysite.com/cms/services/editor/htmlarea/htmlarea.js

Where for Giapeto it would be "page.php", or whatever, for the CMS I'm
dealing with at the moment it's "pages".

But for a pure .js script which doesn't need to be modified before its sent
out (?) to the page requester, it makes no sense for it to be sent out
through the CMS, rather than just through Apache, because there is no
requirement for modification, addition of left, right, top, and bottom
borders, etc. so it would make more sense to have the URL not go through the
CMS and be just, eg.

http://www.mysite.com/services/editor/htmlarea/htmlarea.js

For /graphics/, and /$hordeapp/graphics/ it's trivial to do this, you just
copy the directory into the non-CMS webroot, and leave it there. For
/services/editor/ it's rather more complicated, because there isn't just one
function that references it, the references to its URL are scattered accross
numerous places, hence my suggestion of the registry entry for it. Although
I'm a little confused as to why (IIRC, I could be wrong) it appears to be
sometimes called directly and sometimes called through
/services/javascript.php?

However, as we've all rightly said, an Apache 'Alias' directive adequately
fixes this, but it spoils the notion of Horde & Apps just being "drop-in" to
a CMS system, which I thought was the goal.

It's your call, but I think something needs to be tidied up, and my personal
preference (which I'd assumed was yours as well, hence the bug report in the
first place, rather than just apache aliasing it, and getting on with it) is
to allow easy integration with a CMS, which may or may not support the
Horde_Block/Horde_Template system (and currently to be honest a live
IMP/etc. setup doesn't relistically fit within that system either, only the
summary information does...).

I'm sure that if you wish to see the progress I've made so far on getting
Horde/IMP etc into such a CMS I can privately email you the URL of $client's
site, as long as their anonymity is retained.

K.