onchange in ckeditor

I needed to track changes to source in a CKeditor instance, as my recent work uses a lot of “on-the-fly” updating.

Using Alfonso’s onChange plugin, it was a simple matter to capture changes when in WYSIWYG mode.

But that doesn’t work in source mode.

Assuming you’re using the jQuery extension for CKeditor (and if not, why not?), you can capture source mode changes by adding this to your CKeditor’s config.js:

[javascript]
$(‘textarea.cke_source’).live(‘keyup’, function() {
$(this)
.closest(‘.cke_wrapper’)
.parent()
.parent()
.prev()
.ckeditorGet()
.fire(‘change’);
});
[/javascript]

SaorFM

Last night, I spent four hours chatting with Conor MacAoidh.

We’re both the authors of CMSes, and both need file managers.

I’m the original creator of KFM, but recently, I’ve been getting annoyed at it. The project has grown too large to be easily managed, and it’s slow to start up because of the amount of database configuration involved.

We discussed this, and came up with a plan, which coincides with what I wanted to do for KFM2, but is probably much better.

We are going to reboot the whole thing – write a complete new file manager from scratch. It will only use code from the original KFM2 if the code is demonstrably better than any alternative we come up with.

The project will be properly documented, will have 100% test coverage, and will be completely free.

It will come in a number of separate parts, but only one, the core, will be absolutely needed.

The core of the engine is the bit which handles the actual file management. It will be designed to load in only two or three files for the most part, and as fast as possible.

Communication with the core will be done by either including the core as part of your own CMS, or by interacting with it via RPC.

The RPC will be very important – you send a command such as /rpc.php?action=move&from=/my-files/test1.jpg&to=/images/me.jpg, and results will be returned as JSON.

We decided on the name SaorFM. While this may be slightly confusing for non-Irish-speakers (“Saor”, pronounced half-way between “sair” and “seer”, means “Free”), we feel this is not very important. After all, Ubuntu is a household name, and that’s Bantu.

The main site will be SaorFM.org, the blog will be here, and downloads, issue tracker and SVN can be found here.

We’re still deciding on how to go about things, so there are no downloads yet. The decision to do this was made literally last night.

Having a co-developer on board from the absolute start will encourage me to get my arse in gear on this – if Conor does something cool, I have to beat that. And vice-versa, hopefully!

I’m starting the project off at the moment by working on a description of what it’s all about, and then will start writing some starter tests. This will use “test-driven development”, so every single line of code in this project will be repeatedly tested throughout the development.

We’re planning a load of features, such as desktop-/system- integration for Linux, Mac and Windows, and having totally external UI systems. We even considered going mad and creating a bump-top-like UI for it.

It’s taken me almost a year since planning KFM2 and getting to this.

Part of the reason for the delay is that this is so far removed from the current KFM, that I really didn’t know how to bring KFM1 up to the specification I wanted to reach.

Starting from absolute scratch with a brand new name is the right thing to do, I think.

KFM 1.4.2 released. now with CKeditor support

kfm

KFM 1.4.2 has been released. It’s a minor maintenance release, but it adds support for CKeditor. TinyMCE and FCKeditor have been checked as well.

demo using CKeditor

This release also adds a configurable restriction, where images larger than a certain resolution will simply not be allowed in the repository.

Very large images can cause servers to crash when the system tries to generate thumbnails, because of the large amount of RAM needed. For example, a 3000×2000 image will use up at least 24MB just to hold the thing in memory, and much more to handle the manipulation. 24MB is a large amount of RAM to a web app.

There are also some code additions which are not used by the KFM GUI, but can be used by tools that hook into the KFM engine. These allow uploaded files to be placed in directories specified at the time of upload, or to replace existing files, or even to take an uploaded image and apply HSL transformations to it (when ImageMagick is installed). These are not documented, but anyone that needs this functionality will be a good enough programmer to read the source and find it (or email me 😉 ).

Download KFM 1.4.2 here

KFM2: the beginning

KFM 1.x has reached the end of its development. It has fulfilled its original purpose; to improve on the default file-manager for FCKeditor, and well-exceeded it.

From my records, I can see that KFM has been installed on over 9000 separate domains. That is quite a lot of sites, and says quite loudly how important it is that KFM2 is at least as good as KFM1 (we all know about the KDE4.0 fiasco…).

KFM2 will blow KFM1 well out of the water. It will do everything that KFM1 does, but much quicker, and with a much less monolithic architecture, allowing it to be hugely flexible. I am planning on creating a download section similar to jQuery UI’s, where you can choose the components that you want in the system, and it will be built up and configured for you, ready for download.

