Nope. No easy way to solve it for now without reworking large parts of 
Horde, and I don't think it's critical (yes, easier integration with 
other apps would be nice, but this is an extreme case solveable with 
an apache directive).

Any further action to take on this one?

The first call includes templates/javascript/htmlarea.js, parsed 
through services/javascript.php. This one sets the base URL of the 
HTMLArea editor. The editor needs this URL to find all its scripts, 
images and CSS files. We pass it through javascript.php because the 
path depends on the 'webroot' setting.

Maybe you can relocate the htmlarea scripts by only changing this file.



The second call uses the capability of Horde::addScriptFile() to 
create <!--a75c305b1c0a6022--><script> tags *without* parsing the 
script files throug javascript.php. It includes the basic JS file for 
the HTMLArea editor. This is the action that any client needs to take 
that wants to use this editor. This way to call addScriptFile() also 
requires the 'webroot' setting, not at call-time but when 
Horde::includeScriptFiles() actually renders the 
<!--a75c305b1c0a6022--><script> tags.



This is the only way to keep the htmlarea code separate from the Horde 
code and keep it updateable without needing to patch the code each time.

I have absolutely no idea what that's for. Jan, Marko?
Aha. Correct. I think I have a clear answer on this one, though not a 
solution (yet?). We could solve this by adding a "services" parameter 
to the registry that could be set for Horde to override the default 
horde/services location - similar to how it can be done for 
templates/, graphics/, etc. Here's the problem with this, though - 
there's a whole bunch of code in services/ that relies on the rest of 
Horde being where it thinks it is. So we'd have to add a whole bunch 
of Horde-finding logic for that to work correctly.



It doesn't really seem worth it to me, from the options I see 
(essentially making services into its own "application"), but 
hopefully that at least points you in the right direction if you're up 
to continuing to pursue a patch.
Okay, you lost me again here. What inconsistencies are you talking about?

Ahh... Here's something I forgot.



For certain values of "CMS system", you have to add in each individual 
page that you want to run through the CMS in, css.php, and 
javascript.php have been added in, as they are PHP files, and can 
easily be included in the (PHP) CMS (although without top, left, 
right, bottom borders), which kind of makes sense, but to invoke the 
PHP CMS for non-PHP files, such as .js, .gif, .jpg (especially when 
they are isolated in their own directory), doesn't make sense 
(overheads etc), hence I'm asking for configuration options for them 
to be able to be elsewhere in the web/filesystem tree.



In the circumstance I'm working on, none of Horde is inside the apache 
webroot, but some of it (the non-library .php files) is inside the 
"cms webroot" (sometimes outside the apache webroot, but world-visible 
through the CMS), by virtue of the CMS's own translation, although 
copies of the graphics have been taken from the horde system  and put 
into the apache webroot, so they can be accessed directly by apache 
without CMS intervention/translation.



However, it is my perception due to the prior bug comment, that the 
/services/editor/htmlarea/ stuff cannot currently be moved from the 
current horde root into the apache webroot (therefore accessible 
without invoking the CMS), because the rest of horde is not there, and 
there is no configuration directive to do so, as well as 
inconsistencies(?) in the code about how the directory they are in is 
referenced (which make it difficult for me to come up with a patch of 
my own). That's the problem.



K.

Yes.
Okay, I can understand the confusion 100% here, lets get that 
straight. This project (the client's CMS, and integrating up-to-date 
Horde) has done my head in more times than I'd care to mention, so of 
course I am well aware of the confusion here...



Apache filesystem webroot is: /webroot/

Apache HTTP webroot is: http://myhost/



CMS filesystem root is: /webroot/

CMS HTTP webroot is: http://myhost/cms/



Horde is installed in, say, filesystems /webroot/, so for the htmlarea 
editor, it's:



Filesystem: /webroot/horde/services/editor/htmlarea/

Inside CMS: http://myhost/cms/horde/services/editor/htmlarea/

Outside CMS: http://myhost/horde/services/editor/htmlarea/



Now, it's not very clever (tm) to force the htmlarea.js script to go 
through the extra overhead of the CMS when there's no need to, so I 
would like to be able to access (without Apache aliasing) the htmlarea 
editor via:



http://myhost/horde/services/editor/htmlarea/

(without involving the CMS)



Instead of:



http://myhost/cms/horde/services/editor/htmlarea/

(which involves the CMS overhead)



I can do this with images by just copying the graphics directories 
into the URL path http://myhost/horde/graphics/ and the same for the 
respective application's 'graphics' directories, adjusting the path 
accordingly, and adjusting the 'graphics' portion of horde's 
registry.php, of course.



