New editor tools module for Phorum 5.1+

It's generated code, which represents language strings and module configuration in JavaScript. There's no need for the JavaScript code to be like a nice book to read. If you do not like it, then feel free to do things differently, but please refrain from comments about being "disgusted". That's a quite rude remark IMO.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

I am not talking about nice book to read, I am talking about internet traffic. Do you understand if you include in every page inline style definition like this

   <style type="text/css">
    Extremely long useless paste deleted by moderator      
    </style>

You will waste every page view of your page about 17 kB of server traffic? If your forum use e.g. 1000 users per day, every user makes 21 views, thats 17x20x1000 thats about 332 MB of traffic which can be reduced to 0 bytes using external style declaration. Phorum source code is very professional so I dont understand why there are basic bugs like this. I repaired style declaration from inline to external in almost short time, but now same thing with the inline javascript declaration of editor tools. It seems its much harder repair it.



Edited 1 time(s). Last edit at 04/30/2007 07:29PM by mmakaay.

thats not a bug, its intentional for easier changes and additionally there is a script in the scripts dir to make a static css from it if you need that.
you can change template to whatever you like btw..

---

Thomas Seifert

Quote
ts77
intentional for easier changes

What do you mean exactly? :)

Please do not hijack this thread for this discussion. External vs. embedded CSS has been discussed before on the forums more than once and it's in the FAQ too. This topic is only about the editor tools module.

Like I said: there is generated javascript code for the editor tools, which represents the configuration settings. Because it is generated, it is put in the code and not in a static file that is included. Phorum has no way to write out dynamic files to the webroot, where they could be linked as static files either. That is because writing dynamic files to the webroot is a huge security risk on any web based system. Of course you could change the code to do so anyway, but we won't include that code in Phorum because of the risks involved.

Another way to handle this, would be to let a separate script generate JavaScript code, which the browser can cache. So dynamic code, which is cached by the browser. Here we touch the CSS inclusion discussion. If I would do that, then there's a big chance that changed settings in the module settings screen would not immediately be propagated to the editor tools interface. You can probably imagine that this behaviour would bring up numerous false bug reports. Some browsers would need restarts to see the changes in the settings.

Overall: if you do not like the default behavior of the module, then it is kind of bad luck. All the code is written with design descisions in mind. It's not mindless hacking around. The things you mentions as bugs defenitely aren't. If you want to, you can copy the javascript and css code for your desired setup in separate files and include those in the header. Then hack the module a bit to not put this code in the page.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

I think caching of CSS is not bad idea, because it will save traffic, and I think that Phorum admin will not change CSS x time per day.. But the JS thing, I deleted the new Editor tools module, because I am not able repair that code, its too much difficult.

Simply its not usable unfortunately. That inline scripting is terrible.. however it looks fine, I mean in the browser.

Stop calling it "repairing" please. You not understanding the code makes you a very bad judge of it being broken or not.

If bandwidth really is that much of a concern, then be sure to disable all images on your site too (I asume you have zero images on there?) and to use gzip output compression on the webserver. You can also move all the inline CSS code out of the page, by modifying the templates. Change the {include css} to whatever you like to do to make the CSS external.

As far as the Editor Tools are concerned: a lot of the javascript code is in fact outside the page. About 1700 lines of javascript. So stop making it sound like everything is dumped mindlessly inline in the page. One change that I have planned is to move the data to JSON formatting, but that doesn't change the fact of it being in line.

To conclude: I don't see what you are trying to aim at here, but I doubt it is Phorum developer goodwill :-/

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

It's quite staggering that unpaid, voluntary developers can release a product as good as Phorum, then do more work on excellent free modules and still get rude, ungrateful and ignorant comments from a vocal minority of the community.

test444, perhaps you would be so kind as to release your own useful modules to the Phorum community, as a way of saying "thanks"?

Now, in a thinly veiled attempt at getting this thread back on-topic, Maurice, have you seen this post?
I personally see the future of Phorum as having the option of a WYSIWYG editor - and integrating that with the smiley support from the Editor Tools Module would be the icing on the cake...

/\dam

--
My notable Phorum sites:
Movie Deaths Database - "review comments" system mostly powered by Phorum
Learn Chinese! - integrated forum quiz

Yes, I saw that post. Wysiwyg would be a cool module indeed, but as you also found out yourself, there are a few details which might give us a hard time implementing it. Also, I don't know if Phorum's bbcode is fully compatible with it (I think we have some slight differences in the bbcode features when compared so some other bulletin board system).

One thing that might give problems too, is modules that implement extra bbcode features. I'm about to write a module that implements a [spoiler] bbcode tag, which will hide a part of the post for the user, until the user clicks on a link to show it. That would be easy with Editor Tools, but in a wysiwyg environment, I don't know how that would have to be implemented without confusing the user.

But hey, I'm counting down on your "at least three weeks" and are really curious for the module that you'll write ;-)

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

Quote
mmakaay
be sure to disable all images on your site too (I asume you have zero images on there?)

Maurice is very sad when you as the html developer dont know, that browsers cache the images automatically. So just one load of the images is needed. Same thing with external CSS and may be with external JS I think.

Thats all, may be your development team is so rich that you dont need think about server traffic etc, but I am just trying tell you, that using CSS or JS inline, when it can be used external is bad thing.

If you claim "Speed Comes First" stop serving the unneeded bytes in form of inline CSS or JS. Thats all, you know? However I am using Phorum because I like it. But I wonder why Phorum developers knows nothing about external linking. Every better HTML developer uses rather external linking, because he knows its better.