HTML editing broken if services/editor not a subdirectory of Horde webroot

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

Fri, 01 Oct 2004 13:29:37 +0000

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.

Can you please use a few more words to describe what error y

Fri, 01 Oct 2004 21:38:24 +0000

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.

It ties in with the other bug ID I mentioned, with regards t

Sat, 02 Oct 2004 11:04:23 +0000

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.

An Apache "Alias" adequately fixes this (hey, I needed a hac

Mon, 04 Oct 2004 10:46:57 +0000

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.

I am not sure it really makes sense to make this configurabl

Fri, 08 Oct 2004 09:22:25 +0000

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.

I agree with Jan; you can move the actual files in templates

Fri, 08 Oct 2004 15:04:28 +0000

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.

Changing the summary to read services/editor, not scripts/ed

Fri, 08 Oct 2004 15:06:32 +0000

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.

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

Fri, 08 Oct 2004 15:35:31 +0000

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.

So, am I correct in thinking that you want to be able to rel

Fri, 08 Oct 2004 20:12:52 +0000

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.

> So, am I correct in thinking that you want to be able to r

Fri, 08 Oct 2004 22:52:30 +0000

> So, am I correct in thinking that you want to be able to relocate the > services/ directory independantly of horde/? > Yes. > 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. 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.

> I'm sorry, I'm having a hard > time figuring out what exa

Fri, 08 Oct 2004 23:07:37 +0000

> 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. > 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.

> *) lib/Horde/Editor/htmlarea.php, lines 28 & 29, what's th

Sun, 10 Oct 2004 04:25:35 +0000

> *) lib/Horde/Editor/htmlarea.php, lines 28 & 29, what's that about? I have absolutely no idea what that's for. Jan, Marko? > 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. 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. > 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. Okay, you lost me again here. What inconsistencies are you talking about?

>> *) lib/Horde/Editor/htmlarea.php, lines 28 & 29, what's t

Sun, 10 Oct 2004 09:37:43 +0000

>> *) lib/Horde/Editor/htmlarea.php, lines 28 & 29, what's that about? > > I have absolutely no idea what that's for. Jan, Marko? 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