When you first visit the TinyMCE website and check out the examples, you see a very advanced editor, in terms of the share number of functions. But as with most software, the real power is what is behind that graphical interface, the structure and quality of the code, the way it can be configured.

If you are familiar with Javascript, and go through the documentation of TinyMCE you will quickly get a smile on your face, when you realize the power of it all, from the way you make plugins, to how the the GUI is rendered and how the window popups are managed. And it is always a rush as a developer to see when someone has made a really good implementation and configuration, when you can see that they have studied the API documentation in order to bend and twist TinyMCE to function the way they want. There is even some that have stripped away all the theme/gui stuff of TinyMCE and only use it as an engine for their CMS directly by using the API.

The challenge as a developer is not to build yourself into a corner, don’t follow a path that ultimately will lead you to producing bad or bloated code. On the last rewrite of TinyMCE a lot of thought was put into how to avoid problems like that, and I think we did an excellent job, the code base feels very solid.

One example of powerful configuration is the valid_elements and extended_valid_elements options in TinyMCE, where Spocke invented its own format that has now spread to other projects, read more about the format on the documentation page.

The same goes for our other products, MCImageManager and MCFileManager, there is so much stuff going on behind the scenes in these products its crazy, we even implemented a form of .htaccess type configuration override (but we call the files mc_access). Means that most of the options you can set in the config.php file, you can also put into mc_access files to control the configuration for different folders. For example, you could make it so that if you upload a file to a certain folder, it re-sizes those images to a fixed small size, but if you upload to a different folder, you get a big image. You can restrict access to even upload, or disable certain functions in certain folders, and much much more.

So, check the documentation, even if you are satisfied with how it works, perhaps you can find some hidden gems that are extra useful just for you.

I am guessing noone has avoided noticing the financial crisis in the news, going through the world like a wave through an arena crowd. Can’t really say we have noticed it on our end though, this month will be a record in visitors for the TinyMCE website, as well as a monster amount of bandwidth being pushed out since we moved examples from the Wiki website to the TinyMCE website.

We certainly do not feel like we will be affected much by the financial crisis, on the contrary, perhaps the IT budgets are more slimmed and that makes companies look for Open Source alternatives, and finding that some of these projects are more structured, more tested and more stable than their commercial or home made version.

Currently we are busy doing major work on the MCFileManager and MCImageManager, planing to release 3.1 final during next week, with major behind the scenes rework of the graphical user interface, as well a few new features. We are also working on a secret new Open Source project we just came up with (stay tuned for that).

We will see what the future holds.

There have been lots of fuzz and development of small rich text editors lately and I think it’s time to comment on the these. I will try to explain why size matters.

Some users argue that TinyMCE is bloated and that it can be written way smaller if we rewrite it using JQuery, Prototype or some other library out there. This is not the case, we have calculated that we would gain about 5% in size for the core API. In other words 5k but we would on the other hand loose the library independence so TinyMCE will not be ported to any of these libraries since there isn’t much to gain. Most of the logic in TinyMCE is not related to normal library things like CSS selection, event handling, dom manipulation these parts are pretty small in size the large chunks of code are related to HTML Serialization, URL handling, browser workarounds for editing and those can’t be found in any library out there.

Another common thing we see is “TinyMCE has to much features that’s why it’s bloated, this other mini editor is just 1000 lines of code”. I just have one thing to say about that, TinyMCE is extensible most of the features are placed in plugins so if you remove all those plugins there isn’t that much bloat anymore. The other thing is that most of the logic in TinyMCE is related to browser issues and quirks none of that can be covered with 1000 lines of code.

We are trying to make a stable editing solution crossbrowser that will work the same and this is a very tricky task and that task will require more than 1000 lines of code. Trust me on this we have developed rich text editors in JS for 7 years so we have came across hundreds of browser bugs over the years. So it’s not possible to make a stable editing solution small and still fix the bugs. Not until all the browsers starts to work the same way and there isn’t anything pointing to that in the near future since there is no good specification on how editing in the browser should work. The HTML5 specification doesn’t really cover this.

The size of TinyMCE can also be dramatically improved if you use the GZip compressor package we provide . It will reduce the size by 70% and reduce the number of requests with a equal amount. So if you think TinyMCE is to large use that component.

There are situations where small size matters more than the browser quirks and the output. And then TinyMCE might be overkill to use this can be comment systems on blogs, forums and other situations where valid output isn’t required since the server will process the content anyway. This is why we created PunyMCE, we call it the bastard brother of TinyMCE. It’s small, extensible but not that competent and it will never be since that’s not the goal of that project. It will not turn into another big editor, it’s focused on small size it’s only 9kb in size.

So my suggestion is to choose the right editor for the right task. If you need an editor for CMS systems or blogs TinyMCE is a good fit since it will try to produce valid XHTML/HTML output and has all the features you might need. If you need something for a comment system and doesn’t care about valid HTML and have a backend that will parse the editors output choose a smaller editor like PunyMCE.

So finally there is one thing I have left to say. Size matters but there are also more important issues to take into account when choosing an editor. Does it have a large userbase, is it extensible, does it have unit tests, good documentation and active community? If I where to choose something other than TinyMCE I would look at FCKEditor or YUI Editor. These other editors also have what you would need for serious production usage, the smaller ones don’t.

TinyMCE is not always the perfect match if you need something really small and simple. TinyMCE is designed to be a CMS editor and it has all the features that you might need for such a task.