However with the /services/editor/htmlarea there is no such option in 
registry.php, nor anywhere else, and this is further confused (*) by 
the intermittent use of javascript.php (varying calls to 
addScripting() or whatever the function is called), so I'd like the 
/services/editor/htmlarea to be adjustable in a similar way to the 
/graphics/ directories in order to aid integration into CMS systems.



The idea being that, whether or not 
http://myhost/cms/services/editor/htmlarea (within CMS) and 
http://myhost/services/editor/htmlarea (outside CMS) share the same 
filesystem path, or not, the ability to configure which of the two is 
used should be there, as different CMS systems have different 
requirements in that respect. The one I'm working on requires the 
ability to Horde to be outside the filesystem webroot, whereas others 
require, or at least allow horde to be in the filesystem webroot.



K.



*) lib/Horde/Editor/htmlarea.php, lines 28 & 29, what's that about?



PS. The /cms/ addition for in-CMS URL's could use PATH_INFO to rewrite 
the filesystem path well out of the standard webroot! So if you set 
the 'webroot' registry parameter for something, you can't rely on the 
CMS translation being there to make it work, or the non-CMS version 
being in the actual webroot, hence some extra config is needed to make 
the process easier without resorting to Apache aliases, thereby 
complicating the Horde install process in such cases.

So, am I correct in thinking that you want to be able to relocate the 
services/ directory independantly of horde/? I'm sorry, I'm having a 
hard time figuring out what exactly you want to be able to put where, 
and what *is* in the webroot still (aside from graphics) - things like 
css.php and javascript.php have to be, right? Etc.



The primary goal of Horde is to be a good framework, obviously; I want 
us to be able to play nice with other software when it makes good 
sense and doesn't go counter to the rest of Horde. So that's why I'm 
trying to make sure I exactly understand the need here, to see what 
kind of solution would make sense for what you need while fitting in 
with Horde well. Sorry if I'm being a bit slow on the pickup.



If you wanted to mail me privately about the ongoing work, I would be 
curious to see it.

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.

Changing the summary to read services/editor, not scripts/editor, 
since there is no scripts/editor/ directory. If you meant something 
besides services/editor, then perhaps I'm misunderstanding you, though.

I agree with Jan; you can move the actual files in 
templates/javascript out of the webroot, but /services is really 
intended to be inside the webroot, and pretty much has to be. I'm not 
sure how that could be designed around aside from apache aliases - how 
would put js that needs to be served to the user outside the webroot?



If you come up with suggestions, feel free to add them to this ticket later.

I am not sure it really makes sense to make this configurable. The 
purpose of the service/ directory is to be available to all users. 
Your requirements are really specific ones and can be solved with 
Alias settings as you found out.

An Apache "Alias" adequately fixes this (hey, I needed a hack to make 
it work), but IMHO it should be an option within the Horde framework.

It ties in with the other bug ID I mentioned, with regards to making 
Horde tools integrate with Giapeto and other CMS-es.



In the implementation I'm working on, there are only two more "bugs" 
which are stopping it from going live inside this CMS, both of which 
relate to services/editor/htmlarea.js in the Horde system.



In this setup, they are outside the normal webroot, and hence are 
generating a 404 error, which has the knock on effect of causing 
Javascript errors, thusly (using Mozilla JavaScript console, edited 
for client confidentiality):



Error: syntax error.

Source File: {snip}/services/editor/htmlarea/htmlarea.js



Error: HTMLArea is not defined

Source File: {snip}/services/javascript.php?file=htmlarea_lang.js&app=horde



Error: HTMLArea is not defined

Source File: {snip}/{snip}/mail/compose.php?uniq={token snipped}



This comes about (I think entirely, but maybe just in the first 
instance) because htmlarea.js can't be loaded because the Horde tree 
is outside the CMS, aside from the contents of the application 
graphics (which I do have the option to put there), but because 
there's no config option to put the scripts there, and I can't really 
put the javascript inside the horde tree visible to the web either, 
it's a bit broken.



So I guess it's more a feature request to put a registry.php option in 
there so we can put the scripts somewhere outside of the horde source 
tree.



I'd hack it myself, but I'm not sure where to start (although I think 
hacking addScriptFile[?] in the Horde libs would be the place), and if 
I did, it would probably disagree with the "horde way", and since 
Chuck has asked if I can write a Horde-inside-a-CMS HOWTO I'd rather 
check with you guys about how this would be implemented too.



K.

Can you please use a few more words to describe what error you are 
experiencing under which condition? Or what to expect to happen that 
doesn't.

Similar to bug #626, may cause problems with Giapeto in future?



It causes javascript errors in HTML composition when you get a 404 
page instead of the expected webroot-based location.



This manifests itself nasily in IE, but I hadn't noticed it in Mozilla 
or Opera.



Trying to get my head around how best to make this work, but not 
having much luck so far. It seems overkill to have a registry 
'htmleditor' parameter, but I can't think of another way...



K.