I'm sorry but I don't understand what you're asking.
Dan O.
------------------
Has anyone been able to get this working with htmlarea 3.0? I've been trying but have had less than no luck.
Works great with 2.x but I want to be able to use non-IE browsers with my calendar. 2.x doesn't let me. 3.0 is supposed to support browsers like Mozilla.
Thanks,
-Gary
Let me remember what I did, I may forget a step!....
Extract htmlarea V3 into the htmlarea folder as per the old version.Note that the name of the file has changed from editor.js to htmlarea.js. So you can either make a copy as the old name, or just update the HTML source to point to the new filename e.g. within the add_edit_event.html admin template:
<script language="Javascript1.2" src="/htmlarea/htmlarea.js"></script>
Then the other change you need to make is because the new htmlarea needs the following onload javascript command in the BODY tag: HTMLArea.replaceAll()
e.g. my BODY tag in the template is: <BODY onload="HTMLArea.replaceAll()" BGCOLOR="<%=$AdminConfig->get("page-background-color")%>">
And that should just work. Let us know how you get on.
Cheers,Ben.
Thanks for the reply. I made those two changed to my add_edit_event.html file, and when I click on "Add Event" I get a window with the following error:
WARNING: _editor_url is not set! You should set this variable to the editor files path; it should preferably be an absolute path, like in '/htmlarea', but it can be relative if you prefer. Further we will try to load the editor files correctly but we'll probably fail.
It then takes me to the add event screen where I can enter a title and description, just no WYSIWYG stuff.
Here's the code that contains the _editor_url:
================================</SCRIPT>
<!-- START : EDITOR HEADER - INCLUDE THIS IN ANY FILES USING EDITOR --><script language="Javascript1.2" src="/htmlarea/htmlarea.js"></script><script>// set this to the URL of editor direcory (with trailing forward slash)// NOTE: _editor_url MUST be on the same domain as this page or the popups// won't work (due to IE cross frame/cross window security restrictions).// example: http://www.hostname.com/editor/
_editor_url = "http://acadia/htmlarea/";
</script>
.....
<BODY onload="HTMLArea.replaceAll()" BGCOLOR="<%=$AdminConfig->get("page-background-color")%>">
================================
(FYI: "acadia" is my internal test server. Htmlarea 2.x works fine on this server with the Calendar).
I also tried using _editor_url = "/htmlarea/"; and got the same error. I tried it in both IE and Firefox and got the same error (at least they both act the same now! :-).
Sure there weren't more mod's you had to do? I was hoping it was gonna be as simple as modifying a couple of lines, but in my case it appears it's not enough.
Thanks again for the help.
Hmm I'm racking my brain to see if I have missed anything...
Just looking at my version of the script in the add_edit_event.html, it looks like this:
<!-- ---------------------------------------------------------------------- --><!-- START : EDITOR HEADER - INCLUDE THIS IN ANY FILES USING EDITOR --><script>// set this to the URL of editor direcory (with trailing forward slash)// NOTE: _editor_url MUST be on the same domain as this page or the popups// won't work (due to IE cross frame/cross window security restrictions).// example: http://www.hostname.com/editor/
_editor_url = "/htmlarea";</script><script language="Javascript1.2" src="/htmlarea/htmlarea.js"></script><style type="text/css"><!-- .btn { BORDER-WIDTH: 1; width: 26px; height: 24px; } .btnDN { BORDER-WIDTH: 1; width: 26px; height: 24px; BORDER-STYLE: inset; BACKGROUND-COLOR: buttonhighlight; } .btnNA { BORDER-WIDTH: 1; width: 26px; height: 24px; filter: alpha(opacity=25); }--></style><!-- END : EDITOR HEADER --><!-- ---------------------------------------------------------------------- -->
the htmlarea folder is in my webroot, but notice that I don't have a trailing slash, even though I know it says you should include it! Give this a try, it could be the missing tweak that I forgot..:-)
I figured out one problem right about the time you posted. In my original 2.x version of add_edit_event.html I had the javascript call to htmlarea.js before the definition of _url_editor.
Notice in what you sent _url_editor is set BEFORE the call to htmlarea.js. Well, flipping those got rid of that error. Hoorah!
Now I've discovered another oddity. I'm not sure if this is htmlarea/calendar related or Firefox related. With 3.0 htmlarea I am able to add an event in IE. With Firefox I see the WYSIWYG editor in Add Event, can type in text, change font, size, bold, etc... everything seems to work great. I set the schedule then add the event.
I went in and approved the event and saw that the Description wasn't present. If I look in my events.txt, it shows the description when I added an event in IE, but not for Firefox:
12 3.0 test with IE <P> </P>\n<P><FONT size=3>This is another test</FONT> </P>\n<P><STRONG>1 2 3 4 5 6</STRONG> </P> anonymous Anonymous User 1097848274 0 113 3.0 test with Firefox anonymous Anonymous User 1097848387 0 1
I'm not sure if this is a problem with how I've implemented 3.0 htmlarea or with my Firefox. I'm using Firefox 0.10.1 PR. It's the latest-and-greatest Firefox; I'm wondering if it's not compatible with this htmlarea.
Huh, just tried adding an event from my Linux box which is running Mozilla 1.4.2. Same problem as I had with Firefox. The actual event description was never added to the events.txt:
14 3.0 Test with Mozilla 1.4.2 anonymous Anonymous User 1097848956 0 1
Pretty curious. Ben, you say you can add an event with Firefox and later see the description when you view the event? If so, what the heck am I doing wrong?
Ah ha! yes I remember now, there does seem to be a bug of some kind with this - the users have not complained about it since I showed them the workaround, so I actually forgot all about it!
The way to do it is once you've entered your text and set the bold italic etc, switch in, then out of html view. (the <> button on the toolbar). Then saving your changes will work. I guess the bug must be in htmlarea, I suppose I should have logged it with Interactive Tools but as I say I forgot all about it!
I tend to agree with you that it seems like an htmlarea issue. I'll try to contact the interactivetools.com people to see if they know about this and if there's a fix for it.
Now I just need to add a "Firefox browser users read this FIRST" link on the Add/edit pages so they'll know about the workaround.
Thanks again. I really appreciate it!
quote:How'd you ever stumble across that workaround?
I think after a lot of cursing and pulling my hair out! :-)
Thinking more about it though, it would be a very fundamental bug if it was an htmlarea problem, so I wonder if it's a problem with the implementation.It seems a lot more complicated than the V2, so maybe it's just something else that needs adding to the HTML code, as I only got this far by trial and error! The Forum at interactivetools.com seems pretty good, so it might be worth asking on there.
If you do find anything else out then let us know!
thanks....
Customization