See, KFM 2 will be modular. If you just want a simple upload/download facility, then you will only need the core, and plugins to handle uploads and downloads. If you want the whole shebang, you will find plugins for various ways of selecting files and directories, full-on graphical UIs such as the existing KFM1 forces on the user, plugins for hooking into external file systems using FTP or whatever other method people can imagine, plugins for multi-media, file editing, databases, user authentication, search, RSS, and so on.

Basically everything that KFM1 already does, but with the option to easily remove/add bits that you want. Make it as fast or as “bling” as you want.

KFM2 will have a number of new things which are not available in any other online file-systems, that I know of.

new file-system things

The file system will be modular. You will be able to attach symbolic links to any part of the file system, linking to other external systems.

As an example, let’s look at a URL: http://example.com/kfm/get/images/site1/logo.jpg.

One of the new ideas is that this will not necessarily be located on the server named example.com.

If you are running a very busy website, you might prefer to delegate image management to a different machine deeper in your network, so you add a symbolic link /images/ linking to the image-management machine. This causes the server to issue a redirect to the browser, redirecting it to http://images.example.com/kfm/get/site1/logo.jpg.

Now, imagine that the image management server doesn’t host the logo.jpg file on itself. Maybe it’s one of a number of images.example.com servers in a load-balancing cluster, and the file is actually located on a file-server accessible only by FTP. So, we add a symbolic link in the server’s KFM, telling it how to connect to the FTP server. The image server does this, gets the required file, and sends it to the browser.

This sounds a bit complex, but at least it’s possible with the new system. The old system simply would not be able to handle that at all.

API

At the moment, if you want to select a file or directory, you fire up KFM1, wait 15 seconds for it to finish booting itself up, and select the file or directory. That’s way too long. Really, you should only need to load up a tiny widget that’s designed specifically for picking a file.

The new system will have a simple core with an API that can be connected to by little JavaScript widgets. As an example, let’s say you just want to get the file-listing for the foo directory.

At the moment, you need to go through the whole business of booting up KFM’s GUI, navigating to the right directory, then waiting for the server to connect to the database, generate thumbnails and other unnecessary stuff.

You should just have to do something simple like load up http://example.com/kfm/rpc.php?a=get_file_listing&v=/foo through jQuery’s $.get() function. The RPC script does exactly what was asked, and nothing more.

This should allow us to write some incredibly fast and tiny scripts for all the file manipulation things you could possibly want.

Think of it as the “gnu” way of doing KFM – many small tools, each of which is designed to do one task well.

Of course, you will still be able to use the original GUI with this, after it’s been re-engineered to hook into the new RPC system.

Or, you can write your own – the RPC’s API will be well-documented, and will use simple HTTP parameters, so you can write your widgets in whatever language you want – JavaScript is what I will be writing in, but there’s no reason why you’re confined to that – write a GUI in Python, C, Flash – whatever you’re comfortable with.

plugins

I think the new plugin architecture will make this profoundly extensible. I’m writing the core to be as flexible and stable as possible. You will be able to write a plugin to just about anything:

  • authenticate a user before serving a file.
  • change a user’s root directory based on the server-name or the user’s authentication.
  • the entire system is held on a different machine accessible only by FTP? fine – let’s change how files are accessed.
  • record all files and directories in a database, allowing searches to be done.
  • manipulate files online – edit text files, rotate or crop or resize images, move or rename or delete, etc. standard KFM1 stuff, these.
  • create a log plugin, so all access is recorded.
  • create a quota plugin, for denying uploads or downloads when the quota is exceeded.

It was possible for us (Benjamin and myself) to write all of these into KFM1, but as we are only two people, and very busy people at that, it’s never been the absolute top priority to get all these things done.

But, when KFM2 is released, you won’t have to wait for us anymore. You will be able to write plugins, or download plugins created by other people, which do all of the above and I’m sure there will be plugins that I simply have not imagined yet, that inventive people will come up with (Conor, I’m sure you’ll be one of those!)

languages

Languages have always been one of the cool things about KFM. Version 1.3 was released in about 13 languages in total. Unfortunately, the code got too complex in 1.4 to easily add more, but KFM2 is starting from scratch with the learning-curve of KFM1 well behind me. I’ve already made most of the big mistakes I’m likely to make, so from now on, things should be much easier.

How languages will work is that a website will be created which allows people to help out open-source projects, not just KFM by providing translations of words and sentences.

The programmer will create a screen-shot showing the text in use, and will provide the untranslated text in a format such as .po. Translators will translate the text on-line, and the translation will be available to download by the programmer as soon as it’s done.

To ensure good translation, each line will be presented to a number of different translators. The translations which agree the most with each other, will be considered the “right” one.