Some times you want something really small and simple for example on a forum or comment system. This is where PunyMCE comes into the picture it’s designed to be small and simple but yet extensible. It comes with a number of plugins that extend the functionality of the editor.

The size of PunyMCE is “puny”, about 9kb gzipped or 16kb minified. It’s library independent so it can be used with common frameworks like jQuery, Prototype, YUI etc.

But it’s important to understand that PunyMCE is not designed to be an replacement for TinyMCE nor will it ever be. TinyMCE is focused on being a robust CMS editor that produces valid output and takes care of all browser quirks. PunyMCE is focused on being small and simple, it might still have lots of browser quirks and output issues some of these can be corrected by using serverside technology.

This project was a result of a partnership with Freewebs. Kickapps has also joined the project and will help out internationalization.

So check the PunyMCE project out at:

PunyMCE
Google project

I think I have found the answer, noone reads it anyway, if you look at the TinyMCE forum, 75%-90% of the questions have direct answers in the documentation (or even the FAQ), and the replies to it is simple “check the documentation” followed by a “brilliant, thanks!”.

In my opinion, TinyMCE is quite well documented, thanks to ppl helping out and keeping it up to date and free of typos. It has taken a lot of time to make this documentation good, and it feels kinda sad that ppl do not take the time to read it.

Everyone does not have the same way of thinking, but at least when it comes down to solving an issue with a 3rd party software, these are the simple steps I follow.

1. Check the documentation to the product, the readme, install.txt, wiki etc.
2. Try a few different Google querys to find out if someone else has had the same problem.
3. Search in forums/mailinglists etc for a solution.
4. Try to contact someone or post in public forum/mailinglist etc.

Seems like a lot of ppl just skip to step #4 right away.

Well I guess it is better to have than not to have in the end, hopefully some ppl developing more advanced integrations get a lot of help from the API documentation etc.

As you may have noticed we now have a proper logo for TinyMCE.

In other news, we are working hard on a new version of the MCFileManager and MCImageManager, quite a lot of code re-working but not so much on the outside look and feel. Also expect a small update to TinyMCE to correct some minor bugs found in current version.

Also noticed we passed 2 000 000 downloads on Sourceforge since TinyMCE project start, add that to the 1 800 000 downloads of Wordpress (2.6 only) with TinyMCE pre-installed and there is no doubt that TinyMCE is the most popular WYSIWYG editor at the moment.

The last work on our office is currently being done, and the new furniture has been ordered.

There is a lot of buzz going on now about the new Google Chrome browser, and a lot of different testing of its performance against other browsers.

We take performance very seriously, thousands of ppl use TinyMCE every day, it is important that it works smooth on the browsers, not just loading performance, but also the performance of all the stuff that’s going on under the hood when you work with the editor.

So, the tests we have seen online so far have been very wide spread, showing insane performance improvements, but what are they testing? Is there any real-world implications of these performance tests?

TinyMCE uses DOM operations a lot, we have our own test bed, and these are the tests we are running.

• Serializer - This tests the cleanup functionality, a lot of DOM operations.
• Style parser/serializer - Tests a lot of string and array handling.
• URI - Tests a lot of regexp performance, converting URLs back and forth.

And these are the results.

The performance is measured in milliseconds, lower is of course better.

Summary

We could not install MSIE 8 beta on the same machine as MSIE 7, so no tests for that right now. The testing machine is a Windows Vista 64-bit, 4GB ram, 2.66gz Dual Core. Tests where performed with nothing other than the testing browser running.

Safari comes out on top of performance, with Firefox close behind, however we did not see any improvements when enabling the new JIT compiler in Firefox 3.1 Nightly build.

Results vary a bit up and down, but you can perform these tests yourself at this location.

http://tinymce.moxiecode.com/js/tinymce/performance.html

These tests try a lot of different things at the same time, using the TinyMCE API, the performance improvements that the browser developers have been bragging about does not seem to be there, at least not in the areas interesting for most developers (DOM operations).

Unless your living in a cave you probably noticed Firefox 3 was released recently.

The latest TinyMCE release fixes some minor issues with Firefox 3, in general though, it works very well. There are also a few new interesting features in Firefox 3 that can be used by WYSIWYG editing.

For keeping from going insane on the location toolbar, I can highly recommend getting the “Oldbar” addon.

And you can of course get Firefox 3 at www.getfirefox.com.

Now enjoy summer.

We have been users of the Sourceforge system for a long time now, and personally I think that is has been going downhill for quite some time, more ads, more downtime, site is slugish and at the same time, nice alternatives have been poping up. For example, Google Code and if your brave, the Trac system that you can run on your own servers, been keeping an eye on that for some time and it seems very nice really. Only problem is that its made in Python, not to fond of that.

Spocke planned to make a release of TinyMCE today, but Sourceforge has been down almost all day and now the site is up, but the SVN isn’t, so we will see.

There are lots of fuzz around the ability to store contents offline these days. Using Google gears, local storage in the browser, Flash or Silverlight storage. I can see how these storage technologies can be useful for local applications to store user data without using some backend and having things like a local SqlLite database is really neat and handy.

But there have been lots of examples where the scenario is that you for example write to your blog when your laptop is in offline mode then commit the contents ones you get online. I think this problem is short lived since who will ever be offline in the future. We will have full 3G coverage, local Wifi spots all over, Internet connections on planes (some airlines have this already) so I ask my self when will we ever be “offline”.