Using this, it will be possible for KFM to organically add languages with no interaction from myself or any other programmers. When first loaded, a plugin would try to translate messages into the user’s language. Finding that it doesn’t have the language in its database, it will try downloading it from the language translation website. If it’s not available, a request will be added that it be created. When translators that speak that language come to the website, they will be automatically given the KFM text to translate to that language. The next time the plugin checks, the translation might be done, and it will be added to the KFM instance’s local language database.

Of course, people don’t just do this stuff for the hell of it. It’s more fun if there’s a competition or reward. It would be nice if I could get a few paying customers to add their own translation requests to the website – that way I could offer a reward to the best translators (those that do the most work, or are the most consistent).

The competition aspect comes in, where you give people points for every translation they do that is matched by someone else’s translation of the same text.

Google does a similar thing, for example, where it shows images to people and asks them to come up with keywords describing the image – the commonest keywords are considered to be correct. Same trick, different target.

Anyway! Without further ado, I have a core to design, and tests to create. I was going to talk about testing with PHPUnit, automatic upgrades, and the like, but to hell with ye all – I’ve work to do 😉

webme: admins, frontend editing, KFM, and comments

I’ve done a bit more updating of the WebME code.

I realised I’d forgotten to add some code to create the first admin. That’s fixed now – just go to the admin area. If there are no existing admins, then the first attempt to login will create a valid user account.

You can insert images and stuff now through the FCKeditor in the Pages section. The file manager used is KFM.

When you create/edit a page, see the Advanced tab, where there are a number of options. You can set a page to be hidden from the navigation menu, you can set any page to be the front page, and you can also set a page to allow public comments.

The public comments thing is interesting, I think – I wrote it using a combination of AJAX and some verification tricks. On all the sites that it exists, I have not seen a single spam comment (but now that the challenge is out there…).

If you have logged in as someone who has Admin rights, then you can edit pages directly from the front end just by right-clicking on the page. Choose “Edit Page” and you’ll be able to write directly into the page. Right-click outside the editable area when you’re done, and choose “Save Changes and Reload Page”.

As usual, you can grab the code here: Webworks WebME SVN checkout. I think we’re just about at the point where a proper package will be useful. That will hopefully be provided tomorrow, depending on time.

And now for some news – I’ve been discussing making this into a free service with John (webworks‘ head honcho), and we’re going to go ahead with it. The idea is that you will create your own website on our hosting platform, get some basic services free, and will pay for extras if you want them (domain names, SMS services, etc), but there will be /no/ pressure – if you just want a simple website with an easy-to-use CMS, then that will be available for free. The great thing about this is that the system will be upgraded very often, with new services coming online as they’re finished, and you, as users, will have input into what gets worked on.

fckeditor+firefox 3, lcd vertical lines and missing sound

FCKeditor

If your project uses FCKeditor, then you may need to re-think how the FCKeditor instance is attached to the page – Firefox 3 has changed something (I’m not sure what) which causes FCKeditor to fail in some cases (not all).

The cause is not absolutely clear (the first bug mentioned above states that it relates to loading file:/// URIs, but in my case, that’s not true), but I have managed to fix a few cases by avoiding the dynamic method of on-the-fly initialising FCKeditor (var o=new FCKeditor('blah');o.ReplaceTextarea();, etc) and instead creating the required IFrames and hidden inputs manually. This is a hack – not a true solution, so hopefully someone at the source (FCKeditor) will fix the problem soon.

This bug in their Trac is probably the exact problem I’m experiencing. Note that that bug was “confirmed” by a member of the dev team 9 months ago, and has since been ignored by them.

LCD vertical lines

A few months back, my Acer Travelmate 2420 started developing vertical lines. It would have been expensive to replace the screen, so I instead opted to go for a new machine. I gave the machine to my son Jareth, who doesn’t complain too much about it.

Yesterday, while troubleshooting a sound problem, I noticed that if the screen was twisted /just so/, then the lines vanished. After a bit of experimentation, I found that pressure applied in a certain spot at the back of the screen would clear the lines.

So, there was no other option – I needed to fix it. I got my screwdrivers out, took the screen apart, and MacGyvered a solution together with some paper I had lying around – fold it into a thin strip, then fold one end of it down to form a bulky part, then slot that into place between the screen and the back cover so the bulky part is at the pressure point. When the cover was replaced, the vertical lines were gone.

I have no idea how long the solution will work for, and I am guessing that the solution is causing stress to parts of the screen which may cause a more complete failure at some point in the future, but for now, Jareth is very happily watching a DVD on his machine (Bear In The Big Blue House – Shapes, Sounds And Colours on Fedora 9, KDE4, for those interested).

Missing sound

As stated, Jareth’s laptop had a sound problem – as in lack of sound. this was eventually traced to pulseaudio simply not starting. The solution was to add pulseaudio --system & to /etc/rc.local so the sound engine would start when the machine started.

fckeditor vs tinymce vs everything else

A few questions for the webdev community – especially javascript coders

Which is easier to use, FCKeditor or TinyMCE? Which is less buggy? Which has the better developers? Which is easier to extend? Are there better editors out there?

I’ve been working with FCKeditor for the last few years, and am getting a bit tired of it.

Almost two years ago, I extended their file manager by providing the ability to delete files or rename them. I submitted the code back to them, and …two years later, you still can’t delete files in the FCKeditor file manager.

Yesterday, I discovered that FCKeditor’s HTML-standards are a little restrictive – it assumes the code will be directly embedded in either the <body>, <noscript> or <blockquote> element. This means that the following code is illegal according to FCKeditor, even though it is legal according to the W3C specifications (if embedded in, say, a <div> element):

<p>some text</p>
<img alt="" src="http://www.fckeditor.net/images/logos.gif" />
<p>some text</p>

I have written some pretty complex code for FCKeditor in the past, including the ability to drag elements from an external list into it, and the ability to create and destroy instances pretty much on the fly, for AJAX apps.

The last paragraph is probably the only reason I am wary of swapping to another WYSIWYG like that *snaps fingers*. I don’t look forward to having to rewrite that functionality – it was hard enough in the first place…

However, today, I spent hours trying to track down a reason why plugins were not loading even though the rest of FCKeditor was. I’m preparing to jump ship now. It’s just too exhausting fixing this editor. I’d prefer to work on a simpler, more robust editor.

I’m tired of its bloat and slowness and am asking you all out there in the web world to tell me what you use, why you use it, and would you recommend it.

KFM 1.0 released

Today, I released KFM 1.0, a web-based file manager powered by php/ajax with mysql/postgresql/sqlite.

This is an important release for me, as it marks the completion of the original feature-set that I had in mind when I first started the project – match and exceed FCKeditor‘s default file manager, and provide extras such as multiple file upload and tags.

I was considering giving this a rest for a while before starting on version 2, which will have a lot more “desktop” tricks in it – different view modes, live streaming of videos, vector graphics, plugins – but I feel energised right now, so may just get to work on it.

ohloh considers this project to be worth about $889,277, and you get it for free, so please download it, try it, and comment about it.

KFM 0.8

function getKfmFile(version){
window.SetUrl=function(value){
value=value.replace(/[a-z]*:\/\/[^\/]*/,”);
document.getElementById(‘filename’).value=value;
}
var lang=document.getElementById(‘lang’).value
window.open(‘http://kfm.verens.com/demo/0.8/?lang=’+lang,’kfm’,’modal,width=700,height=500′);
}

Demo English
Bulgarian
Danish
German

Spanish
Finnish
French
Irish
Italian
Dutch
Romanian
Russian

Browse…

download it at the KFM website

New Features

  • New language: Romanian (thanks to Andrei Suscov)
  • Return thumbnails to the opener (35, 142)
  • Tag engine (12, 13, 143), allowing files to be categorised, and searched by category.
  • Client-side syntax highlighted text editing (125, 126) using CodePress.
  • Rename multiple files (103). This allows you to select a group of files, and rename them all to a common format.

Improvements

  • Multi-line captions (89)
  • ImageMagick used where possible (152, 111), allowing huge images to be edited without PHP running out of memory.
  • KFM will return either a normal URL (155), or a URL which allows the get.php script to be used to retrieve the file. The advantage to using get.php is that in the future, we will be able to apply authentication, so only authorised users can read a file. This also allows thumbnails to be built on-the-fly.
  • The database tables can use a specified prefix now (129).
  • Double-click can be configured to either send the file back to the opener (FCKeditor, your CMS, etc), or to open the file directly (120).
  • config.php split into two files, allowing easier upgrades (146).
  • when moving through files with the arrow keys, the selected file will always be visible (110).
  • KFM can now be used to manage multiple sites through one instance (154).
  • A metrics logger has been added (134). This will allow us to know what versions of KFM are in use, and whether it is safe to deprecate certain features if need be.
  • Comments can now be extracted from .gif files to be used as captions (88).
  • Documentation written on how to transfer a KFM archive from one machine to another (161).
  • Many bug fixes (159, 97, 156, 149, 68, 157, 147, 148, 144, 102, 145, 118, 140, 141, 98, 139, 135, 150, 151, 165, 167, 164, 162, 160, 113, 163).
  • Some ideas were rejected (112, 21, 131, 19, 18).

As usual, this release has been helped along by the many testers in the forum, testers who have contacted me by email, and all of the translators.

Very large thanks to Benjamin Ter Kuile, who has been very actively hacking away at the KFM code and produced such gems as the CodePress integration.