The New Territory

Asus Eee Pad Transformer

2011-12-25T13:16:00.001+01:00

These days I'm testing an Asus Transformer (the first version, not the new "Prime") in order to check the viability to use it as a kiosk display.

Currently it's much simpler and cheaper to provide the clients or visitors a touch screen so they can query information or perform some basic tasks thanks to all these new tablets, but the fact is that it could be even cheaper and more powerful. I'll write a separate post about that with all the things that I have in my mind.

I'm gonna try to focus this little review on the things that I've found so far, at least as a serie of notes to myself so I can remember these details some months from now.

The client wanted basically a touch screen that could be used to access a single site by the customers so things like GPS, bluetooth or the cameras didn't really matter, but it's usualy better to get a brand name instead of an unknown mix of components that you can't be sure if they will survive 6 months and the quality of those components. And of course, having such a table available means that they could take it home at night and use it for other means if they want to :-)

I've also thought about buying one such tablet for myself, and I was unsure about how I might use it instead of my Nexus One (N1), so this is a good way to test it.

First impressions

I was expecting/hoping for something lighter. I don't mean in any way that it's heavy; not at all, but for myself I was hoping to get a very light tablet and this one doesn't fit that expectation. I wanted something as light as my phone but with a bigger screen, hey, we're free to have high hopes for the future :-) maybe a 7" tablet might be better for my expectations in this regard.

It has a relatively wide bevel around the screen, in a way it can prevent that grabbing the borders will activate the touch sensors like happens in the N1, but I think that other smart touch controlers don't have the same problems as the one in the N1 and even then I bet that you can cut that border in half and still keep always the fingers out of the screen.

It uses a propietary connector instead of mini or micro USB, I don't like that; we all know that in such situations the outcome is that if for whatever reason the cable gets damaged or lost I have to buy it from them instead of being able to use any other one that I have available at home. Other simple reason is that the cable itself it isn't very large so if I connect it to the computer I can't move too much the tablet because it's almost at the full length of the cable.

It seems that trying to charge it by connecting it to a computer it's too slow according to other reviews. I've just connected it to check that but I can't be sure if it's charging or not, I don't see any indication like it happens in the N1 where an orange LED signals that it's charging and when it turns green then it's over 80%. But here there's no feedback about the charging, the only way to know that it has been charging is to wait a while and then look at the battery stats to verify that they have gone up.

I can understand that a power outlet is a better energy source than the USB connector of a computer, but if I buy a tablet I would expect to be able to connect it with a standard USB cable to a computer and then get it to charge at a reasonable speed instead of being forced to carry that special connector and wall plug.

Currently I can't use the tablet because it's charging from the wall and as I said the cable isn't very long so I would have to stay in an awkward position in order to use it while charging. BTW: when charging from the power outlet the Lock screen stated that it was charging, but after the screen goes off there's no LED, the only way to know if it has finished charging is to wake it up and look at the text in the lock screen.

Shortly after booting it up and connecting it to the wifi it downloaded two firmare updates automatically and the next day I performed a check while looking at the settings and another one was ready to install. I think that according to other comments Asus seems to be providing constant updates and that's a very good thing for me as a consumer, I don't want to buy anything from a company that sells a product and the only update that they offer is to spend the money with their new device. If I buy something I expect it to work and being supported for a very long time, I don't like that programmed obsolescence situation created by the big corporations to keep us buying new things.

Back to updates, the Market app notified that there were 4 updates available, although they show the Install button insted of update. I've managed to install/update one of those apps, the other three just open the existing app instead of installing a new version. One of those apps is Google Maps, it has the version 5.10.1 and the latest found with the N1 is 6.0.3. No matter how many times I click on the install button, it always open the current one instead of trying to upgrade it.

Talking about maps, it's quite broken in this version: while using only the maps view it seems to work fine, but after adding the satellite layer it hangs up in a very short time, the map gets frozen and although the buttons seem to accept clicks, there's no dialog, dropdown or anything. The only solution at that moment is to go to the Applications settings and kill the Google Maps process. But the funny thing is that once I launched the maps while in Airplane mode and then I was able to use the satellite view with the cached photos perfectly, zooming in and out, moving, rotating, ... really nice but it's not practical to go into airplane mode in order to use the app :-D

The YouTube application doesn't show the subtitles, although it's able to dim the controls (and clock) in the notification bar so they are a single gray dot . So far I've found that only the Gallery is able to perform this same trick, so using other video players not optimized for HoneyComb might be a little annoying with thosee controls always visible while trying to watch a movie.

The Browser uses the following User Agent:

Mozilla/5.0 (Linux; U; Android 3.2.1; es-es; Transformer TF101 Build/HTK75) AppleWebKit/534.13 (KHTML, like Gecko) Version/4.0 Safari/534.13

It looks more like a Chrome thanks to the full url bar with tabs, and the first thing that it prompted upon launch was to install the Flash Player from the market (I didn't because I don't need it for this project), besides tabs, the browser also supports incognito mode.

contentEditable and CKEditor

I performed a quick test and looked OK, so I used my local copy of CKEditor these are my tests (the tablet is running Android 3.2.1 HoneyComb, the browser doesn't seem to be a version modified by Asus but I can't be sure about that), you can use the official CKEditor demo as well:

The keyboard pops up automatically and the blinking caret is visible. It's easy to write (using always the virtual keyboard, I'm using the default Asus keyboard for these tests), but it's hard to move the caret exactly, there are no cursor keys and you have to rely on touching with your finger in the right point. When I tested in the simple contentEditable test, each time I pressed Enter the keyboard went away, but in CKEditor this doesn't happen, I guess that this is an unexpected benefit of the enter key handler in CKEditor. Another difference is that in the basic test the browser follows the link but in the full CKEditor nothing happens, so I wonder what can be going on here.

It's possible to perform a long press and select the text in the content as well as copy it, but the text can't be pasted back in the document directly. If I press the "Paste as Text" then I can use the dialog to paste in that textarea and insert it back in the document (but of course as plain text). So: No pasting in contentEditable.

Those selection handles don't seem to really work at the DOM level, if I try to select some text and then apply any formatting then nothing changes: the handles go away and the text remain in its previous formatting. It's not possible to format existing content. The problem seems to be that those handles are overlayed on the document, but they don't modify the DOM selection: It's possible to select all the contents with the "Select All" command and the selected text gets a green background, then performing a long touch shows the selection handles that allow to perform a new selection over the existing content that it's already selected. Then clicking the Bold button the first time makes the handles disappear and the second one made all the contents bold as the previous "Select all" was still in effect.

Clicking a format button like bold and then typing works correctly, the text uses the format so it can be used to format new content; but of course you have to be careful to click/touch the right button, the current toolbar isn't designed for a touch screen.

Dialogs can't be dragged around (like iOS), of course the dialogs can't be resized and the tableresize plugin doesn't work. When all those elements are fixed to handle touch events for iOS they should also work in Android. Another point in common is the lack of context menus, this is all part of adjusting the UI of CKEditor to make it touch friendly. Trying to use the divreplace sample also fails, the sample might need to use the proper listener instead of the current doubleclick as that just zooms in-out

The maximize button makes the toolbar disappear making this a very dangerous button.

Some differences with the iOS tickets: I didn't notice any problem typing after enabling SCAYT, the editor doesn't grow, it remains at the initial size, overflow auto seems to work, it's possible to scroll the contents of the editor as well as the toolbar combos

The toolbar combos can be closed , but they don't work perfectly; selecting an option from font size or family works, but it also performs a click on the point where you touch the screen to select the option, so usually the caret moves and you don't get the expected result. The Styles combo is much more buggier, although the contents scroll but dragging them, it seems that somehow the clicks always go to the first items, I always ended with "var" and "kbd" instead of any other style further down.

When a dialog is opened, it puts the caret in the first field, but the keyboard disappears and you have to touch that input to show again the keyboard.

When typing at the end of the editor and pressing enter the caret jumps to the next line, but the content doesn't scroll up automatically so you can't see what you're typing, and when I tried to write something long, it scrolled the first line, but it didn't scroll again after that. When I tested the Google Voice keyboard to talk instead of typing it only inserted the first letter of my sentences.

Using the editor with the default sample pages isn't nice because the editor is placed almost at the bottom of the screen, when you touch the content the keyboard pops up over the current content so you have to scroll now that up (previously it wasn't possible) to see the caret. and whenever the keyboard goes away the document is scrolled back to its original position and a loop begins of keyboard on, scroll manually, keyboard off, auto scroll. And when a dialog opens up you might not be able to use it correctly in landscape mode because the dialog is centered on the screen, it's not possible to scroll it and the keyboard is covering most of the dialog

CKFinder doesn't recognize the browser as a mobile device so it doesn't show automatically the little adjustments introduced in 2.1 and that means that it's not possible to insert images or links to files.

Google+ vs Blogger

2011-12-12T23:15:00.000+01:00

Ok, according to the latest announcement it seems that the aim will be to keep Blogger and use Google+ to share existing content outside and comment on it.

Just a little post to test it :-)

Google Maps plugin with lines and areas

2011-12-03T22:15:00.001+01:00

Version 3.1 of GoogleMaps plugin

Finally after all a very long wait I can say that the Google Maps plugin for CKEditor is ready, it includes all the previous features and uses the latests versions of both CKEditor (3.6.2) and Google Maps (3.7)

As I explained in previous posts the main missing feature was the ability to create and edit lines (paths) and areas and recently Google added this missing API. So after founding a little free time I've included these features as well as checking and testing everything fixing some little problems along the way. (One such problem is that previously I think that CKEditor managed to automatically resize the dialogs to fit their contents, but now they are shown beyond the dialog boundaries. Some people have reported such problems when they try to add a lot of images to the Smileys dialog).

A summary of features

The plugin allows to insert a Google Maps into your pages easily without any previous knowledge.

It's possible to use any size for the map, while you're in editing mode a static preview of the map is shown (if the size is bigger than 640x640 px the image is scaled because that's the maximum size for static maps)

A preview/edit dialog is used to move the map as desired as well as setting the zoom level or various features like map types or available controls.

A search field is available to find the location that you want.

It's possible to add several overlays on the map like markers, text, lines and areas. It's also possible to use a KML or KMZ file to add complex sets of features after creating it with Google Earth for example.

The plugin can generate either static images, normal javascript maps or static images with the option to turn them into normal javascript maps. (the static image doesn't support the same set of features than the full map: texts and Kmls won't be shown)

How to get it?

As explained previously, the price of the plugin is 15 euros for a domain or 50 euros in order to use it with any site that you create. My contact data is amla70 at gmail dot com and the payment can be done with PayPal.

You can pay now after selecting the type of license that you want:

Deprecation of old browsers or bad pages

I would like to use this message to announce that from now on this plugin as well as any other that I develop won't support pages in Quirks modes and versions 6 and 7 of Internet Explorer.

This means that I won't test any plugin in those cases, and if someone reports a problem with such situations then the output might be that I add a check so that the plugin refuses to load instead of spending several hours to find a workaround for such problems.

Of course, the visitor of the page will be able to view the map correctly with any browser (until Google decides to pull the plug for those browsers), but when the admin is trying to edit the content he should use a modern browser and your administration should use a Standards rendering mode.

Write Area 1.1 discussion

2011-10-14T22:14:00.002+02:00

Seems that some people don't like the new integrated mode of Write Area, so I would like to know better what's the problem and what can be done to keep everything simple and useful for as most people as possible.

First, I've added a survey at the side pane. Of course, remember that we are talking just about the textarea replacement; if you're using it to replace an existing HTML editor then this survey isn't for you because there's no integrated mode in that situation. In the survey you should be able to check more than one option if you think that you would use more than one mode if all there were available.

So far the complains have been about the removal of the option to edit in a popup dialog, I didn't read anyone complaining about the removal of the bottom pane and at least that's a good thing. Can we all agree that the bottom pane isn't needed?

Then the dialog thing. Why are you having problems with the new mode and need the dialog back?
Please, write a comment here explaining (in a civilized way) why the integration mode doesn't work for you. I've got one comment about problems in tumblr.com, I'll try to check that tomorrow, although I'm not sure if I'll have enough time as I had planned other things to do.
But if you provide a list of things that don't work as expected then I can try to look at them and then fix them one by one or bring back the dialog if they can't be fixed in integrated mode.

Now it's your turn if you want a change in this extension.

Toolbar buttons in Writearea

2011-09-03T20:49:00.001+02:00

Since version 1.1 it's possible to configure which buttons do you want to use in the toolbar of Writearea. There are in fact two toolbars and you can switch between them with a custom button.

The way to define the buttons is to use the preferences pane of Writearea and put the array of buttons in the corresponding input fields. Note that to try to help a little, you don't need to put the outer [ and ], just the groups separated by commas and with a '/' if you want to start a new row.

These are the default values for each toolbar:

Full Toolbar:
['Save'], ['SaveFile','LoadFile'], ['Source'],['Cut','Copy','Paste','PasteText','PasteFromWord'],['Undo','Redo','-','Find','Replace','-','SelectAll','RemoveFormat'],['ShowBlocks','Maximize'],['Image','Flash','Table','HorizontalRule','SpecialChar','Iframe'],['JustifyLeft','JustifyCenter','JustifyRight','JustifyBlock'],['BidiLtr', 'BidiRtl' ],'/',['Styles','Format','Font','FontSize'],['Bold','Italic','Underline','Strike'],['TextColor','BGColor'],['NumberedList','BulletedList','-','Outdent','Indent','Blockquote','CreateDiv','Code'],['Link','Unlink','Anchor'],['SwitchToolbar']

BasicToolbar:
['Undo','Redo'], ['Bold', 'Italic', '-', 'NumberedList', 'BulletedList', '-', 'Link', 'Unlink'],['SwitchToolbar']

Most of the commands are the ones available on the default CKEditor install, I don't know if there's any listing of the meaning of all of them, the best thing that I can think of is the user's guide, but it doesn't clearly link the button names with its action.

But beyond those common buttons, there are a few ones with special meaning here:

Custom buttons

'Save': It's available only while in the dialog popup, it will save the content of the editor to the original element. When the editor is integrated into the page you should use the existing save button provided by the page, that way there won't be any problem due to extra event handlers or differences between Save draft, Publish and Preview buttons of the page.

'SaveFile', 'LoadFile': These two options allows you to save/load the content of the editor to a file in your computer, just in case the page doesn't have any auto-save feature or you want to use something more than once.

'SwitchToolbar': These button allows you to switch between the basic and the full toolbar. I would suggest you to use the basic toolbar by default and only switch to full toolbar when there's something extra that you need at that moment. And of course, adjust each toolbar so the basic includes the commands that you usually need and the full toolbar doesn't includes buttons that you know you'll never use.

'Code': it's the SyntaxHighlight plugin available here. I made some little adjustments, but someday I might have to perform some bigger fixes to improve it and make it easier to use.

ServerPreview plugin for CKEditor

2011-08-22T21:47:00.001+02:00

Some years ago I created a plugin for FCKeditor to easily provide a preview of the contents that are being edited as they will look in the final site. That's specially important when you're using special markup in the editor that it's being replaced at the server by a widget or just some plain data.

The plugin is quite simple as the idea itself is simple: Get the current contents, and instead of opening a window with that HTML, post it to a custom page at the server and that page will be the one that can provide the proper context and show the HTML as it will be rendered in the final page.

This weekend I was tasked by Flatbooster GmbH to upgrade it so it can be used with CKEditor, and also perform some additions like controlling the size of the preview window.

The usage is quite basic, you just have to add it to your extraPlugins, specify the serverPreview_Url with your server script and use the posted "htmlData" variable. You can read the install.html to learn about other little options.

The plugin replaces the normal 'Preview' button, so there's no need to do anything to your toolbar.

The plugin can be downloaded here: Server Preview plugin for CKEditor 1.4.

Update 15/10/2011

Version 1.4, allow to use other CKEditor instances in the serverPreview_AdditionalFields setting.

Is your clock adjusted correctly?

2011-08-21T15:24:00.015+02:00

FoxToPhone now uses OAuth

In July I changed the authentication routines in FoxToPhone to start using OAuth like the latest version of ChromeToPhone. Using OAuth in a Firefox extension was a little harder at the start because I couldn't find something easy to use like the snippet that it's available for Chrome extensions.

Finally I took that code and adapted it to be able to use it the way that I wanted, without the need of a "background page", and reusing most of the code to avoid introducing any unexpected error.

This weekend this version 1.2 of FoxToPhone has been approved and now it's being updated as Firefoxes check for updates of the extensions. And despite all our hopes on the beta testers it's clear that not everything is OK.

Some people have been experiencing login problems with ChromeToPhone getting a hardly useful "redirecting..." message, and it's not clear what's going on, so it should be expected that some people would get also strange errors in Firefox with the new authentication. We fixed one or two such issues during beta testing, and today I've found another reason.

Your clock settings

Other people have already commented about it in that ticket, and I didn't look at it, but today one user reported login issues and after a little testing I found that while starting the authentication, one request is done that includes the current time, and in this case the request showed that it was one hour ahead of the current time. And the Google server replied with an status 400 meaning that the request was wrong.

So the user just moved his clock one hour back and then he was able to login and start sending the requests. Great!, we're moving ahead.

So if you get a response status 400, then you should check the settings on your control panel about the time zone and daytime savings are correct. Even if you see that the clock matches the one in your wrist, the computer also has additional information like the zone/country where you are, so when it tries to convert that local time to a global timestamp it will generate the wrong data if some of your info is wrong.

Testing time

This is a little script that tries to request the current time to the Yahoo servers and then checks it with your local time, if you see an error message then you should review the time settings in your computer

Hey Google, can you improve that error page?

Certainly returning "400 (Bad Request)" when the problem is the timestamp seems a little rude. It's clear that it's possible to check that the parameter is out of the allowed bounds, so in order to be helpful the error message should give a clearer hint that the problem is just that parameter. No real attacker is gonna try to send a request with that parameter wrong, it's just too easy to do it right, so the only people that would pass wrong data there are those users that don't realize that there's a problem with their clock settings.

Just as I've been able to mock a little script that performs a simple test, I guess that you should be able to provide at the very least the same check in a dedicated page and working a little further it should be able to guess more exactly if the problem is the time zone, the DTS or just the clock itself, something that shows the user the correct screenshots to check their settings etc...

Location aware password policy

2011-08-15T12:33:00.001+02:00

This morning I waked up and I was thinking about the password on my phone. I've always found it annoying having to retype it every now and them, specially if I'm at a place like my home where no one else can grab it.

So I thought that the device should be smarter, and I think that currently it should be possible to bring a little intelligence to these "smartphones". When I'm at a place that I have to configured to be trusted, then once I unlock the phone it should remain unlocked as long as it remains there or I don't explicitly lock it.

One easy way to achieve this would be to enhance the wifi manager, whenever I connect to a protected wifi with a password one new option is available: "this is a trusted site", by checking it the phone (or any similar mobile device) will remain unlocked and it's also possible to specify if the unlock should last some minutes (5 or 10, like when you are doing something with 2 devices, leave one apart and when you pick it up again it's locked so you waste time unlocking it), one hour or remain unlocked as long as you're connected.

That simple change could help lots of times, if we can use the devices at home without the need to retype the password (or whatever lock mechanism you've chosen), then we would be slightly happier and we could use slightly harder passwords for the moments when we're out of home.

Additional refinements could defined as an option to specify a coverage zone: instead of home, you're at work in your office, so you want the device to remain unlocked while you're there, but if you move out of the office then it should go back to the normal behavior.

I think that many people might not be using currently any password just to avoid the hassle of having to unlock his device every now and then, but if a system like the proposed in this post would be available then I would bet that they would be much happier to know that they have a secure device when they're walking down the streets while keeping the simplicity of an always available device at home without the need to retype the password at every moment.

Upcoming changes for Write Area

2011-08-13T16:03:00.001+02:00

It has been a long time, but these days I'm going to try to push a new stable release of Write Area. It will be mostly an upgrade to the current CKEditor 3.6.1, but at the same time I'm gonna try to finish some code that it's available in the betas and provide a simplified version.

The main change will be the removal of the option to select whether to open the editor in a bottom pane or in a dialog. My plan is to finish the behavior of the new "integrated" mode, so that whenever you select to use Write Area with a normal textarea then it will be replaced by a CKEditor instance integrated in the same page. This is similar to what the "bottom pane" provides, but with the advantage of being able to create more than one instance, and the rest of the scripts of the page can get direct access to the contents as if nothing had happened.

If you try to use instead an existing editor that isn't too compatible with the current Firefox or it's missing features, then the editor will be launched in dialog mode. The plan is to do this automatically without the need to select a preference.

Why?

First: Simplify options.
More options means more testing, harder for the user as he has to think about what's better. I can't claim that I know better than him what's better for him, but I know what's more job for me.

Second: Try to avoid future problems due to changes in Firefox.
The bottom pane is a "XUL overlay", that means that it's somehow quite integrated with Firefox, and in the future the plan is to try to move as much extensions as possible to the Addons-SDK. That means that such integrations might be harder or just impossible. If I start removing these blocks I can try to test if it's possible to port the extension to this new world. Anyway that goal is quite far away as I've stated previously that I won't start using the Addons SDK as long as they require to install Python or any other third party libreary/compiler/whatever.

Third: Other browsers.
By using a simpler approach it's possible to create a Write Area version for Chrome, and although I don't use it I understand that other people do, so if there are just a few differences then I can provide a port of the extension. It won't be as feature rich as the Firefox version, but at least is something that people can use.

Conclusion

If you have a strong reason to believe that I'm making a mistake the I would like to hear your concerns. Otherwise I'll go ahead and release the update when it's ready

Third version for seamless replacement of textareas

2011-07-31T18:43:00.005+02:00

Sometime ago I wrote a script that allows to use CKEditor, and at the same time keep using older scripts existing on the page that relied on reading the textarea.value (or even writing it), without having to modify them to use the CKEditor API.

The initial version worked with Firefox and Internet Explorer 8, and shortly after I added some adjustments so that Opera was also supported.

Recently a comment in that second post stated that the script gave errors in Chrome, although it tries to detect if the API that I was using is supported, but of course, webkit guys decided to implement the API but not make it available for native properties. Their statement is that treating native properties as overridable would have a negative effect on performance, and as we all know it's much more important to have a fast browser than a browser that allows the developers to do new things; unless you're in their team then you can write a new API for whatever you need and everyone else should use this API because it will change the world, you'll no longer have to use Flash because now you have this API to overcome other problems that we didn't want to fix. Besides the bug tickets commented previously, here's another one: bug 36423

Ok, enough ranting.

As I said, I've worked to find out the problems and the funny fact about this new version is that it works in Chrome but it still fails in Safari 5.1. So you can use it in your site if can restrict the browser used by your users to IE8+, Firefox 3.5+ , Opera 10+, and Chrome 12+ (I don't really know the oldest version of Firefox, Opera and Chrome where this will work, but I wouldn't expect anyone to use old versions of those browsers)


// Modify the default methods in CKEDITOR.dom.element to use .nativeValue if it's available
CKEDITOR.dom.element.prototype.getValue = function()
{
    if (typeof(this.$.nativeValue) == "undefined")
        return this.$.value;

    return this.$.nativeValue;
}

CKEDITOR.dom.element.prototype.setValue = function( value )
{
    if (typeof(this.$.nativeValue) == "undefined")
        this.$.value = value;
    else
        this.$.nativeValue = value;

    return this;
}

// Hook each textarea with its editor
CKEDITOR.on('instanceCreated', function(e) {
 if (e.editor.element.getName()=="textarea")
 {
  var node = e.editor.element.$;

  // If the .nativeValue hasn't been set for the textarea try to do it now
  if (typeof node.nativeValue == "undefined")
  {
   // for Opera & Firefox
   if (!DefineNativeValue(node))
   {
    // IE8 & Webkit
    if (!DefineValueProperty(node))
    {
     alert("Your browser is buggy. You should upgrade to something newer")
     return;
    }
   }
  }

  node.editor = e.editor;

  // House keeping.
  e.editor.on('destroy', function(e) {
   if (node.editor)
    delete node.editor;
  });
 }
});

// This function alters the behavior of the .value property to work with CKEditor
// It also provides a new property .nativeValue that reflects the original .value
// It can be used with HTMLTextAreaElement.prototype for Firefox, but Opera needs to call it on a textarea instance
function DefineNativeValue(node)
{
 if (!node.__lookupGetter__)
  return false;

    var originalGetter = node.__lookupGetter__("value");
    var originalSetter = node.__lookupSetter__("value");
    if (originalGetter && originalSetter)
    {
        node.__defineGetter__("value", function() {
                // if there's an editor, return its value
                if (this.editor)
                    return this.editor.getData();
                // else return the native value
                return originalGetter.call(this);
                }
            );
        node.__defineSetter__("value", function(data) {
                // If there's an editor, set its value
                if (this.editor) this.editor.setData(data);
                // always set the native value
                originalSetter.call(this, data)
                }
            );

        node.__defineGetter__("nativeValue", function() {
                return originalGetter.call(this);
                }
            );
        node.__defineSetter__("nativeValue", function(data) {
                originalSetter.call(this, data)
                }
            );
        return true
    }
    return false;
}

function DefineValueProperty(node)
{
    var originalValuepropDesc = Object.getOwnPropertyDescriptor(node, "value");

 if (!originalValuepropDesc)
  return false;

 // Safari doesn't allow to overwrite the property (but Chrome does)
 if (!originalValuepropDesc.configurable)
  return false;

    Object.defineProperty(node, "nativeValue",
            {
                get: function() {
                    return ( originalValuepropDesc.get ? originalValuepropDesc.get.call(this) : originalValuepropDesc.value );
                },
                set: function(data) {
                    originalValuepropDesc.set ? originalValuepropDesc.set.call(this, data) : originalValuepropDesc.value = data;
                }
   }
        );

    Object.defineProperty(node, "value",
            {
                get: function() {
                    // if there's an editor, return its value
                    if (this.editor)
                        return this.editor.getData();
                    // else return the native value
                    return this.nativeValue;
                },
                set: function(data) {
                    // If there's an editor, set its value
                    if (this.editor) this.editor.setData(data);
                    // always set the native value
                    this.nativeValue = data;
                }
            }
        );
 return true;
}

// Detection, not really needed, but it can help troubleshoting.
if (Object.defineProperty)
{
    // IE 8 and updated webkits
 // Detect Safari
 if (document.head)
 {
  var test = Object.getOwnPropertyDescriptor(document.head, "innerHTML");
  // IE9
  if (!test)
  {
   if (!DefineValueProperty(HTMLTextAreaElement.prototype))
    alert("Unable to define property override on the prototype");
  }
  else
   if (!test.configurable)
    alert("Safari doesn't allow to overwrite native properties");
 }
}
    else if (document.__defineGetter__)
{
    // FF 3.5 and Opera 10
 // We try to get the innerHTML getter for the body, if it works then getting the value for each textarea will work
 // Detect old webkits
 if (!document.body.__lookupGetter__("innerHTML"))
  alert("Old webkits don't allow to read the originalGetter and Setter for the textarea value");
}
    else
{
    // detect IE8 in compatibility mode...
    if (document.documentMode)
        alert("The page is running in Compatibility Mode (" + document.documentMode + "). Fix that")
    else
        alert("Your version of IE is too old");
}

Too many permissions for simple apps

2011-07-13T12:21:00.002+02:00

Yesterday I was badly surprised when Reto Meier added a post pointing to an Android game activated by the voice; that sounded fun (although it's clear that it can't be played in too many places), but I wanted to check it out.

The bad surprise came when the market showed me the required permissions for the App:

Record sound (obviously, it needs as that's the differential point)
Full internet access (ok, some ads as it's a free app)
Read and write the contents of the SD card. This isn't too nice, but some apps and games have extra downloads to keep the app itself smaller and they download the data to the SD. We have to accept it until Android provides a better option (check below for my proposal)
Read identity and state of my phone. No, this isn't OK. An app doesn't really require to know anything about my phone. Usually this is enough for me to not install an app.
Read SMS. What??? Read my SMS? for a game?, are you joking?. So this app requires full internet access, read all the content of my SD card as well as my identity and my SMS? They can ask for my bank account at the same time.
Send SMS. Ok, this is enough. What's the difference between this game and those trojans that have been found claiming to be legit Android Apps? How can a user be able to find out that the developer is really a good person and it's requiring those permissions really based on real requirements instead of being used to send premium SMSs and hide them as those trojans do?

Whenever such application with those huge permissions is mentioned by someone that it's otherwise respected, we can expect that people will download it, and by doing it people will be used to accept that apps might require extra permissions. This will lead to "permission blindness" just like people is now blind to the Ads that appear in some webs, people will get used very soon to the fact that any app might want to read your SMS, your contacts and anything else.

So this will destroy any effectivenes of the permissions system, the typical statement "be careful about what you install" and "it's easy to spot a trojan due to its permissions" will be void. Sum it with the lack of review system in the Android Market and you get a big problem just waiting to happen.

According to some comments in that post, the developers answered in Twitter claiming that the SMS is to upgrade the app to a paid version. So... what's wrong with the Android Market? why don't you offer the full version there instead of using SMSs? Does premium SMS work across countries? how much it's gonna cost some random user in Spain like me a premium SMS sent to the USA? If it's just an internal switch in the app, why isn't this done using the existing internet connection? People pay it in your site and then the app is upgraded to full version. Hell, it can even be done showing the user an unlock code and without internet on the phone app itself!

The requirement to read/write the SD card could be fixed if Android had a better system for apps to store their own data:
Currently those apps create random folders anywhere on the SD card and they remain there after the app has been removed. If instead of getting full access to the SD card they had access to just a custom unique folder, then this could be much better:

Any app can read/write to his own folder in the SD, ex. /Android/data/com.google.android.apps.maps/
That folder is only accessed by that app (or other apps like file managers that really request full SD access), there's no need to state it in the permission list
When the app is removed, the uninstaller also cleans up that folder, so that the app has been really uninstalled and nothing remains. If the user wanted to keep the data he can do a backup of the folder before performing the removal.
In summary: the app itself doesn't really need to know the location of that folder, it just knows that it can safely read and write there, and due to that safety it doesn't require an extra permission at install time. Better for the developer, better for the users.

The Android system really needs an improvement in the way that permissions are granted, the user shouldn't have to worry because an app is requesting weird permissions, also, the Android Market should be much more careful and force a review of any app that requires permissions like send SMS, or perform a combination of read SD and get internet access. When an app just requires internet to show ads it's OK, but if that app is also able to read all the data in your SD card (photos, Titanium backups, etc...) then it should be reviewed to provide a warranty that it's a good app and not something evil.

Enough of bad comments, do you want to know a nice game? (no, this post isn't sponsored and I'm not related to the developer)
Test Trap!, it ask for all the permissions that you can expect from a nice game: none, and it can keep you playing it for a while trying to beat yourself.

Testing Google's Music Beta

2011-06-23T21:40:00.002+02:00

Last week I got the invitation to the new Google's "Music Beta" service. I haven't had time to test it too much, but these are my first impressions:

Upload is really slow. That's of course due to my ADSL connection, but you can expect almost a week to upload all your music.
It's strange that the limit is the number of songs (20.000) instead of the size of them
The Uploader recognizes that .ogg files are music, but it refuses to upload them. Why? I've to verify if it has uploaded other "strange" formats that Foobar2000 played happily.
I didn't had all the music properly tagged with ID3 as it was organized with folders and it worked fine, but now those files have crypting names. That's bad in a thousand files library. But the problem is that I have to find out which files have been uploaded wrong, then correct my local copies and also correct the remote copies (or reupload them).
If I edit the metadata of some remote file, I can't download later that updated file. That means that we can't really get rid of our local copies and use just the cloud for storage. In no way I'm gonna get rid of my MP3 player until the phone's batteries last as much and the only way to put music there is with USB, no magic cloud connection.
Some albums are missing the cover picture, and you can edit that with the web interface, but they have forgotten to add drag&drop support to easily upload the new picture. Hey Google, ask the GMail team to give you a hand.
I don't see how playing streaming music in a browser can be interesting in my desktop, I won't use Google Music there until they provide a native application that can use my existing files without streaming them (Hey, I already have them here)
The uploader has given me an interesting error with some files: "No music found in file", but every other player handles those files correctly. Editing the tags didn't fix, so I reencoded and then it accepted them and they were uploaded.
Other times it has stated that there's an error while uploading, so I have to verify album by album if it has been correctly uploaded.

Como usar el DNIe con Firefox 4 en Mac 10.6

2011-04-17T15:28:00.010+02:00

This post is in Spanish as it's related only to a problem in Spain with Firefox 4.

DNIe vs Firefox 4

Desde que se lanzó Firefox 4 la gente que usa Mac ha tenido problemas para poder usar el DNIe ya que no permite instalarlo, y si lo tenías instalado con anterioridad no hace nada al intentar acceder a páginas donde lo requieran.

En principio nadie sabía indicar cual era la causa de estos problemas, pero tras crear un ticket en Mozilla respondieron diciendo que el problema es que estabamos intentando usar unas librerías de 32 bits y Firefox 4 se ejecuta por defecto a 64 bits.

Existen los drivers de OpenSC para Mac a 64 bits, pero no sirve de nada instalarlos, ya que los drivers específicos para el DNIe no vienen incluidos y la versión que proporcionan no funcionan con ellos, por lo que tenemos que esperar a que nos publiquen una versión oficial para poder usarlo correctamente.

Solución temporal

Sin embargo, en vez de desinstalar Firefox 4 y volver a la 3.6, podemos configurar fácilmente el ejecutable como indica Willyaranda para que se ejecute a 32 bits y de esa forma sí que podremos instalar la librería necesaria en Firefox y luego usar el DNIe.

Primero vamos a "Aplicaciones" y en el icono de Firefox pinchamos con el botón derecho y escogemos "Obtener información"

En esta ventana se activa la opción de "Abrir en modo de 32 bits"

Y ya está, ahora cuando ejecutemos de nuevo Firefox funcionará en modo de 32 bits y los drivers del DNIe sí que se ejecutarán. Podemos lanzar la web de verificación y nos pedirá que introduzcamos nuestra contraseña.

Si todavía no habíamos instalado el DNIe y esta es la primera vez que lo hacemos, puede pasar que en el paso final tras iniciar de nuevo la sesión en Mac y cuando se lanza automáticamente Firefox, nos diga que no se ha podido instalar el Módulo de seguridad. En ese caso a mi me ha bastado con cerrar Firefox, y al abrirlo de nuevo cargar otra vez el fichero de instalación file:///Library/OpenSC/share/web/instala_modulo_f3.htm y entonces sí que se ha instalado correctamente (tras confirmar los permisos requeridos)

Posibles problemas con los certificados

Otro posible problema con Firefox 4 (pero no exclusivo de Mac ni relacionado exclusivamente con el DNIe) es que al intentar acceder a alguna web con HTTPS nos muestre una ventana de error con este mensaje: "ssl_error_renegotiation_not_allowed"

Dicho problema está explicado por completo en el Wiki de Mozilla: Security:Renegotiation y básicamente se trata de que existe una vulnerabilidad en los protocolos SSL/TLS y desde Firefox 4 han decidido que lo mejor es bloquear dicha vulnerabilidad, e intentar conseguir que todo el mundo actualice sus servidores para evitar el problema.

Por tanto, lo primero que hay que hacer es enviar un correo al contacto de ese sitio web para indicarles la existencia del problema y que deberían solucionarlo lo antes posible. Cuantos más les escribamos, más posibilidades hay de que al fin se decidan a corregirlo aunque no sea más que para no tener que seguir oyéndonos.

Y mientras tanto, pues nosotros podemos hacer unos ajustes en nuestro navegador para poder usar esa web si así lo queremos:

Escribimos about:config en la barra de direcciones y pulsamos enter
Si nos avisa de que podemos estropear algo le decimos que sí, que estamos seguros de lo que queremos hacer.
Escribimos (o pegamos) security.ssl.renego_unrestricted_hosts en el filtro, nos aparecerá la preferencia correspondiente y por defecto como una cadena en blanco.
Le damos a editar y pegamos ahí el dominio donde nos ha dado el error (sin https:// ni las carpetas)
Si hay más de un dominio los separamos con comas.
A continuación filtramos esta otra preferencia security.ssl.treat_unsafe_negotiation_as_broken y la cambiamos a true.

De esta manera ya podremos acceder a ese dominio de forma temporal mientras corrigen los problemas con su servidor y lo dejan bien protegido.

Lo que NO es recomendable es cambiar la configuración de security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref ya que eso anula por completo la seguridad y seremos vulverables en cualquier web al problema existente que estaban intentando evitar (es decir, por poder acceder a una web de esta forma se anula la seguridad en todas las webs)

Migrating from FCKeditor is a little easier now

2011-04-13T23:03:00.001+02:00

There are tons of site out there that are still using FCKeditor despite the fact that it has been replaced by CKEditor and no work is being done to improve it since long ago.

There are several reasons about that, and one of them is the time cost of upgrading things like the configuration and now there's a little plugin that helps avoid at least one of those problems.

In FCKeditor the definition for Templates (HTML snippets) that the user could insert into the content was available in XML files, but as CKEditor was designed so it could be used in a cross-server environment that meant that the format was changed to JSON in order to load .js files from the server instead of trying to do a XHR that it's quite complex or impossible to do on a foreign server.

But the fact is that most of the people doesn't use CKEditor in such environments and also there are lots of people that have their templates specified in XML files and migrating them to JSON isn't obvious as no tool has been published to carry out that goal. Besides that, I personally find much easier to deal with XML files for the templates instead of the JSON version.

Example of a template in JSON:

   {
    title: 'Image and Title',
    image: 'template1.gif',
    description: 'One main image with a title and text that surround the image.',
    html:
     '<h3>' +
      '<img style="margin-right: 10px" height="100" width="100" align="left"/>' +
      'Type the title here'+
     '</h3>' +
     '<p>' +
      'Type the text here' +
     '</p>'
   },

The same template in XML:

 <Template title="Image and Title" image="template1.gif">
  <Description>One main image with a title and text that surround the image.</Description>
  <Html>
   <![CDATA[
    <img style="MARGIN-RIGHT: 10px" height="100" alt="" width="100" align="left"/>
    <h3>Type the title here</h3>
    Type the text here
   ]]>
  </Html>
 </Template>

In the JSON version you have to use single quotes on each line of the "html" and remember to concatenate everything. In the XML version you just paste whatever you want inside the CDATA comment.

Ok, that's fine. You might like one version or another, but if you want to easily use the XML templates in CKEditor, then upgrade to CKEditor 3.5.3 and add the XmlTemplates plugin.

New beta for WriteArea with CKEditor 3.5.3

2011-04-09T13:21:00.002+02:00

Following the release this week of CKEditor 3.5.3, I've updated the WriteArea extension for Firefox to this latest version to include all the bug fixes and enhacements that have been worked on since the last release (check the change log, it's quite a long list as it's usual for every CKEditor release)

In this version, the only patch applied to the core is the latest from this ticket that allows a new button that you can use to switch toolbar on the fly.

The size of the extension has grown again a little due to several languages that have been updated since the previous checks that I did and so I've restored as new they can be correctly used to localize your CKEditor and not have part of the texts in your language and the other half in English.

Direct download link: WriteArea 1.1beta4

onChange event for CKEditor

2011-03-27T22:24:00.002+02:00

It's a somewhat frequent request to see people asking how they can get a notification whenever the content of CKEditor changes.

Some of them are too optimistic:

I've this code <textarea onchange="myfunction()"></textarea> and when I use CKEditor "myfunction" is never called

But most of the people can understand the difference between the original textarea and a CKEditor instance and ask what's the better way to get a notification whenever the content changes, isn't there any built in event for that?

The answer is that no, there's no default event fired whenever something changes, but as I will show here it's quite easy to extend the CKEditor API and generate such event.

Generating a new 'change' event

Although there's no event for "the content has changed" there's something very similar, and that's the Undo system with its saveSnapshot event; whenever something changes it will be called, so we can listen for that event and it will help us greatly with our goal:

       editor.on( 'saveSnapshot', function(e) { somethingChanged(); });

That will take care if the change is something being changed like appying bold or any other style, a new table, pasting, ... it should handle almost everything. But there's one thing that doesn't file a 'saveSnapshot' event, and that's the undo system itself. When Undo or Redo are executed they don't fire that event, so we must listen to them:

        editor.getCommand('undo').on( 'afterUndo', function(e) { somethingChanged(); });
        editor.getCommand('redo').on( 'afterRedo', function(e) { somethingChanged(); });

Ok, Why "something changed"?
Answer: because we are not really sure that something has changed and we aren't really interested to know exactly what has changed, only that something might have changed. Any plugin will fire a "saveSnapshot" before and after any change to work properly, so in our function we will merge all those calls and fire a single event:

        var timer;
        // Avoid firing the event too often
        function somethingChanged()
        {
            if (timer)
                return;

            timer = setTimeout( function() {
                timer = 0;
                editor.fire( 'change' );
            }, editor.config.minimumChangeMilliseconds || 100);
        }

This way the editor will fire a "change" event at most every 100 milliseconds, and you can use editor.checkDirty() to verify if it has really changed (that call might be a little expensive if you are working with big documents, so it's better to avoid calling it too often by using something like the minimum 100 miliseconds that I've added)

Extra checks

To trap every change (and ASAP to avoid delays updating any UI that it's interested in this event I added also a listener for the afterCommandExec (I don't remember now which situation made me add it and I didn't put any comment explaining it :-( )

        editor.on( 'afterCommandExec', function( event )
        {
            if ( event.data.command.canUndo !== false )
                somethingChanged();
        } );

and also a listener for the keyboard (don't know right now why I didn't listen for the editor.on('key') event; maybe I forgot about it) and new code to handle drag&drop (I've proposed to enhance the Undo system that way in ticket 7422 with some improved code)

        editor.on( 'contentDom', function()
             {
                 editor.document.on( 'keydown', function( event )
                     {
                         // Do not capture CTRL hotkeys.
                         if ( !event.data.$.ctrlKey && !event.data.$.metaKey )
                             somethingChanged();
                     });

                     // Firefox OK
                 editor.document.on( 'drop', function()
                     {
                         somethingChanged();
                     });
                     // IE OK
                 editor.document.getBody().on( 'drop', function()
                     {
                         somethingChanged();
                     });
             });

Ready to use plugin

Here you can download a zip with the full plugin and install instructions onChange event for CKEditor.
Obviously it can be improved, but the important part was to get something working good enough not to win a code contest about the best and most beautiful code.

Note: If you wanna link the plugin from any other site, please link this post so people can get the new versions when they are released instead of linking directly to the zip that will be outdated.

Edit: version 1.1 3rd September 2011

I've fixed an issue with the 'afterUndo' and 'afterRedo' events: they're fired on their respective commands, not on the editor itself; now the Undo and Redo buttons should work correctly. I can't understand how I missed that the first time.

Following the suggestion in the comments, I've added detection for changes in source mode, by keyboard, drag and drop and also on "input" if supported.

Edit: version 1.2 18th September 2011

The new CKEditor 3.6.2 fired the 'saveSnapshot' event too many times, just changing the focus might fire it and generate bogus change events when nothing has changed. Filtered those extra events.

The keyboard listener has been adjusted to ignore movement and other special keyboard events.

Edit: version 1.3 22th December 2011

Avoid firing the event after the editor has been destroyed.

Notes to self about the Code highlighter plugin used in WriteArea:

It doesn't remember the last used language reverting always to Java
It doesn't prefill the content with the currently selected text

Creating extensions for each browser

2011-02-06T11:31:00.001+01:00

These last days I've tried to create a similar extension for each browser, and this is a little recap of the first differences among them. A page with a full list of differences can be found in the State of the Add-on Developer Union

Firefox

In Firefox there are two options:

Create the extension using the "classic" way that goes back to the very beginning and provides full access to anything in Firefox, you can customize it in any way that you like.
Use the new Add-Ons SDK, only for Firefox 4. These ones doesn't require a restart and it's supposed to be future-proof.

In order to create a classic add-on you can get a skeleton using the Add-on Builder . There are lots of info about how to create these extensions and the API that they can use, and to start creating an Add-on the first step is this page to setup the environment. All you need is a text editor, some patience and be careful following the instructions. You can then configure Firefox to load the extension from the disk but when you make changes to the code you'll have to use an extension to force a reload of all the Firefox code or directly restart it; not nice.

To get started building add-ons with the new SDK, check the tutorial.
First problem: You are required to have Python installed.
What?
I'm so tired of projects that say: you have to install this or that or all of these projects just to get started.
What's so special about Python and the SDK environment that can't be done inside Firefox?
Why should I have to keep the list of instructions instead of being able to click on some buttons "Add extension", "Run tests", "Install", "Reload", etc...
Big boo here.
Maybe they want us to use wget instead of Firefox if they think that command line is so nice.

Anyway, I gave it a go in the Mac (I won't bother trying to install python in windows, it has already too many SDKs there for this and that), and so I followed the basic example, while trying at the same time to adjust it to my goal, I add the files, and when I do the "cfx run" then I get a cryptic error "raise ValueError('invalid resource hostname: %s' % name)". WTF? check again that I haven't done anything too weird. Nops. Then put back exactly the sample code. Nops. Search for the message. Bingo!, although there's no warning about this in the tutorial, you CAN'T use uppercase letters in the folder name. Hello Mozilla, it's 2011, I thought that the problems with uppercase and lowercase were gone long ago since MS-DOS. Why aren't your wonderful Python scripts able to deal with them?
Another big fail.

As a summary: I got a bad taste of the Add-ons SDK. When they put forward something that isn't oriented to Python lovers I might test it again (please note that I haven't even tested the API, just the environment makes me go back to keep using the classic method)

Chrome

It seems that there's a lot of work going on here in order to provide a very complete API for the extensions as well as good documentation and lots of examples. You can see a very basic one here and everything is quite easy to follow. Given the fast path that it's set on the release of new Chrome versions we can expect that this trend will continue and that they will add missing features to make some tasks even easier.

The only thing that you need is a text editor and Chrome, and by following the instructions you can get it working. It's not so powerful as the classic extensions in Firefox, but it's really easy to start creating an extension and there are lots of examples to check how they work.

Safari

It seems again that there's plenty of documentation at a central place, but just in the first page there's something strange:

Important: To develop extensions for Safari, you need to sign up for the Safari developer program online, at http://developer.apple.com. You need a signed certificate before your extension can be installed.

Uh?
So to create an sample extension in my own computer I need a certificate?

Ok, this shows again that Apple is a control freak. Why do I have to register to get an Apple ID and then get enrolled into a "Safari developer" program so that I can finally request a signing certificate, just to create a test extension? I can understand that in order to deploy it I might need to sign it, but I really should be able to create an extension for myself without the need to sign two looong agreements with Apple (I'm not sure if there was a paragraph about my first newborn there)

Anyway I go ahead and get a certificate in the Mac, and then it seems to work, but I would like to keep the development environment in Windows, so I try to install the downloaded *.cer there but anyway Safari keeps saying that there's no signing certificate installed. After a little while and some digging I realize that I must export the private signing key from the Mac KeyChain to Windows and once I installed it there Safari started working.

In some regards this might be the simpler interface of all the browsers in order to create an extension as you get a dialog to setup the basic configuration of the extension instead of editing them in a text file. The way that the code is setup is similar to Chrome (and Opera): background pages, injected scripts, so porting from Chrome wasn't a hard task.

As it happens with almost everything Apple does, if you are satisfied with what they offer, they try to make it quite easy, but if you want something extra then it's a no go.

Opera

I started checking the Opera API with the very first builds where they started adding support for extensions. In those days the API wasn't complete, there were a bunch of things that didn't work at all, so due to my hurry to test it I became a little frustrated because there were so many things missing, there was almost no documentation at the moment so it required a lot of effort to try to make something work because the examples were quite basic.

Now they have improved everything a lot, the behavior is similar to Chrome and Safari, but this is still a fresh SDK, so there are still missing features available in other browsers. They have written now lots of documentation and I guess that very shortly it should be quite easy to port an extension between Opera, Chrome and Safari due to the convergence of APIs that the developers find useful.

For the moment Opera it's lacking an API call similar to the ones that I've used for the other browsers so I will put the extension for browser at rest waiting for them to include them instead of struggle again and get tired of finding that it's not possible in any way.

Mobile test

2011-02-03T23:50:00.001+01:00

A quick test of the new blogger application for android

Seems to support only plain text and pictures. Doesn't list existing posts or labels

WriteArea 1.0.1 Beta 1

2011-02-01T21:44:00.004+01:00

Today I've uploaded a beta version of WriteArea to AMO, as I said, it has been updated to CKEditor 3.5.1 but besides that it includes (finally) a feature that it's the way that most of us expected the editor to behave: in-page editing.

This means that the editor is integrated into the page instead of a bottom pane or popup dialog. This feature is still experimental and there might be some unexpected problems, so please be careful (by saving drafts or copy&paste of the contents) before submitting the form.

This feature might have some improvements before the final release, but you can already start testing it

Some drawbacks (at least for the moment):

It's not possible to revert the action, once the editor is created it only goes away when the page reloads (might not be a big problem)
The clipboard operations are again restricted by default.
The Open/Save draft features are no longer available. Maybe I'll adapt them to use HTML5 storage instead of saving to file.

Benefits:

It's just easier to use and understand
There can be multiple editors in the same page
A button can be added so all the textareas are converted without using the context menu

Please, test it and tell me if you notice some problem or if you think that this is really the way to go and the other options should go away.

HTML5 Video plugin for CKEditor

2011-01-24T23:13:00.002+01:00

You might have heard a lot of people talking about the new features of HTML5, and one that has brought a lot of interest is the <video> element that some people think that will avoid the use of Flash once and for all (at least Steve Jobs thinks so).

Personally I don't think that it will be so easy to dismiss a whole environment like Flash just because videos now can be played without external plugins, leaving aside the fight of h264 vs WebM (or as is now: Apple & MS vs the rest of the web), Flash has a lot of features that aren't easy to replace, the most basic one, the fact that you deploy a single swf file, vs having to provide several javascript and images just to perform anything basic with javascript. And as soon as you want to use some effects, you might end up with something huge and in fact as slow as the dreaded flash files.

But back to the topic, HTML5 video and CKEditor. What about that?

Ok, here we go, this is a plugin sponsored by DM Logic that makes using the <video> element as easy as an old <img>, you can insert, edit, use the context menu, etc... the dialog allows to specify the poster image, the dimensions (they are automatically adjusted according to the preview) and two source files, so that both the browsers that use the WebM format (Chrome, Firefox and Opera) and the ones that support only h264 (IE9 and Safari) can view your videos. Here's a short video showing how it works.

Download it here.

Background image plugin for CKEditor

2011-01-22T16:14:00.001+01:00

People enjoy colorful pages, background graphics and everything that can make their pages show their good taste, that's why some of them haver requested such feature for FCKeditor and CKEditor.

It's not clear if it might get directly supported in the core but here's a plugin for CKEditor to include a "Background image" field (with a button to launch the server browser) in the Table and Cell properties dialogs.

You can download the plugin here, the zip includes an install doc explaining how to use it, just extract the zip under the plugins folder for CKEditor and add "backgrounds" to the list of extra plugins.

Thank you to Igenti, Inc. for sponsoring the development of the plugin.

Avoiding extra request for the translation of a CKEditor plugin

2011-01-16T21:40:00.001+01:00

When you write a plugin for CKEditor, it's almost for sure that it will include some text, it can be the tooltip for the toolbar button, a context menu entry or some change to one dialog, and you can leave that string hardcoded in your language, but it's usually better to use the localization features of CKEditor so it's easy for users in other countries to use your plugin, as well as allowing to easily change the text to fit better in a different environment.

As you might know this is achieved by setting a "lang" property in your plugin that it's an array with the list of language codes that your plugin provides:

 lang : [ 'en', 'es' ],

That entry tells CKEditor to load the file with the translation from the lang file of your plugin (lang/en.js or lang/es.js), and it's a pity that with all the current efforts about improving performance, due to the desire to provide the translation your editor might load slightly worse as it gets that extra file.

But there's an easy workaround, you can put the localization in the plugin.js file itself, so that when it checks what does it needs to load for this plugin, it can see that the translations are ready and so it skips for the next item.

Now each translation is just a line in the plugin and it doesn't require an extra request to the server:

CKEDITOR.plugins.setLang( 'backgrounds', 'en', { backgrounds : { label : 'Background image'} } );
CKEDITOR.plugins.setLang( 'backgrounds', 'es', { backgrounds : { label : 'Imagen de fondo'} } );

Security attack from IP 92.243.90.103

2011-01-15T23:00:00.001+01:00

I've noticed recently that the IP 92.243.90.103 is testing several servers, requesting for files related to FCKeditor and then checking for the availability of the connectors to perform operations on the server (usually I think that it's more common requests related to tinymce filemanager, but it doesn't really matter too much).

I don't think that the requests are related to an unknown problem with the server connectors in FCKeditor as it seems to search both the asp and aspx versions (maybe it acts depending on the server software), but there are a few points that everybody should remember in order to avoid problems.

As every other time that I've written about this issues, let me remember you that I'm not a security expert and these are just some basic guidelines, the basis is that you should try to create an onion around the security of your server, different layers so that an attacker has to go through all of them, and hopefully he should be stopped at the very first steps.

Keep only the needed files

Whenever you use a third party software (or even your own software), don't upload to the server everything that comes in the shipped distribution. You won't need at the server source files, samples, documentation, or integration files for other server languages.

By removing those extra files you are avoiding a larger vulnerable surface and you can focus on the important files.

Security by obscurity can be useful

Yes, security by obscurity isn't really secure, but this kind of automated attacks that just search any number of domains for some files at specific locations like "/FCKeditor/editor/filemanager/connectors/aspx/connector.aspx?Command=GetFoldersAndFiles&Type=File&CurrentFolder=/" can be avoided if you place this 3rd party components in a non-standard location, so something as easy as putting the FCKeditor in another subfolder can avoid that an automated attack finds your files.

It's also important that the files that the users upload to your server with scripts like the FCKeditor server upload, don't end up in a folder that gives any hint about how they have been placed there, if your files are under /scripts/CKFinder/userfiles I'll know that you are using CKFinder somewhere in your server and more important, you are stating the path for CKFinder so you are weakening a little the security that you got in the first place by using /scripts/CKFinder instead of just /CKFinder

Expose the upload script only to users that can upload files

If a user doesn't have permissions to upload anything, then he shouldn't be able to see any hint about what are you using to manage the files in your server.

Secure the upload folder

The folder where the users are able to upload files shouldn't have permissions to execute any script, so even if they are able to upload a script, it won't do anything. Using the IIS control panel or .htaccess files in Apache it's easy to perform this task.

Keep your code updated

This can be a pain, but you once you start using a script at your server, you should check from that moment any new release about that project, paying special attention to warnings about security problems in new releases. I think that every project has some kind of RSS feed, so it shouldn't really be that hard to at least notice the new versions.

Enable file management wisely

In FCKeditor and CKFinder the server connectors include a config file where you can adjust some parameters (location of uploaded files, allowed or disallowed extensions, types of files, etc...) but the most important one is the ability to state if the script is enabled or disabled.

By default the server connectors are disabled in FCKeditor and CKFinder as that's the safe default, but people the complain that when they try to use them they get a message stating that the connector is disabled. Of course, that kind of people are showing that they didn't bother to read the minimum about how to configure these scripts, so they might end up using other ones that are enabled by default and they won't ever notice that now everyone can manage the files of their servers.

The correct step is to use the login credentials of your CMS to enable the file management only for the correct users, you don't really want an anonymous user being able to upload a file to your server.

Finally: be careful

As you can see, I'm not revealing anything extraordinary, these are just some basic rules that can provide some basic protection, but there are more that you should be aware of and that's part of the task of managing a web server.

When you pick a file manager for your server, don't think only about a few buck that you can save by using a free manager instead of a paid one, check how the security is implemented in each one, if an attacker is able to get control of your server you can lose many times that money trying to getting it back to normality.

Public release of new Google Maps for CKEditor might finally see the light of day

2010-12-30T16:52:00.001+01:00

For quite some time I've got almost ready a port of the Google Maps plugin for FCKeditor to the latest version of each API: Google Maps 3 and CKEditor 3, but there was a major problem that I wasn't happy about and that was the lack in GMaps 3 of the ability to create and edit polylines and areas.

I could have go ahead and state that it's finished without such feature, but that wouldn't be honest.

Or I could have worked out my own implementation, but I already created such code in the old times and I wouldn't like to do it again because I can't spend enough time polishing any issues and making sure that the code works correctly and that it's correctly optimized.

So I waited and waited...

And finally, yes, today they have stated that they plan to release it in the first quarter.

With this light at the end of the tunnel I'll try to verify that everything else keeps working as I left it some months ago and I'll be very happy to state that it's finally released even if there are some other missing features from v2.

Christmas present: WriteArea 1.0 is available

2010-12-28T15:55:00.001+01:00

Last night, Jorge Villalobos as Mozilla reviewer approved the 1.0 version of Write Area as an update, so now you should start getting update notifications for this version.

What do you get with Write Area 1.0?

With Write Area you can use the best WYSIWYG web editor inside your Firefox: in any site that allows to input HTML, either with a textarea or even from other not-so capable editors, you can launch Write Area using the context menu and that way you'll get full editing capabilities.

This version has been adjusted to avoid the existing problems with Firefox 4, so the upgrade of Firefox should not cause you any trouble. Some other details have been improved like focusing existing instances.

The internal editor core has been changed from the old FCKeditor 2.6 to the latest CKEditor 3.5, so future upgrades should come out sooner now that the used editor is again one under very active development. Nevertheless, updates in an extension requires review by a AMO editor, so instead of releasing an upgrade with every CKEditor release I might publish a "beta channel" version for minor updates and a full one where there's a new milestone or some important bugs fixed.

Besides that, you can keep using the internal Firefox spellchecker in a normal installation of CKEditor if you install the Gecko SpellChecker plugin.

Go ahead, click and install this extension.

(another post powered by Write Area)

Little test of Firefox 4 beta 3 for mobile

2010-12-22T22:30:00.005+01:00

As Mozilla has just released Firefox 4 beta for mobile, and due to a talk this morning with Garry about editing in mobile I wanted to check how does it rate just in a quick test of contentEditable vs the default webkit-based browser.

The basic test at the previous post is enough for the initial checks and it doesn't require anything special, anyone can easily test if his browser includes the basic functionality expected in a modern browser.

Here's a testing area again:

Type here.., a link (it's part of the content, so it shouldn't be active)

First test: I click on the div and a caret shows up. Firefox 1, Webkit 0 (nothing signals that the editable zone has focus)

Second test: scrolling with the trackball moves the caret. Firefox 2, Webkit 0 (it scrolls the screen)

Third one: clicking on the link doesn't tries to open it. Firefox 3, Webkit 0 (it opens the linked Google page)

Fourth: The keyboard opens automatically when the div is focused. Firefox 4, Webkit 0 (You must open it by long pressing the Menu key)

Fifth: Typing (default keyboard) is slooow, very very slow. Firefox 4, Webkit 1 (in this page it works as fast as any other input field)

Sixth: Typing with Swiftkey, it tries to edit the contents, it's almost impossible to use it. 8pen seems to behave a little better. It seems that the Android browser tells the keyboard to send only single characters or to ignore autocomplete, I don't know how to explain it, but for this situation I think that using the Webkit method works better. Firefox 4, Webkit 2

Seventh: tweaking the CKEditor env.js file to allow the Android browser, we can test it in the full environment. The context menu opens/remains open at the 0x0 of the content, trying to type anything is almost impossible, the editor gets the focus, the keyboard opens and then it's closed automatically. Firefox 4, Webkit 3. The context menu doesn't show up and once the keyboard is forced it remains there. This could be something that can be tweaked in CKEditor, as the simple test doesn't behaves so badly.

Conclusion:

None of them are usable :-(

Maybe Firefox could be much better if it was able to select/configure the way that the keyboard opens, and then we should try to understand why it behaves that way in the full editor. Besides that, Firefox is still missing other features (the zoom function seems much worse than webkit) so we just need to be sure to fill a ticket with Firefox so they might fix it in the future.

Edit 1: I've filed bug 621438 for the Firefox problems with the keyboard.

Updating translations in CKEditor

2010-12-11T15:57:00.003+01:00

CKEditor is fully coded so it can be used in any language (many other simple WYSIWYG editors work in only one language), it just needs the translations for the used strings, and that task is done by providing a language file as found in the _source/lang folder.

Currently it ships with 57 translations, but unfortunately many of them are quite outdated in my point of view, so in order to avoid wasting too much space with outdated files I've chose to remove any language that is missing over 200 sentences (the total number of entries for 3.5 right now is 346)

That means that Write Area 0.9.5a2 includes only 32 languages (saving 90Kb), but as I said, I'm planning on removing languages that are missing more than 100 entries, than means removing other 13 files and the savings won't be as big as the first removal, but i don't see a reason to ship something that only works half of the time. If the user sees dialogs with mixed English and local language I think that it might look more weird than seeing everything in English.

But there's something that you can do if you want to see a fully translated CKEditor: provide an updated translation to your locale.

The steps are quite easy:

Get the nightly version (it's based on 3.4x instead of 3.5x so it won't include all the new entries, but that's one of the problems with the current dual branch method).
Extract the zip to any folder in your computer (you don't even need a web server for this task)
Open one of the files under _samples, for example _samples/replacebyclass.html
That should work and you should be able to perform any operation with CKEditor (besides saving the contents)
Now replace the "lang" folder with "_source/lang", so it's easier to edit the files
Open the file for your language with a text editor (be careful, files are encoded as UTF8+BOM, so if you are using an old editor it might not open correctly) and search for entries marked with "// MISSING"
You can see there the English text, so write your translations, save and then it's time to check that now they work correctly.
By opening the files from the disk usually it isn't needed to clear the cache, but at the very least you'll have to reload the page in your browser, if you don't see any change, then try to close the browser and open it again.
When you have finished updating your locale, go to http://dev.ckeditor.com/wiki/Bugs and read quickly the steps. The most important part is that you have to create an account and after that you can create a new ticket.
Provide a brief summary "Updated Italian translation" select as Component "UI: Language" and put something simple in the summary stating any notes that you want to add.
Mark the "I have files to attach" and click "Create ticket"
attach your translation and if everything is OK your updated translation will be added for the next release.

Something important to note: Take a look first, maybe someone else has already provided an updated translation and it's just waiting to be added.

And of course, besides adding missing entries you can try to provide corrections over existing sentences, but in that case it's not as easy for us to know if the first translation is really bad and your new suggestion is better, so it's better if you can try to find the original translator and both of you agree with a new file. There are times when someone provides a translation but without looking at those sentences in CKEditor, so maybe the text is too long and is displayed poorly, or it doesn't fit correctly with the rest of the dialog, that's why it's important for you repeat steps 7-8 and check that your new entries fit correctly with the rest of the dialog.

Setting 100% height in CKEditor

2010-12-08T11:50:00.001+01:00

In CKEditor the config.height setting doesn't allow to use percentages, only fixed sizes are supported, but that is not good when you try to provide a dialog that is just the editor without any extra stuff (like in this Write Area pane).

The available option is to use the maximize plugin and execute it using the instanceReady event; that has some little problems:

You have to keep the maximize plugin into the code, although you want to execute it just once.
If you try to remove the maximize button from the toolbar, you'll get an error.
There's a flicker while the editor is first created and then resized.

The way to avoid those problems is to adjust the CSS in your main page, these are the rules that I've included in Write Area to get 100% without the previous problems (keep in mind that I've tested only in Firefox, at the very least you'll have to provide the "cke_browser_gecko" rule also for other browsers (ie, webkit, opera) and test if there are other problems.

span.cke_skin_kama, span.cke_skin_office2003, span.cke_skin_v2 {
 padding:0  !important;
 border:0  !important;
 -moz-border-radius:0  !important; 
 height:100%;
}

span.cke_browser_gecko {
 height:100% !important;
 display:block;
}

.cke_skin_kama .cke_editor, .cke_skin_office2003 .cke_editor, .cke_skin_v2 .cke_editor,
.cke_skin_office2003 .cke_wrapper, .cke_skin_v2 .cke_wrapper {
 height:100%;
}

.cke_skin_kama .cke_wrapper {
 padding:0 !important;
 height:100%;
}

Testing the new Write Area

2010-12-05T23:39:00.004+01:00

I think that I've found the problem that caused Write Area to reset the toolbar configuration in Firefox 4.

Let's hope that the rest of adjustments are fine and I can release this version soon (yes, it includes CKEditor, the 3.5 SVN. It weights 483 Kb, so I'm not sure about trying to remove more things that aren't too useful)

Update 1:

I've reduced 90Kb by removing the translations that had over 200 missing entries. It might make sense to even remove translations with over 100 missing entries.

~~Currently there's a problem as the toolbar Cut and Copy commands don't work like they used to do (without any warning), so I'll have to check what has been changed.~~ I've fixed that problem with a little change, due to the default security settings I don't think that many people have been able to test that code before.

Update 2:

The current work is available in the "beta channel", you can get it in the Write Area page, and scroll down searching for "beta channel". I've removed several plugins, looked for unused files, and everything that I could find to easily reduce the size (changing the core to remove code for other browsers is not a valid option in the long term).

I've applied also some fixes that might not be available in 3.5, but I think that they provide a better experience. Some parts might not work correctly as the 3.5 still isn't finished and there might be unexpected bugs.

Compressing a folder with Firefox nsIZipWriter interface

2010-08-08T23:28:00.002+02:00

Writing an extension in Firefox is usually done in Javascript, but instead of using just the classic features available to a web page, there are many others that are exclusive to the inner workings.

One of those features introduced in Firefox 3 is nsIZipWriter; with this interface it's possible for an extension to create or modify a zip archive without the need of any external program.

And that looked perfect for some code that I was planning so I looked at it and after reading the docs page and a little testing I created this zipFolder function that takes as arguments a nsFile object that points to the folder that you want to compress, and the second argument is a callback function.

It takes the contents of that folder (including subfolders thanks to the addFolderContentsToZip recursive function) and compress them in a temporary file that you can use afterwards as it's the parameter passed to the callback function.

The only "problem" is that there is no progress notification about the task, I've configured it to do the job asynchronously (that's why it uses a callback to be notified of the end of the task), but that doesn't allow to set any progress listener or use an interval to check for the number of bytes processed.

/* Zipping functions */
const PR_RDONLY      = 0x01;
const PR_WRONLY      = 0x02;
const PR_RDWR        = 0x04;
const PR_CREATE_FILE = 0x08;
const PR_APPEND      = 0x10;
const PR_TRUNCATE    = 0x20;
const PR_SYNC        = 0x40;
const PR_EXCL        = 0x80;

/**
* folder is a nsFile pointing to a folder
* callback is a function that it's called after the zip is created. It has one parameter: the nsFile created
*/
function zipFolder(folder, callback)
{
 // get TMP directory  
 var nsFile = Cc["@mozilla.org/file/directory_service;1"].  
   getService(Ci.nsIProperties).  
   get("TmpD", Ci.nsIFile); 

 // Create a new file
 nsFile.append( folder.leafName  + ".zip");
 nsFile.createUnique(Ci.nsIFile.NORMAL_FILE_TYPE, 0666);  
 
 var zipWriter = Components.Constructor("@mozilla.org/zipwriter;1", "nsIZipWriter");
 var zipW = new zipWriter();
 
 zipW.open(nsFile, PR_RDWR | PR_CREATE_FILE | PR_TRUNCATE);
 
 addFolderContentsToZip(zipW, folder, "");
 
 // We don't want to block the main thread, so the zipping is done asynchronously
 // and here we get the notification that it has finished
 var observer = {
  onStartRequest: function(request, context) {},
  onStopRequest: function(request, context, status)
  {
   zipW.close();
   // Notify that we're done. 
   callback(nsFile);
  }
 }

 zipW.processQueue(observer, null);
}

/**
* function to add the contents of a folder recursively
* zipW a nsIZipWriter object
* folder a nsFile object pointing to a folder
* root a string defining the relative path for this folder in the zip
*/
function addFolderContentsToZip(zipW, folder, root)
{
 var entries = folder.directoryEntries;  
 while(entries.hasMoreElements())  
 {  
  var entry = entries.getNext();  
  entry.QueryInterface(Ci.nsIFile);  
  zipW.addEntryFile(root + entry.leafName, Ci.nsIZipWriter.COMPRESSION_DEFAULT, entry, true);
  if (entry.isDirectory())
   addFolderContentsToZip(zipW, entry, root + entry.leafName + "/");
 } 
}

Hope you find it useful, it's mostly putting together some sample code and doing some tests, but if you are trying to do it and have some problem it's usually nice to find some code that works as it might be the hint to understand your problem.

SendToPhone now handles market links

2010-08-03T19:11:00.002+02:00

Last week Patrick proposed a simple idea to workaround a limitation in the current ChromeToPhone app that doesn't allow to send anything but http links: if we use a proxy server, we can send a link to that server that when called from the phone returns the real link.

He did make some tests and worked so the next step was handling automatically market: links so that instead of Firefox asking what to do with such links, they are redirected to the phone, and thanks to the Torrent Server Handler extension we were able to learn the kind of code required to do the job. This is one of the beautiful things about open source, besides having the official docs that can be daunting for a newcomer, Patrick was able to look at that extension and we had our own market: handler.

Unfortunately it didn't seem to work with the changes in Firefox 4 about that kind of code, but I was able to re-arrange the code and created a new version that after some rewrites works in Firefox 3.x and 4.0b and also takes care of automatically enabling/disabling the handlers as soon as the corresponding preferences are toggled.

So we just had a little pending work: UI to change the protocols (check the last screenshots), some reported bugs and other minor improvements and finally we published version 1.0 yesterday. It might take some days until it's reviewed and approved, but if you are brave and want to have a big smile in your face, go to the version listing and install that 1.0

Of course, some people might be a little worried about the proxy server as it isn't using a secure connection, but as this is meant to be just a temporary workaround and we don't expect you to send military secrets with this kind of links I think that it should be OK. But in any case, you can change the url to any server that you like and you just have to put basic HTML page with just this code:

<script type="text/javascript">
 document.location = unescape( location.search.substr(5) );
</script>

and set the url in about:config for extensions.sendtophone.proxyUrl, for example with a local server you can use this url: http://192.168.0.29:8888/protocolHandler.html?url=
(the substr(5) in the javascript code is meant to remove the "?url=", so if you change that part remember to adjust the value).

If you enjoy this extension, it would be nice if you cold spend some little time to test the new version and report us if you have found any new problem so we can fix it ASAP. On the other hand if it's working fine, please write a nice review to offset the people that are still trying to install it in non-Froyo phones and write negative reviews.

Performance impact by extensions

2010-07-24T21:58:00.002+02:00

As suggested by recent the recent post, today I wanted to check the startup performance of my Firefox extensions.

The first step was getting the timing values, and I must say that it's really crazy how every project is always stating "it's easy, you just have to install this", and that means that you have to install php for one project, the different .net frameworks for another, other request Java, then the jdk, jre, ant, ...., in this case they say that you just have to install both Cygwin and Python in order to get the time!!!

I'm tired of installing things, so I opted to use the macbook and fortunately it seems that Python is already installed in MacOsX so I didn't need to install anything and after a few tests I got the timing values (although I wasn't sure about the unmount part and skipped that script because I didn't want to get a big problem).

Ok, around 1500ms with the default profile. So I disabled some add-ons and got down to 1000ms, wow, 50% improvement.

Then I checked both WriteArea and SendToPhone (the current as the next one that includes some drastic changes) and it seems that the startup time was similar, I didn't notice a performance hit due to enabling or disabling the extensions, and that's logical because they don't really do too much things at startup, just some listener for context menus, an overlay here and there,... but no heavy duty. That means that fortunately I don't have to work in order to improve the performance.

Finally I started re-enabling the rest of extensions and checking the times and the culprit for the 500ms hit is.... Firebug!

I don't want to say bad words about Firebug because it's really useful, but on the other hand it really needs some hard work with cooperation by the Mozilla guys to find out the issues and address them correctly.

Final UA for FroYo FRF91

2010-07-04T23:16:00.004+02:00

There are no surprises in the User-Agent for the "final" build of Android 2.2 for the Nexus One

Mozilla/5.0 (Linux; U; Android 2.2; es-es; Nexus One Build/FRF91) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

Again, the only change is the build identifier. I tested just in case the demo for contentEditable and it has the same problems, it's almost impossible to use. Even the trackball isn't recognized as a way to move the caret (that is invisible btw).

GoogleMaps for CKEditor 3 is almost ready

2010-07-03T12:07:00.002+02:00

After lots of work to port all the code to the new architecture both of CKEditor 3 and Google Maps 3, the final version is almost ready.

The missing parts

First and foremost: there are three features available previously that won't be ready in this first version because they aren't available in the Google Maps 3 API and I think that it's better to wait for them to port them instead of doing some partial work that requires time and then it will be thrown away.

These features are:

Ability to create and edit lines and areas. Tracked in Issue 2432. In the first versions of the plugin (1.x) I coded some basic editing capabilities for lines showing fake markers, but I think that lot of us are waiting for the port of this feature and hopefully they can port it soon.
Option to show/hide the Overview Map at the bottom right corner. Tracked in Issue 1470. Ok, it's not really that important, so it won't be a problem for most of the people.
Option to show the Google search widget. Tracked in Issue 1697. It adds a nice touch to some pages, but it isn't really needed for most of the maps.

Of course my biggest concern is the editing of lines and areas. For the moment the editing dialog is able to load existing lines and areas from previous versions and change their properties (width, color, opacity), but not to edit their points. As a partial workaround you can use a KML file, but of course that requires the use of a program to create such file. The good thing about KML files is that they can contain lots of data, but if you want to generate a static image then this won't work (Issue 207)

With regards to the CKEditor side, the integration of the dialogs as elements inside the page and the default CSS provided makes it almost impossible to correctly show the maps inside the dialog: there's a CSS rule that tries to reset several values for all the content inside a CKEditor instance, but the way that it's written breaks the CSS inheritance and only the styles that are applied to one element are shown correctly, it can't inherit things like text-align or cursor from its parents, and any <input> that you try to insert doesn't have the default OS styles (in fact it doesn't have any border or background at all).

So some elements that previously were shown inside the map as info windows (text, lines and areas properties) now have their own CKEditor dialogs because it was a nightmare trying to put the controls in a simplified UI.

But despite moving those controls to their own dialogs, there are still some visual problems with the maps: the drag cursor isn't shown, the pointer cursor is instead a text cursor, all the texts are aligned to the left...

The good things

So those are the bad news, let's see the nice side of the changes

The Maps API v3 doesn't require to sign for a key, so that's one step less to worry about, and it can help a lot if you host your site under different domains.

The overall speed is improved, both GMaps and CKEditor APIs are part of the improvement as they have been redesigned to improve performance. Also, in CKEditor the dialogs aren't any longer a new iframe, so they share the same scope with the page, and once the GMaps API has been loaded it doesn't require another check when the dialog is launched again.

I've been trying to reorganize some parts of the code in order to have a better base planning for future enhancements (I won't make any statement about what or when because they might be a distant future), but now the code should be easier to make some kind of improvements.

Some little bugs have been squashed, but for the moment and until it's tested in more environments it can include unexpected problems. An example of something that I didn't ever test previously but now I think that it will work (I'll try to test it correctly) is having two editor instances in the same page and editing the maps in one or both of them.

What's left

I've ready almost all the code, now it needs to be tested more thoroughly, tested across some browsers (no, I won't care about old versions), test that it reads correctly data from the previous versions of the plugin.

Also it needs to try to improve the UI in the dialogs, they way that they are done in CKEditor makes it a little harder to get nice results, but I think that I'm finally getting the grip about that and with some tricks it's getting better, although I won't be happy until I really see that it works as expected and not some "it's not too bad".

Then the basic documentation, how to install the plugin and some user docs, I hope to reuse as much as possible from the previous version.

And then it will be finally ready (I guess that in a week from now).

No, it won't be open source. As the v2 of the plugin this one will be available only under a license, people that collaborated for the previous versions will get this one shortly.

With regards to v2, once v3 gets all the missing features I will provide it for free 3 months after the release of the updated v3 version. I don't see any reason to keep that code locked for ever if it has been deprecated by a newer version.

FormData interface won't be available for IE9

2010-07-01T10:58:00.001+02:00

Not long ago a new DOM interface to send form data with XHR was introduced "FormData", and as shown in this post from the Mozilla guys it can be useful to provide nicer integration for uploading files to the server.

That option is already available in Chrome 5 and Safari 5, Firefox 4 will also support it, (Opera?) so I wanted to ask for this to the Microsoft IE team and filed this ticket, but just today they have replied that they won't be able to support it in IE9.

Does Android 2.2 support contentEditable?

2010-07-01T09:12:00.004+02:00

In Android 2.1 the browser doesn't support the contentEditable attribute for elements, meaning that it's not possible to use WYSIWYG editors in web pages because the virtual keyboard won't popup to write your texts (lots of other operations can be done by manipulating the DOM, but also providing a virtual keyboard might be too much).

One important problem with that status is that although contentEditable doesn't work, isContentEditable does return the "correct" value, and it states that such elements are editable although they aren't so it can't be used to find out if the browser doesn't support contentEditable and when they release a new version enable it automatically.

So I filed a ticket about this some weeks ago, and yesterday I got a notification stating that Android 2.2 a.k.a. FroYo does support contentEditable!

Those are good news, really good news. If it's true, you can expect to see support for your Android phone shortly in editors like CKEditor, TinyMCE, YahooUI,... and apps like GMail, Google Docs....

Anyway, I'm still unsure about that statement, currently I'm using FRF83, that's not the final build because now I'm waiting for the OTA as they said that we should get it during this week, but I've been doing quick tests with the previous builds and I didn't notice any change in the behavior.

You can test it right below. If it works, clicking after the "type here" paragraph should put the caret there and enable the keyboard, and clicking the link should not open the Google home page, let me know if it works in your phone.

Type here.., a link (it's part of the content, so it shouldn't be active)

Nesting dialogs in CKEditor

2010-06-28T22:57:00.008+02:00

The task of upgrading the Google Maps plugin from FCKeditor to CKEditor is getting closer to the end, and in this post I'll show a few screenshots about doing little crazy things in CKEditor (ok, I have done this kind of crazy things previously).

First, let's start with an almost normal CKEditor instance, the only difference is the last button that lanches the new plugin

This dialog has four tabs and below them a Google Maps instance. Showing there an instance that was visible in any tab was one of the first problems that I needed to workaround.

As there was no previous map, it defaults to the third tab in order to ease the task of doing a search of our desired location. Now I'm not searching for anything special, so let's see the fourth tab. There it's possible to add markers, texts and in the future lines and areas as well as KML files. So let's add a marker by clicking the tool and then a point in the map

After clicking the map, a new dialog is shown to edit the properties of the marker, the tooltip that will be shown, the width of the info window and its contents (at the moment it's still missing the button to change the icon color)

Look carefully, yes, it's a CKEditor instance nested in the dialog, so it's possible to write some nice formatted text, and a picture or a link. Of course, that means nesting another dialog!

From bottom to top: Main CKEditor instance, Google Maps dialog, Marker dialog (with another CKEditor instance), and Link dialog.

After closing the link and marker dialogs we can get back to the edited map and test the marker in the first tab (ok, all the code still isn't hooked up, but you get the idea):

The nested CKEditor instance seems to work nicely without any need to do any strange workaround, but I still have to test it thoroughly because the problems might arise only under certain conditions. Anyway I'm happy with that part.

Updated UA of Froyo FRF72

2010-06-19T22:28:00.001+02:00

The User Agent in the new leaked FRF72 build is

Mozilla/5.0 (Linux; U; Android 2.2; es-es; Nexus One Build/FRF72) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

Compared to the previous one, the only change is the build identifier. No change to the WebKit version.

Mozilla/5.0 (Linux; U; Android 2.2; es-es; Nexus One Build/FRF50) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

Send To Phone is now approved

2010-06-04T21:26:00.001+02:00

Today the Send To Phone extension has been approved so installing it should be a little easier and less "frightening", but most important, now it's part of the auto-update so everyone should get the latest version soon.

Well, maybe not everybody because looking at the stats it says that one user has tried to install it in Thunderbird, and someone else is running Firefox 2.0, so I guess that he might have disabled automatic updates (but then why does he wants an extension that requires you to be on the bleeding edge using a pre-release OS in your phone?)

Since the initial release the extension has got some little adjustments:

First the localizations, now they are partly done so if you have an update for your language send it to us.
Then the context menu was improved to allow better control over sending links or images.
After that a little adjustment to try to send the current view while navigating the maps instead of just the Google Maps url
And the last one before approval was a context menu on the toolbar to allow to logout (it just clears the cookie), so you can switch accounts.

Lots of people are downloading the extension and they are happy about it. It's not a revolution about how to use your mobile, but I've found it useful to quickly send to the phone a url or video that I wanted to watch as I move away from the computer.

The next things that might get added is support for more apps (Seamonkey, Thunderbird) and a more controlled login experience (use our own dialog instead of showing the default login in a new tab). Drop here a note if you have a nice idea, but remember that this is only the part for your browser, the Android App is the one provided by Chrome to Phone project.

Debugging web pages in Android

2010-05-30T19:47:00.002+02:00

Finally I've found a nicer way to debug errors with web pages in the Nexus One!

The Android documentation states that console.log calls can be used to send messages to "logcat", and then you need another app or keep the phone connected to the computer with the SDK and whatever in order to read those messages. Too complex.

On the other hand, if you type "about:debug" in the url bar and press go, you won't notice anything special, but if you press the menu button and then "More", you'll notice that there are two extra items at the end, also there are additional settings at the end of the panel (allowing to change the User-Agent for example). And one of them (enabled by default) is to show the javascript console, so now when a page outputs something to the Javascript console you get a little notification bar at the top and clicking it shows the messages without the need to switch to another application.

I don't know where this feature is described and other about: pages that have special meaning in Android.

Little Firefox extension for people with Android 2.2

2010-05-29T22:14:00.002+02:00

One of the new features that it's coming in Android 2.2 or FroYo is the ability to use the Google "Cloud to Device" servers. Basically it is the possibility of an Android App to get a notification from an external server, but without the need to open a connection by yourself and drain the battery and data plan of the user. It's nicely explained in the Android Developers blog: Android Cloud to Device Messaging

Besides the API they have published also a little project "Chrome to Phone" that adds a little button in your chrome browser to send whatever page you are currently viewing to your phone. But despite all the nice features of Chrome I still prefer to use Firefox, the Chrome interface still looks too weird to me and in general I know that I Firefox works mostly the way that I want.

So the next step was quite obvious: it was a Sunday with some free time so I created the Send to Phone extension. It was funny but quickly after publishing it I realized that another guy had the same idea and he beat me by 3 minutes, fortunately it seems that none of us have a big ego so we have agreed to merge both extensions, I picked some of his code, added a few extra things and we got now a nicer version for you to enjoy.

If you did install the leaked 2.2 preview you can test the extension right now, I hope that you enjoy it and find it useful at least for some situations: for example this morning I started watching a YouTube video on the PC, but had to go to the kitchen, so I just clicked the button and then I had the same video on the phone without the need to search anything.

New releases at CKSource

2010-05-29T09:51:00.001+02:00

Yesterday CKSource released the new versions of CKEditor and CKFinder. You can read the updates on each one in their blog posts, but I'm gonna give you my point of view about them.

CKEditor 3.3 is a progressive enhancement over the previous version, lots of bug fixes, some little new features, everything focused on trying to make your experience using CKEditor better than ever before. Of course we have tried to test and verify that everything is working correctly and no regressions have been introduced, but it's just impossible to test all the possible setups and ways that people use CKEditor, so if you find something that used to work in 3.2 or 3.2.1 and now fails, then go ahead to the CKEditor dev site, check for other reports and if you don't find anything create a new ticket explaining the problems and please, provide a test case so that we can reproduce the problem. If you just say "it fails", then we won't be able to fix it, if instead you provide a simple html file then it will be easier to find out what went wrong.

CKFinder on the other side is a complete rewrite of the client part, you'll find now that it follows the behavior of CKEditor, it includes lots of changes and this is just the beginning. With CKFinder 2 it's possible to write both client-side and server-side plugins to enhance your integration and provide new features. Check the provided samples and be sure that we will keep improving it, we just need time and good feedback about what you need. In order to report issues you can use the CKFinder forum

Trying to explain all the features available right now with just a few words isn't easy so I'm gonna stop talking and urge you to test the demos (CKEditor and CKFinder), I hope that you really like them.

Browser updates in FroYo

2010-05-23T10:12:00.001+02:00

As FroYo (Android 2.2) has been "released" for the Nexus One I opted to not wait for the OTA update and yesterday I installed it. The process was very easy and quite fast.

In the Google I/O conference they talked a bit about the new features, and those have been posted over and over again, so I just wanted to talk about the details in the browser.

Previously the User-Agent was

Mozilla/5.0 (Linux; U; Android 2.1-update1; es-es; Nexus One Build/ERE27) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17

Now it's

Mozilla/5.0 (Linux; U; Android 2.2; es-es; Nexus One Build/FRF50) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

The scores at Acid3 and Html5Test remain the same (more about this later)

Animated gifs now work, and also <input type="file">, although its behavior it's a little strange: When you click it it prompts you to select the application to use: Gallery, Sound recorder, Ringdroid and Music track.

Gallery and Music track works as you expect: it shows their listings and you can pick up the file that you want. Sound recorder is also quite what you can expect: you get a simple sound recorder allowing to record, play and confirm the sound, but it doesn't allow to change any setting and the file is saved as .3gpp (AMR 8000Hz 12kbps) in the root of the SD card. I didn't test for the moment to upload it, but refreshing the page leaves the file there, maybe it would have been better placed at the /tmp ? The other strange issue with this Sound recorder is that such app isn't available as a stand alone, why?

Finally Ringdroid, this means that other apps should be able to somehow appear in the list. When you pick Ringdroid it shows a file listing and when you select one, instead of going back to the browser it opens that file in Ringdroid, so you edit it and it becomes the selected one, but you can't pick an existing file without modification.

So now I hope that whatever API is required to use correctly this feature is properly documented so file managers like Astro are able to hook into it and we can use whatever file that we have on the SD card.

Lastly Flash. Yes, Flash 10.1 (beta) available in a mobile device: You go to the market, search for Adobe and install it. Then you can go to browse the web without any worry about if some feature was using it or no, you just use that page. And if you don't want to use it by default you just have to adjust the settings in the browser so add-ons aren't enabled by default so you see a green arrow and can click it to load that flash. Hey Apple-fans, how does that causes crashes or eat my battery?

As I was testing the html file upload I decided to give the flash part a go and it works partly: if the file mask is *.* then you can't pick any file (a "No file was found" message is shown), but if you restrict it to images ("*.jpg; *.jpeg; *.png") then it will show you a list of images and you can select the one that you want (yes, one one at a time). Isn't that weird? if you say that you only want images you get the file listing, but if you allow any file then you can't pick anyone.

Testing Fennec with the Nexus One

2010-04-28T22:47:00.001+02:00

As lots of sites have reported, Mozilla has published a first "pre-alpha" build of Fennec for Android. Of course, I had to give it a try with this little gem know as Nexus One and so I downloaded and installed.

The first impression is that for the moment is still too slow load, doesn't use the bottom buttons, it needs still work, but I think that given the time that they have been working on this the impression is very possitive.

The surprise came when I decided to load CKEditor on it to test if this is again a crippled browser like the stock ones in iPhone and Android, but the surprise is that it works!!!. yes, click on the content and the keyboard pops up and you can change the contents. Selection doesn't work and I haven't tried too many things because the browser itself is lacking for the moment lots of little things, but I guess that this will be the first mobile browser to work with CKEditor and other WYSIWYG editors.

Kudos to all the people that made this possible.

And for iPhone fans: I'm sorry for you, not being able to select the browser to use is a pity. Maybe someday Apple will release a new version of iPhoneOS with a browser that has the same features that their desktop version, meanwhile you'll enjoy only a part of the internet with your mobile.

CKEditor 3 - 2 - 1 - Zero!

2010-04-11T20:37:00.001+02:00

Excuse me for the bad joke in the summary :-)

The good news is that CKEditor 3.2.1 has been released. It contains lots of bug fixes, some minor improvements and it's overall a recommended update for anyone running previous versions of CKEditor. And if you are still using some other WYSIWYG editor, then give it a try because it's really worth it.

IE9 test preview

2010-03-16T19:53:00.002+01:00

The good

So many features we all have been waiting for years. Yes finally rounded corners :-P

Seriously: Massive improvement in JS performance, DOM events, XHTML, SVG, CSS3 selectors... we now need to test how all that works together in real pages.

The bad

Only for Vista and 7. Yes, they say that it's too early to talk about the final version, but if you don't want to talk about the supported platforms right now, how can we have any faith that you will respect most of your customers and won't leave them stuck with the previous generation like you did with Windows 2000?

Don't say that it's due to the drivers or anything like that. All the other browers work perfectly in Windows XP so that's a lame excuse.

You can test it by downloading the preview from http://ie.microsoft.com/testdrive/

Alpha 5 of WriteArea

2010-01-18T00:10:00.001+01:00

These days I've kept on working on WriteArea and today I've uploaded the fifth alpha version. This version is quite better with regards to the detection of other Rich Editors and finally removes a little code that I added for their detection but I knew that shouldn't be included in a final version.

Most important: this version includes an option in the preferences to open the editor in a bottom pane of the page. I've borrowed the close button from the AdBlock Plus skin and I will try to confirm that this is OK before releasing the final version.

There's a little problem with this bottom pane: it isn't aware of tabs, so when you switch tabs it remains there and it's a little annoying, because if you close the pane you might lose all the content. I'll try to find a solution to this problem, although I'm getting already a little tired of so much work in this extension for the last few days.

Alpha release of Write Area

2010-01-14T17:38:00.002+01:00

I've uploaded a beta version of Write Area to AMO as a little preview of what's next.

New plugin

It includes the Syntax Highlighter plugin by Darren James. Remember that you must configure your page with the SyntaxHighlighter by Alex Gorbatchev

With this feature you can include code in your pages like this:

  var script =  writearea.injectScript(this.parentWindow.document, command);
  var info = script.getUserData('editorInfo');
  script.parentNode.removeChild(script);
  // undetected framework
  if (!info)
   info = {
    type:"undetected",
    data:element.ownerDocument.body.innerHTML
   };

In the editor you click the "code" button and in that dialog you paste the contents and select the programming language that must be used to highlight it. In the editor it will be shown like other <pre> code (currently in blue, but I might change that), and in the final page it will show the code as you see above if you have properly installed the js and css files as explained by Alex Gorbatchev.

Not just textareas

The second feature is the ability to use the editor even on top of other editors. It tries to detect correctly some editors, but it should be able to handle any system where a WYSIWYG editor is used. Just right click on the content and click the Write Area entry, and the rest is just the same.

I'll explain this a little better: there are lots of places where some kind of rich editor is used: CMS, Forums, WebMail... The problem is that some of those places use old versions or editors that have very few features, so trying to use them can be a little painful.

My first motivation for writing this extension was that kind of situation where I had to deal for example with the editor here at blogspot. Fortunately for me I was able to disable it and use a plain textarea and easily work with it in my extension, but not all the editors have the ability to be switched off or to show the current source in a textarea, and one day I had a simple idea to detect this situation (check if the document has designMode == 'on') and work with the innerHTML of the body.

This works as long as the editor doesn't use special elements (like the icons shown here for anchors) as that means that the innerHTML isn't really the HTML output of the editor, to get that info (or to properly change the content so it shows any special elements) the API of each editor must be used. That means that there's a set of editors that I'm detecting and in the rest of cases the body.innerHTML is used for read/write.

The current sets of editors that I've coded to detect is as follows:

CKEditor
FCKeditor
TinyMCE 2 & 3
CuteEditor
YUI Editor
Xinha
EssentialObjects
HTMLArea

I could go on adding support for any other editor out there, but I think that this is enough to test the mechanism and verify that I could increase it in the future. I'm realizing right now that the detection could be extended even with a configuration option to add the required script, this is for example the part that detects CKEditor:

 if (window.CKEDITOR)
 {
  match = nodeId.match(/cke_contents_(.*)$/);
  if (match)
  {
   return {
    type: "CKEDITOR",
    data: CKEDITOR.instances[ match[1] ].getData(),
    setDataTemplate: "CKEDITOR.instances['" + match[1] + "'].setData(##DATA##)"
   };
  }
 }

The important trick here is that the code inside the extension can't call any method or access any custom javascript object of the web page, this is done in order to protect the browser from any external attack that tries to run code with Chrome privileges.

So by default the if (window.CKEDITOR) check always fails because as I said, the code in the extension can use the window of the document, and standard properties like window.document, but won't return anything that has been set by a script.

As a test phase I used the real window as returned by window.wrappedJSObject and I was able to verify that the ideas worked, and kept on that way for a little while, but finally today I have changed all the detection code so that it's done in a single place (previously the code looked quite different) and it's merged into a big string that it's added to the web document as a script. That script executes a function that includes all the detection parts and returns an object that it's set as a property of the script DOM node, and then in the other side of the fence, the extension gets back that object with the detected data.

Isn't a little strange that I can't get an element added normally to an object like window, but it's possible to pass an object using node.setUserData?

So back to what's important:
Now you can use this extension almost anywhere, it doesn't matter if it's your blog, your CMS or a WebMail app like Hotmail, GMail or Yahoo, if you want to overcome some limitation of the editor, or a "silly" restriction set by whoever added that editor leaving only a few features, you can right click on it and launch the WriteArea extension to work as you please. Note that you might need to disable the option in the preferences of Firefox to allow the pages to replace the default context menu, and you should be aware that dueto bug 486990 if you are using Firefox 3.5 the page might be able to ignore that restriction (but Firefox 3.6 works nicely).

I plan to do some other enhancements before releasing this as a full new version, but I think that it's worth publishing it as a beta to let people test it.

I might edit this post to explain better how to use each of those two features and why they are useful, but I would like to hear your comments about them meanwhile.

Edit 17th January: I've added an example of the output of the Syntax Highlighter plugin and an explanation of how the detection of other editors work.

New releases of CKEditor and CKFinder

2010-01-12T11:48:00.001+01:00

To start the new year, the team at CKSource has released new versions of CKEditor and CKFinder.

CKEditor 3.1

It is an evolution of the previous version. It's focused mostly on introducing New features, several of them to bring back parts of the old FCKeditor feature set, but there are also new parts like the integration with jQuery and the new Paste system that allows to have a control about what's being pasted into the content.

As these features have been rewritten, don't be surprised if there's a little bug here and there, so if you're sure that something isn't working then head up to the dev site and search for existing bugs (if it's something obvious and easy to reproduce it's highly likely that someone has already reported it). If you can't find any ticket about the problem then file a new one with the steps to reproduce the problem (what's the browser, a sample page to load, what must be done after the page is loaded...) and then if it's confirmed it might be fixed in a future release.

If you don't report the bug with the proper steps to reproduce the problem then your problem might remain there for a long time, but even if you provide a clean set of steps to reproduce, just remember that browsers have bugs so maybe it can't be fixed because it would need some very complex workaround that can introduce other problems or it's just impossible to fix in javascript.

The best way to learn more about the new features is to read the announcement by Frederico and then download CKEditor 3.1 to test them.

Just remember that there's a lot of work going on in CKEditor as you can see in the roadmap.

CKFinder 1.4.2

The simple announcement by Wiktor explains it well, some little bugs, improved compatibility and new translations. The focus of the work is now on the new version that will try to address the missing features that are requested in the CKFinder forum and trying to look even further by making it possible to create more easily new features in the future that no one has dared to request.

There's one thing to notice about this release, as I explained in the previous post Firefox 3.6 hasn't included support of onreadystatechange and the previous versions of CKFinder fail to enable the upload button. The new release includes a little workaround so download CKFinder before your users upgrade to Firefox 3.6 and they call you to ask why does it fail.

Delivering code half-done in a web browser

2010-01-06T17:09:00.001+01:00

Today I was checking something about CKFinder and I've realized that the Upload button doesn't work in the latest beta of Firefox 3.6.

That's strange and quite important as lots of people will be using it as soon as it is released, so I dug into the code to find out the problem. After tracing the differences in the execution of 3.5 and 3.6 I've finally found that when an iframe is created it finish the initialization by checking for document.readyState to avoid problems using an unfinished document in IE, and now that code was triggered also by Firefox 3.6

The fact that Firefox includes a property that was previously supported by IE (and IIRC also Opera and Webkit) shouldn't break anything, that code path uses the document.onreadystatechange to properly listen for the change of state and finish the initialization.

The real problem is that such event hasn't been added to Firefox, so the code never executes!

Everything was OK without support for document.readyState, but now they have added it without including the document.onreadystatechange, so things might get broken due to this big oversight. I suggest all of you to review your code and check for the usage of this event (not to be confused with XHR.onreadystatechange) because Firefox 3.6 might be a real pain for you if you don't patch your code it in due time.

Mozilla guys: thank you for bringing us this extra work.

Zoom Plugin for CKEditor

2010-01-01T13:12:00.002+01:00

Recently all the browsers that are implementing the latest and greatest elements of CSS 3 have added support for CSS Transforms, and so I decided to have a little fun while creating a little example about how to create a custom dropdown element in the CKEditor toolbar.

The idea is to provide a new dropdown that allows the user to set the zoom level for the editor, this example is gonna be a little rough and it can be greatly improved, but this is mostly a proof of concept about how to do it.

The first step is to create the skeleton for the plugin:

CKEDITOR.plugins.add( 'zoom',
{
    requires : [ 'richcombo' ],

    init : function( editor )
    {

    } //Init
} );

That code should be placed in a "plugin.js" file located in the plugins/zoom folder of your CKEditor installation. If you want to create another plugin, you'll use another folder name and put that name as the first parameter in the call to CKEDITOR.plugins.add()

For this plugin we need to be sure that the code from the "richcombo" plugin is loaded, as that's the real code that will create the dropdown element, so we specify it in the requires field of the plugin.

Finally this plugin must be added to the CKEditor instance, so in your config.js (or whatever other place you want to specify it) add it to the plugins that must be loaded:

    config.extraPlugins = 'zoom';

You can place an alert() inside the init function to verify that the plugin is being loaded when you refresh the page with CKEditor. If it doesn't work, verify the error console and try to clear your cache.

Now we need to fill up the code in the init function to create the dropdown:

    init : function( editor )
    {
        var config = editor.config;

        editor.ui.addRichCombo( 'Zoom',
            {
                label : "100 %",
                title : 'Zoom',
                multiSelect : false,

                panel :
                {
                    css : [ CKEDITOR.getUrl( editor.skinPath + 'editor.css' ) ].concat( config.contentsCss )
                },

                init : function()
                {
                    var zoomOptions = [50, 75, 100, 125, 150, 200, 400],
                        zoom;
                   
                    this.startGroup( 'Zoom level' );
                    // Loop over the Array, adding all items to the
                    // combo.
                    for ( i = 0 ; i < zoomOptions.length ; i++ )
                    {
                        zoom = zoomOptions[ i ];
                        // value, html, text
                        this.add( zoom, zoom + " %", zoom + " %" );
                    }
                    // Default value on first click
                    this.setValue(100, "100 %");
                }
            });
        // End of richCombo element

    } //Init

In this function we are creating the dropdown as a "RichCombo" element with editor.ui.addRichCombo() The function takes as parameters the name of the RichCombo and the object that contains the definition. Inside this object there's an init() function that will be called to initialize the dropdown on first click, here we specify the options available in the RichCombo and add them with this.add()

So now we can add to the toolbar of our CKEditor this 'Zoom' RichCombo element:

...
    ['Maximize', 'ShowBlocks', 'Zoom'],
...

Refreshing the page will show now the dropdown and clicking on it will show the panel, although we still haven't specified what must be done when an option is selected. Doing it in a simple way and not trying to optimize how it works we can add this function to the RichCombo definition:

...
                    // Default value on first click
                    this.setValue(100, "100 %");
                },

                onClick : function( value )
                {
                    var body = editor.document.getBody().$;
 
                    body.style.MozTransformOrigin = "top left";
                    body.style.MozTransform = "scale(" + (value/100)  + ")";

                    body.style.WebkitTransformOrigin = "top left";
                    body.style.WebkitTransform = "scale(" + (value/100)  + ")";

                    body.style.OTransformOrigin = "top left";
                    body.style.OTransform = "scale(" + (value/100)  + ")";

                    body.style.TransformOrigin = "top left";
                    body.style.Transform = "scale(" + (value/100)  + ")";
                    // IE
                    body.style.zoom = value/100;
                }
            });
        // End of richCombo element
...

This code blindly tries to set the property for each browser, without bothering about which one is being used of if it supports CSS Transforms at all. We know that IE doesn't support them, but it has supported since long ago the style.zoom so in this case we can use just that.

A correct implementation of the plugin should verify that the browser does support CSS Transforms (or is IE and can use .zoom) before adding the RichCombo, and in the onClick event handler should use just the correct property instead of trying all of them.

This plugin also lacks internationalization, because that wasn't the point of this test, but it should be easy to add and to fix other little things.

But there are two problems that can be seen with just this code:

The first one is that the width of the combo in the toolbar is a little too big to specify some little text like "100%". This is being tracked in ticket 4559 but as you can see by reading all the comments there's no easy solution that can be applied to automatically fix it. So the solution is to add some rules in the stylesheet, although that makes deploying the plugin a little harder. Maybe the RichCombo should be allowed to specify a width in its definition?

The second problem appears only in Webkit browsers (Safari and Chrome), when you open up the panel it will take full height, and it's a little ugly. Other combos have their size specified in the skins css but that doesn't seems like a good solution if you want to publish a plugin that will be used for other people, as well as making upgrading a little harder.

Browser support: The zoom feature should work in IE6+, Firefox 3.5+, current Safari and Chrome (I don't have old versions to test) and Opera 10.5+ (still in alpha)

Happy 2010

GeckoSpellChecker plugin for CKEditor

2009-12-19T18:05:00.001+01:00

A little while ago I created the GeckoSpellChecker plugin for FCKeditor that allows to use the internal Firefox spellchecker from the editing area without any external server.

Now the plugin has a version ready for CKEditor. Be sure to download the 1.0 version for CKEditor, the 0.7 version will remain there for the people using FCKeditor.

I hope that you can find this useful.

Recompressing ckeditor.js to fit your needs

2009-12-18T20:34:00.002+01:00

Note:
Most of the content of this post as well as some corrections are available now at the official documentation for CKEditor: CKPackager - Compressing CKEditor
This post will remain here only for historical reference and to link to the new documentation (the one that you should read)

The javascript code of CKEditor is delivered as one main ckeditor.js where all the code has been compressed and merged (of course, not ALL the code, just the code that is needed for the core and the default plugins, the code of the dialogs for example is loaded on demand). And one question that you might have is: how can I compress my own version? I'll try to provide here some explanations and notes about this, but despite its length it is far from a full guide and it might contain some incorrect parts.

First you have download the ckpackager.jar (there's also an .exe for those in windows that haven't installed Java) from
http://svn.fckeditor.net/CKPackager/trunk/bin/ckpackager.jar and put it at the root of your CKEditor folder. (Note that this is a SVN repository so it should contain the latest version)

Backup the existing ckeditor.js and ckeditor_basic.js so you can check that the process is working correctly.

Now the first step is to verify that you have Java correctly installed and that everything is correct in your environment, so fire up the console/terminal/command prompt and navigate to the CKEditor folder and type there the command to start the compilation. This should generate identical files to the previous ckeditor.js and ckeditor_basic.js if you haven't changed anything in the _source folder:

java -jar ckpackager.jar ckeditor.pack

Maybe the js files aren't identical to the previous ones due to some change in the version of CKPackager used to compress the released version of CKEditor and some fix/improvement made to CKPackager since that moment, but the overall should be similar and you should be able to use the new files without differences.

Working with the source files

Now you can try to apply changes to the files under _source and test them using the ckeditor_source.js, and when you are ready to deploy you just have to compress them all again. You should be careful with your changes because compressing the source means that any slight error can be fatal.

The new packager is based on Rhino, the javascript implementation in Java from the people at Mozilla, so I don't know how it does deal with missing semicolons, and other minor issues that can be fatal with some compression systems. Of course it's better to write code without problems instead of relying on the tools to fix them.

Selecting just what you want

The ckeditor.js file includes all the plugins (but not all the code of the plugins: the dialogs are lazy loaded only when needed as I said). So if you don't want to provide several options to your users you could remove those plugins, not only from the toolbar, but also from the packaged file so you can end up with a much smaller ckeditor.js file.

In order to change what's included you need to edit ckeditor.pack and remove the entries about plugins that you don't need.

Don't alter the entries under '_source/core/*' because the editor probably will fail. Remember that if you mess with the packaging process no one else can help you, you are the one that is editing the file and not knowing what to do isn't a good idea here.

An example of a change would be to remove the line

                '_source/plugins/elementspath/plugin.js',

if you don't want to show the elements path at the bottom of the editor (there's the config.removePlugins = 'elementspath' option but that means that the code is still loaded so if you are sure that you never need this option you can save some bytes). Then you save the file and issue the recompress command, and now the ckeditor.js is 2Kb smaller.

Of course it seems that it would be a trial/error the process to find what are the files that you can remove as one plugin might depend upon another and so you need it to run correctly. In order to generate the default ckeditor.pack file, the SVN version of CKEditor includes a _dev folder with some development tools and that includes a packager folder with a HTML file created to generate the correct content according to the current configuration (this is meant to be used in the SVN version, I don't know how it will deal with the released version).

Optimizing the downloads

If you check the ckeditor.pack file you can see that the lang file isn't compressed, this is due to the fact that not everybody speaks English, so packaging the en.js file for everybody would mean a waste of bytes, but if you know that your users speak only one language, then you could specify that language in the ckeditor.pack file and get it bundled along the others.

This will increase the size of ckeditor.js but remember that those bytes were downloaded separately as another request, so now the editor will be slightly faster as we have avoided that extra step.

At the bottom of the file you can see that the kama.js file is also being bundled, so if you are using another skin you could adjust that to remove the kama and put your own one, avoiding the extra download of your selected skin.

And if you are using some custom plugin you can include it in the list so it's ready along the rest of files and the user don't suffer an extra delay for the usage of your plugins.

This is just a quick explanation, but it should be enough to get started about how to recompress the code.

Adjusting the preview text in easyUpload

2009-12-16T15:55:00.000+01:00

Over the years people have reported that sometimes the users don't understand what's the Lorem Ipsum text that appears in the preview of the image and flash dialogs, claiming that it's not English and it's not what they have written.

The solution is to point them to the source of those dialogs and then remove the offending text (of course they will lose then the ability to understand how the various align values will affect their layout, but it's their choice).

With the improved capabilities of CKEditor this can be done much easier. For example I've added just an id to the uiElement that it's used to create the preview:

        {
            type : 'html',
            id : 'htmlPreview',
            html : '<div>' + CKEDITOR.tools.htmlEncode( editor.lang.image.preview ) +'<br>'+
...

The first motivation to add this id was to provide a way to remove the preview for those that didn't want that in a dialog with simple options. But with just that addition it's possible to write a little code using the 'dialogDefinition' event. First we check that it's loading our dialog and then we can change both the label over the preview as well as the context of the preview:

    var preview = infoTab.get('htmlPreview');
    preview.html = '<div>My image preview<br>' +
        '<div id="ImagePreviewLoader" style="display:none"><div class="loading">&nbsp;</div></div>'+
        '<div id="ImagePreviewBox">'+
        '<a href="javascript:void(0)" target="_blank" onclick="return false;" id="previewLink">'+
        '<img id="previewImage" alt="" /></a>This is some example text around the image' +
        '</div>'+'</div>';

We could change the html to whatever we would like, but in order to mantain compability and keep the preview working we should preserve the "placeholder" elements (div, a, img) and change only the texts (in this case "My image preview" and "This is some example text around the image")

This is the complete function:

// When opening a dialog, its "definition" is created for it, for
// each editor instance. The "dialogDefinition" event is then
// fired. We should use this event to make customizations to the
// definition of existing dialogs.
CKEDITOR.on( 'dialogDefinition', function( ev )
    {
        // Take the dialog name and its definition from the event
        // data.
        var dialogName = ev.data.name;
        var dialogDefinition = ev.data.definition;

        // Check if the definition is from the dialog we're
        // interested on (the "easyImage" dialog).
        if ( dialogName == 'easyImage' )
        {
            // Get a reference to the "Info" tab.
            var infoTab = dialogDefinition.getContents( 'info' );

            var preview = infoTab.get('htmlPreview');
            preview.html = '<div>Image preview<br>' +
                '<div id="ImagePreviewLoader" style="display:none"><div class="loading">&nbsp;</div></div>'+
                                    '<div id="ImagePreviewBox">'+
                                    '<a href="javascript:void(0)" target="_blank" onclick="return false;" id="previewLink">'+
                                    '<img id="previewImage" alt="" /></a>This is some example text around the image' +
                                    '</div>'+'</div>';
        }
    });

Another option to customize the lorem ipsum text would be to mark is as a configuration option or language item (like the title above it: editor.lang.image.preview), but this is a worse move in my point of view. I haven't studied if I'm wrong and it can't be done other ways, but it seems that then it will specify the whole "Lorem ipsum... " text at the plugin.js level or in each language file. Either of those options means that all that text will be loaded whenever the editor is loaded even if you are not going to use the image dialog, and the reality is that very few people don't understand that this is just some placeholder and the important thing is only the image, not the text.

Going even further with the customization, the first option (despite its simplicity) is more powerful because it could be used to inject other elements in the html so you could turn it into a real preview by changing the contents of the box with parts of the current content of the editor each time the dialog is loaded. I won't recomend that as it might mean some extra work to make it work as desired, but it's certainly doable.

So I would say that just adding the id is enough and it can allow the developer to chose betweeen removing the preview (this requires some other fixes in that dialog) or change its contents.

Uploading .app files

2009-12-12T21:14:00.003+01:00

Developing an extension for an application like CKEditor means that you have to be aware of the environment. CKEditor tries to cover the differences between the browsers and even adds workarounds for the bugs that are known in each one (as long as it's possible of course)

So when you are writting your code and something doesn't work as expected you have to start searching for bugs in your own code (the usual culprit), then you have to review how you are using the CKEditor API, verify that you have understood the explanation and that it matches the actual code that you have written. Then you escalate up the problem to the CKEditor source code, maybe there's some bug there that it's causing your problems. And sometimes you have to get even higher in the chain...

One of these situations is an issue that I've talked about in the post about uploads in CKEditor, I did try to apply an onChange listener for an uiElement with type="file", but it didn't work. After debugging the issue I found that despite the huge differences in DOM (this element was created as an iframe with a form and the <input type="file">), the event listeners aren't aware of this difference, so they apply the listeners to the container <div>.

This week I've been writing the code to fix this problem (that's the beauty of open source, when a problem is spotted it's possible to really check what's going on under the hood and create the patch without waiting for a company to include it in their plans), and after some tests it seemed to work: as soon as the user picks an image from their computer it is uploaded to the server and they just have to review the Alt attribute, the Class or the Title.

I had to review that the events are being reapplied correctly when the iframe recreates, so the tests (somewhat random) also included uploading non image files to verify that they are handled properly and everything still works.

Then I started to find that something was wrong, I selected an application, the file picker showed the name but there was no message. I debugged it further and the onChange event was being correctly fired (well, at first it was fired too many times due to a bug in the logic to append the listeners, but this is what these tests were about).

Maybe not CKEditor?

I had this form inside an iframe in a lot of nested code with lots of javascript, custom events and God knows what else. The next step was to create a simple testcase to focus on the problem:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
    <head>
    <title>Upload test</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <script type="text/javascript">
            function fileChanged(e)
            {
                var input = document.getElementById("upload");
                console.log("Selected file: " + input.value);
                //input.form.submit();
            }
        </script>
    </head>
<body>
    <form method="POST" enctype="multipart/form-data">
        <input type="file" name="upload" id="upload" onchange="fileChanged(event)">
        <input type="submit">
    </form>
</body>
</html>

This showed that I could select any file and it showed the name correctly and the form was posted by pressing the submit button or with the js call. But if I selected an application (I'm using currently a MacBook) then it showed the name and the form wasn't submitted. No error message, no warning, nothing.

The simple test removed CKEditor out of the equation and avoided long hours trying to find a non-existing problem in that code, and instead it pointed to some other basic issue with the browser and the upload of Applications (.app)

The current browser was Firefox 3.5, so I searched bugzilla but I wasn't able to find any report about this, the only bug that reported some strange problem was one about sending sometimes files with 0 size to the server.

So I added

                console.log("File size: " + input.files[0].fileSize);

and it showed the .app to be files of 0 size.

Something is quite wrong here!. I tested Safari and it seemed to allow the upload the .app but it showed the size as 102 bytes instead of several Mb.

Then I finally realized that an Application in Mac OS X is really a folder with subfolders and files, so this is the reason why it fails. Firefox accepts the .app in the filepicker but at the upload time it somehow sees that it is a folder (or that it isn't a real file) and rejects to send the form, but as I said, there's no warning about the problem. Testing with Opera did provide a message stating that the path pointed to some file that it couldn't find.

The most interesting situation was Safari, I changed the form to point to a real script that would handle the file and the result was that the application has been compressed on the fly and sent to the server as a .zip

How does each browser behave?

This is a live test with some code similar to the above:

So on one hand we have Firefox, it doesn't allow to upload the .app and doesn't provide any hint that there's a problem with the selected file. Also shows the size as 0.

Opera does its job much better and shows a tooltip on the <input type="file"> explaining that there's a problem there. Better but still not good enough as people might get confused about the reason of the problem. It hasn't implemented the API to get the size of a selected file.

Safari is quite different, if you select an .app then it will compress it and send it as a .zip so even if the user might find it a little strange that it has bothered to compress the data he finds that he was able to upload the file that he wanted. The only issue is that it shows the size as 102 instead of showing the same data that it's in the Finder.

The final test was the new beta of Google Chrome. Like Safari it showed the size of an .app as 102 bytes, but when I tried to upload it to the server (localhost) it just hanged. It showed a warning about a non responding page and no matter if I selected to close the page or ignore the warning. Chrome was dead and the only solution was to force quit it, even if the tab can be closed, something remains working there that didn't allow a clean exit.

So this can lead to one bug report for each browser (well Opera is almost OK, so it should be just a feature request), so much fun and job for a little test trying to find a bug in my code or CKEditor.

Adjusting the context menu of CKEditor

2009-12-11T21:52:00.001+01:00

The easyUpload plugin aims to replace the default image & link plugins as they can be seen as too complex, so we can expect that the config won't include their buttons in the toolbar, but the context menu entries will still be shown even if the command isn't available in the toolbar.

So you might think that it's just a matter of removing the "image" plugin, but you'll find that the context menu is still there. After a little digging you might be able that this is due because the "forms" plugin has stated that "image" is a requirement (for the input type="image). Then the next step would be to remove the forms plugin, but maybe that's a little too much.

Or what about the link plugin? It does include the unlink command as well as the anchor, so if we remove that plugin we need to copy all that code to another file.

The solution would be to remove just the context menu entries for those items that we don't want. In order to do this you need to study a little how the context menu plugin works and you'll find that it stores the available items in an object: editor._.menuItems and when the context menu is fired, every listener returns the object that should be shown at that time, but if that entry doesn't in the editor._.menuItems then it just skips that order.

So we can do this in our plugin to remove the context menu for the image plugin:

    afterInit: function(editor)
    {
        delete editor._.menuItems.image;
    },

On the other side, this plugin creates its own entries for images and links, but maybe you want to use only the new image dialog, so we need to apply some cleanup to the context menu.

Then instead of just hardcoding the elements to remove from the context menu the approach is to review the elements that are defined for the toolbar comparing them with a list of items that can be removed if they aren't used and then finally remove from the context menu all such items.

    afterInit: function(editor)
    {
        // Remove the default context menu for elements that aren't being used in the toolbar.
        // This object is composed of the button name and the name of the context menu entry
        var removableEntries = {Image:'image',Link:'link',Unlink:'unlink',EasyImage:'easyimage',EasyLink:'easylink',EasyUnlink:'easyunlink'},
            // Get the data that is being used for the toolbar, we end with an array of arrays.
            toolbar =
                    ( editor.config.toolbar instanceof Array ) ?
                        editor.config.toolbar
                    :
                        editor.config[ 'toolbar_' + editor.config.toolbar ];

        // Loop the main array (composed of groups of commands)
        for (var i=0; i<toolbar.length; i++)
        {
            var items = toolbar[i];
            if (!items)
                continue;
           
            for (var j=0; j<items.length; j++)
            {
                var buttonName = items[j];
                // If it was marked at our check object remove it because it's in use
                if (removableEntries[buttonName])
                    delete removableEntries[buttonName] ;
            }
        }
       
        // Remove all the entries that aren't used in the toolbar
        for (var command in removableEntries)
            delete editor._.menuItems[ removableEntries[command] ];
    },

With this code our plugin will take care of leaving only the correct entries in the context menu without any extra configuration

Plugin localization in CKEditor (vs FCKeditor)

2009-12-09T17:14:00.002+01:00

If you work in the web you should have already realized that there are tons of people from every where and that not all of them speak English, and even if they are able to understand it they might to work with their native tonge, so providing the ability to translate your plugins it's important if you want them to be used anywhere.

Adding the plugin

In FCKeditor the registration call of the plugin did specify the available languages:

FCKConfig.Plugins.Add( 'easyupload', 'de,en') ;

In CKEditor there's no call to add a plugin, just a list of plugins and two other lists to add extra plugins or remove existing ones (each list is just a comma separated string with the names of the plugins). So that call would be something along the lines:

config.extraPlugins = 'easyupload';

But that doesn't specify the languages available for the plugin, now instead is the plugin itself the one that specifies what are its available languages:

CKEDITOR.plugins.add( 'easyupload',
{
    // translations
    lang : ['en'],
...

The translation file

The available translations must be placed as previously under the pluginfolder/lang/languagecode.js being pluginfolder the name of your plugin and languagecode the code of the language ('en' in the above case), so we would end with a file under plugins/easyupload/lang/en.js for example.

The structure of this file is quite different from the previous one. In FCKeditor the file was a simple list of properties added to the FCKLang object:

FCKLang['EuImgDialogTitle']  = 'Insert / Edit Image' ;

Now the file is made of one (or several depending on how you have defined your data) call to the CKEDITOR.plugins.setLang method that gets as parameters the name of the plugin, the language code and an object that contains the definitions of the strings:

CKEDITOR.plugins.setLang( 'easyupload', 'en',
    {
        easyimage :
        {
            toolbar: 'Insert/Edit an image',
...
        }
    }
)

Usage

And so the way to use it now is also slightly different, the "lang" object of the current editor instance has been augmented with your definitions:

        editor.ui.addButton( 'EasyImage',
            {
                label : editor.lang.easyimage.toolbar,
                command : 'easyimage',
                icon : this.path + 'images/image.gif'
            } );

Dialogs

Now all the dialogs are created from javascript objects, there are no html parts to load so there is no need for the "fcklang" attribute and the call to FCKLanguageManager.TranslatePage(document)

Class selector in easyUpload

2009-12-08T17:51:00.001+01:00

Following with this serie of posts about the new easyUpload plugin for CKEditor, today I'm gonna talk about the class selector for images.

What's the class selector

The selector is used due to two reasons:

Avoid showing the user all the options about Border, HSpace, VSpace. This avoids clutter in the dialog, avoids the use of presentational attributes (changing the underlaying code to use sytles instead of attributes is not enough, they are placed there on each image and so they can't be used in a somewhat unified way) and puts the presentation in the stylesheet instead of the html document.
Asking users to use a text box and learn the available class names that they can use it's not an option. They won't. It's not their job to learn the names that the designer has selected so they are gonna use any kind of cheatsheet, so it's better to offer that cheatsheet inline so they pick the one that they want and see how it does affect the image.

You can try to tell them to just upload the picture, don't change anything in the dialog about the presentation and use the Styles combo in the main menu, but this is too complex: If they shouldn't use something in the dialog, then they shouldn't see that option at all, and it seems logical to then put the options of the Styles combo related to the image in that dialog.

There's something about this option that you might argue that it shouldn't be done this way and it's the fact that only class names are used from the Styles data. It won't use the css style="", or any other attribute that you can specify in the definition of that Style, but I've already said that from my point of view this is better to avoid leaving scattered attributes and styles all around the HTML instead of putting the presentation in the stylesheet.

This is an example of a valid definition that would be shown in the class combo of the easyUpload dialog as "Nice picture" and if selected the image would end up with a class="highlighted"

    {
        name : 'Nice picture',
        element : 'img',
        attributes : { 'class' : 'highlighted'}
    },

CKEditor vs CKEditor

The UI of the dialog is quite similar to the previous one for FCKeditor (some small layout differences aside), but the underlying code for this feature is quite different.

In order to make this feature work, previously I just re-scanned the data in the FCK.Styles.GetStyles() array looking for element=img and the use of any class. But the new implementation of the styles combo makes this approach impossible. It's using private data locked inside the object so it can't be used outside of it, and thus the plugin now needs to copy the loading data code (fortunatelly the "resource manager" in CKEditor means that the file is loaded only once and then it's shared for every later request). Trivia: This investigation of the source code led to a bug found while trying to understand the behavior; The styles combo is "dead" until you first click on it, its initialization is delayed until it's shown so if you don't click on it, the data that it's shown is always the same because it has no data to match the current style of the selection.

The bad part about having to request the load of the stylescombo data is that if in the future the format of the data is augmented to allow XML files like it was possible in FCKeditor, or even if a plugin is added that does allow to parse the stylesheet and create the proper entries automatically, then that code won't work for this plugin due to the fact that it's hardcoded to load just the js definitions file, the easyUpload plugin would need to copy again the part about how to load the styles data.

The idea about creating a plugin that does scan the stylesheet and automatically populates the Styles data instead of having to define in an external file the available Styles is a clear advantage. I've been using one such plugin for several years in FCKeditor and I've never had to care about adjusting the (at that time) XML file with the definition of the style for each site. Just defining properly the css selectors in the stylesheet is enough to make the plugin parse the data and fill the combo. Unfortunately the code was developed for a company so it can't be shared, but I can assure you that it's quite simple; Due to the new structure (with private data) of CKEditor I'm not so confident about the ease of coding it to use this kind of feature in the new version. But if you look at the posts of beginners (and maybe not-so begginers) about the use of the Styles combo a question repeated over and over again is why the styles combo isn't filled with the data from their stylesheet.

Using your own Uploader in CKEditor

2009-12-07T16:21:00.002+01:00

CKEditor still doesn't include its own file manager, but the hooks to integrate your own uploader script or file manager are already in place, as you can check win CKFinder or any number of third party scripts that people have been writing.

Upgrading from FCKeditor

Maybe you want to use a previous uploader that you've used in FCKeditor and you are not sure about what are the differences, and the current documentation isn't clear enough for you. I'm pointing here the differences for the upload (or "quick upload") part, I might try to cover the slight differences in the "File browser" in other post.

The file is sent as "upload" instead of "NewFile". Note that this is the value that you'll get using the default dialogs, but the name of the input is the id applied to the uiElement used to create the widget so in some situations you might get a different name.
Some additional info is sent along the request as GET parameters: the name of the CKEditor instance, the current language code and a parameter to specify the callback function.
The callback function is dynamic, you must read the "CKEditorFuncNum" parameter and send it back.
There are no special error numbers in the callback function. Your script can return a url to use and a message to show to the user, both are optional so you can return just an URL that will be used in the dialog, or you can return a message that will be shown to the user, or a URL and a message (for example a warning that the file has been renamed and the new URL).
Thanks to the message and the "langCode" parameter you can use localized messages instead of having them in English.

So I think that that is the summary of differences showing that the limitations in the previous API (hardcoded error numbers and messages, no info about the current instance...) have been fixed.

Practical example

Maybe that's not enough for you, so here's an example "upload.php" file that you can use to study and adjust your code. This code doesn't save any file, doesn't include any security check, it doesn't check for errors... It's just some basic sample explaining what you can do.

<?php

// This is just a simple example, not to be used in production!!!

// ------------------------
// Input parameters: optional means that you can ignore it, and required means that you
// must use it to provide the data back to CKEditor.
// ------------------------

// Optional: instance name (might be used to adjust the server folders for example)
$CKEditor = $_GET['CKEditor'] ;

// Required: Function number as indicated by CKEditor.
$funcNum = $_GET['CKEditorFuncNum'] ;

// Optional: To provide localized messages
$langCode = $_GET['langCode'] ;

// ------------------------
// Data processing
// ------------------------

// The returned url of the uploaded file
$url = '' ;

// Optional message to show to the user (file renamed, invalid file, not authenticated...)
$message = '';

// In FCKeditor the uploaded file was sent as 'NewFile' but in CKEditor is 'upload'
if (isset($_FILES['upload'])) {
    // ToDo: save the file :-)
    // Be careful about all the data that it's sent!!!
    // Check that the user is authenticated, that the file isn't too big,
    // that it matches the kind of allowed resources...
    $name = $_FILES['upload']['name'];

    // example: Build the url that should be used for this file   
    $url = "/images/" . $name ;
    // Usually you don't need any message when everything is OK.
//    $message = 'new file uploaded';   
}
else
{
    $message = 'No file has been sent';
}
// ------------------------
// Write output
// ------------------------
// We are in an iframe, so we must talk to the object in window.parent
echo "<script type='text/javascript'> window.parent.CKEDITOR.tools.callFunction($funcNum, '$url', '$message')</script>";

?>

If the code is deemed worth, it might be added to the wiki (for example in Custom File Browser, or creating a new article "Custom Uploader") but before doing so I would like to hear a little feedback.

Simple things are hard to achieve

2009-12-06T16:13:00.003+01:00

A very important part of easyUpload is that it must be easy, it should protect the user against unexpected behavior, it should be straight forward and simple, let's see two details:

Tabs

There are no tabs in the dialog. If no image is selected in the editor then it starts with a screen asking the user to select the image that he wants to use, and the options are quite clear: upload from the computer, browse the server, use an url.

In order to hide the tab bar (because in reality the code is splitted in two tabs, but only one of them is visible each time) I had to find a workaround because as I said only one tab is visible, but the code checks for the number of tabs and then it decides to make the tab bar visible.

So this is one possible solution (in the onShow method of the dialog)

this.parts.tabs.hide();

This does indeed hide the tab bar, but the spacing remains there, a better solution is to mark the dialog as "single paged":

this.parts.dialog.addClass("cke_single_page");

This little trick adds the class used by CKEditor to mark a dialog as single paged, so the tabs bar is gone as well as the spacing.

Ok button

If the user browses the server, as soon as he has picked the image the first screen dissapears and then the image properties are shown. The other two options have a button each one to confirm the selection, but there's a problem: the big "OK" button at the end. Users might click on it instead of using the one besides its option, so we need to listen to this button.

That's easy, you just need to add an event listener on the dialog for the 'ok' event.
But wait, it doesn't work!
The dialog keeps showing the dreaded "Some of the options have been changed", not our event handler!

Fortunately the Event system in CKEditor has a nice feature: The ability to specify a priority for our listener so we just need use a priority lower than the default (10) to get the event first. But if you look at the code you'll find that the dialog constructor adds its listener for this event (the one that later will show the alert) with a priority of 0. Oh, no.

Why does it needs to specify 0 as its priority? If it's the first listener that it's being added (and we are talking about the constructor) it should get fired first by default without the need to specify anything and saving those little bytes in the code.

What can we do now?
If we add the listener also with 0 it will be called later anyway :-(
But...
We are talking about javascript, in javascript there are no unsigned integers, just numbers, so this little trick is enough

    this.on( 'ok', function( evt ) {
...
    }, this, null, -1 );

Exactly, by setting our listener with priority -1 we get over the default one and no unexpected prompts will be shown :-)

Making options simple for the plain users usually requires a significant ammount of time to find the right parts to tweak, so it isn't strange that as the software becomes bigger there are some rough edges and only by focusing on some narrow part it's possible to improve it at the cost of not working on other improvements.

File upload in CKEditor

2009-12-05T15:59:00.002+01:00

CKEditor redefines the way that dialogs are created by defining them as a hierarchy of "uiElements", each element is defined as a JS object and its type define its behavior.

You can see this if you open the source of any of the dialogs and search for "contents :", there you'll find the structure of the tabs and you can see how the "type" property is used with values such "hbox"/"vbox" (for layout of several elements: horizontal/vertical box), other values that matches typical HTML form elements: "text", "button", "password", "textarea", "checkbox", "radio", "select", "html" (this one allows any kind of html to be used directly), and some special ones: "file", "fileButton". These elements and behaviors are defined in the dialogui plugin.

File upload

When you want to provide the "quickupload" feature you must use the "file" uiElement, this one takes care of creating an iframe whose contents are a form with an <input type="file">. But of course, you must specify the url to POST the file, so this is handled by the fileBrowser plugin. This plugin scans every dialog based on the dialogDefinition event and then adjust the properties so the form is created correctly as well as adjusting the buttons used to launch the file browser. This is done based on the existence of a "filebrowser" property in the element definition.

The current definition of the "file" uiElement has some bugs/problems, and so far I haven't fixed all of them as it took me long enough to understand the behavior and I needed to move forward, but I'll try to look at them in order to finish the easyUpload plugin.

One of the problems is that if a user selects a local file but presses the dialog "OK" button instead of the "upload file" [hey, we're talking about users ;-) ] then the dialog might close without any warning and no file is uploaded. This is due to the fact that the .getValue() function is hardcoded to return an empty string, fortunately it's easy to fix that problem at the initialization of our plugin:

        // Fix file input definition:
        CKEDITOR.ui.dialog.file.prototype.getValue = function()
        {
            return this.getInputElement().$.value;
        };

This only causes a little issue: now if you try to close the dialog with the Cancel button it will always state "Some of the options have been changed..." (quite unfriendly message by the way, it would be much better to state "The file upload has been changed..." using the proper label for each element). So we just need to force the initialization of the "initial value" for the element to match the empty string (as I'll explain next, the initialization code is using the container instead of the real <input> so it's doing wrong things at that time)

        CKEDITOR.ui.dialog.file.prototype.setInitValue = function()
        {
            this._.initValue = '';
        };

Of course these two changes are easy and should be available also in the core code, but I needed them right now, so it's easier to provide the fix in the plugin instead of waiting for the patch to get approved.

Pending issues

In the original easyUpload I added the code (that it was then merged into the core) that instead of just letting the user wait for the upload to finish without any indication that there's something going on, he would see the loading throbber. Of course, it's not really "useful" as it doesn't correctly state how much of the file has been uploaded or how much time remains, to see that kind of info you should use Firefox 3.5 with CKFinder 1.4.1.
And it might be argued that sometimes people report problems because they try to upload a file with a wrongly configured connector and they just see the infinite throbber, but the ones that see that problem are the developers setting up CKEditor and I would argue that they should learn a little about all the tools that are available for developers to find javascript errors, server responses, etc...
But let's get back to the topic: the "please wait" message is still missing, and the aim of the plugin is to be user-friendly so it should get one.

Another friendly feature was the automatic upload of the file as soon as it was selected from their computer instead of having to click on the "upload" button.
First let's understand the 'file' widget; it's quite different from the rest of elements as it does create it's own upload iframe, and that iframe is recreated each time the .reset() method is called on it. That happens when you load the dialog, or when a file is uploaded or when the dialog is closed. So every now and the the iframe with the inner form and the <input type="file"> will be recreated, but currently it doesn't fires any event to the parent window, so it can't be tracked to reassign the needed events on it. Besides that, the creation logic of the uiElements is based on assigning the event listeners required on them after they have been created, but due to the iframe element and the oddities of this element, at the time that those assignments happen the inner frame still isn't ready and instead it tries to work with the container of the iframe (quite useless). So the fix for this means that the 'file' uiElement must keep the list of events that it must assign to the inner <input> and that the iframe must notify to the parent container that it has finished loading so it gets reapplied the desired set of events.
Quite a lot of work for a little detail, but the end user just care to use the program without having to take a semminar about uploading files.

The last difference with regards to FCKeditor is that previously if the user picked a ".doc" file in the image dialog he would get immediately a warning stating that this isn't a recognized image format so that won't be uploaded. Now this check at the client side is missing, so the user will upload the file and it's the server the one that must reject it.
This means two things: poorly written server connectors will allow to upload any kind of files at the image dialog and then users will ask why they have uploaded the .doc and it doesn't work (or even worse: iirc correctly Safari in Mac does allows to use a .pdf as source for an img, so they upload the pdf, put it as source for an image and then only Safari users will see the contents). The second problem is that the user has wasted his time uploading the file to the server instead of getting an immediate feedback stating that the file isn't valid for this dialog.

As you can see, there are some rough edges about this functionality that we should expect to improve in CKEditor as it evolves, and meanwhile I'll try to fix them in the easyUpload plugin.

Porting easyUpload to CKEditor

2009-12-04T21:16:00.001+01:00

A little while back I was tasked to upgrade the easyUpload plugin to CKEditor 3. Due to a broken leg this job has taken too long, but it's finally starting to see the end, and I think that writting some little posts about the problems/workarounds that I've used might be useful for other people trying to write some plugins/customize CKEditor.

Given the new events in CKEditor at first it looked like it would be possible to directly use the existing dialogs and then apply our changes over them (you can look at the api_dialog.html file to see how it's done). That was my idea after writting the original plugin for FCKeditor, I saw that I used a bunch of existing code so having a way to modify the dialog before it's used would be great. But the reality is that in their current state those dialogs can't be customized without writting lots of code (and ugly code) to change the inner logic. I'm gonna talk about the image dialog to explain some of its problems, of course I expect this to change in due course and a future version of the plugin might be as clean as originally envisioned.

In the image dialog you just can't remove the preview or the scripts will fail. The possibility of removing that part hasn't been considered/tested and so the code uses it without first testing for its existence. This is easy to workaround (just some "if"s that you can check when the plugin is releaded) and I think that it might be fixed in the official version. Anyway, this isn't a high priority item because the preview is quite nice in order to verify how the image will look like, but if someone cares to provide a patch to do it the chances will be higher :-)

Lock size & Reset size buttons: They are a single entity without any identifier. It's possible to hide them only after the dialog has been created (vs using the dialogDefinition event to remove them like it's possible for other elements). I think that the solution that I've included (just splitting each button as a single element and reviewing a little some scripts that expected those buttons to always exist) is also easy to add to the general code. For me the important part here is the removal of the "Lock size" button, for plain users that option must be checked always and they shouldn't have to option to turn it off, removing it from the screen just removes a question from their minds.

"Some of the options have been changed...", yep, if you load the image dialog with an existing image loaded and then you try to dismiss the dialog, this prompt will be shown leaving you wondering what has been changed and doubting about closing the dialog or not. This is due to a delayed initialization to avoid an IE7 rendering bug (it seems that IE has several problems with the sizes of the dialogs under certain conditions), and so that initialization needs to be patched with the fixed function.

Considering the number of elements to remove, the scripts that needs to be dynamically patched (as explained above) and then the new elements to add with their logic I decided that it was easier for me to start with a copy of the image dialog and then apply all the changes there instead of having to find ways to override everything that I needed while trying to retain the original functions to perform their work.

These are some of the problems that I've faced, but not the only ones, although they have different origin so they must be handled in a different post.

CKEditor is Fast!

2009-11-29T16:02:00.002+01:00

Yep, CKEditor is fast and this is not just a marketing slogan, but a fact. I'm stating this as the reply to this question:

I want to fire some event every time I replace <div id="editor"><div> element pressing "Create Editor" button:

  editor = CKEDITOR.appendTo('editor');
  editor.on('pluginsLoaded', function(ev) {
    …
  });

Everything is OK on first replacement of div. But when I destroy editor with "Remove Editor" button:

  editor.destroy();

and create it once again, event function is not executed.

The problem here is that the second time the CKEDITOR.appendTo is called, all the files (core, plugin, configuration, ...) are already loaded in memory, so the creation process is almost synchronous; as soon as the call is finished, the instance is almost ready and the only event you can attach the second time is the "instanceReady", the rest of events already have been executed by that time. (and that instanceReady is fired later due to the delay loading the iframe for editing and its initialization, maybe if the editor is configured to start in source mode that event is also fired synchronously. Correction, no. Starting with source mode still fires the instanceReady so it isn't related to iframes initialization, but other asynchronous task).

So we can't attach the event using editor.on() because as I said this is too late, the events have already been fired the second time. In this situation you can opt to use maybe the instance "instanceReady" because as I said this seems to be fired always. But we are playing a game with some risk: if the initalization is further optimized in the future avoiding those little milliseconds of delay that event will be fired as well before we get a change to listen to them.

Honestly I didn't speak about the events of a CKEditor instance, and this might be a little hidden topic as the official documentation doesn't explain it for the moment, but there are two ways to listen for the events of an instance.

The first method is what you can read above and everybody is used to in other environments and frameworks instance.on( eventName, callback ). But by the time we get a hold of instance the event has already been fired. Despite that we could use another workaround using the CKEDITOR.instanceCreated event. We can set a listener for that event and due to being assigned to an object that always exists, it will be always fired whenever an instance is created. So this means that any listener that we set on and editor instance inside a CKEDITOR.instanceCreated listener should then be fired even if the process of creation is synchronous. So this is a more promising solution because no matter how fast the computer, browser or CKEditor is optimized, as long as the event remains there we can use it to hook into any new instance and set our listeners.

But the second method is more appropiate for this situation, and it's based on the ability of creating events listener at creation time. It's based on this code from editor.js

                    // Register the events that may have been set at the instance
                    // configuration object.
                    if ( instanceConfig.on )
                    {
                        for ( var eventName in instanceConfig.on )
                        {
                            editor.on( eventName, instanceConfig.on[ eventName ] );
                        }
                    }

So it states that if we pass an "on" object in the configuration object at creation time, the events defined there will be assigned to our editor. And you can indeed try it:

    editor = CKEDITOR.appendTo( 'editor' , {  on:{'pluginsLoaded':function(e) { console.log('instance config::' + e.name)} } });

That event will be fired no matter if it's the first, second or Nth time that the editor is created. You have to be very careful about the syntax as it's easy to make a little mistake with some extra parenthesis or a missing bracket but the error console should warn you in that case.

Controlling the cache with CKEditor

2009-11-14T15:46:00.001+01:00

One of the biggest problems that are faced while developing some javascript code in an app like CKEditor is the browser cache as it doesn't behave like you want to in those time.
Usually the cache is great, it can be very helpful to avoid long delays loading again the shared files, but if it insists on loading the old version instead of the new one that you have just changed then it will be painful.

Depending on the browser that you are using and its configuration it can be easier or harder to force loading the new version. and the last resort is to close the browser, load about:blank and clear the cache, now it should really load the new version (unless there's some proxy between you and the server that doesn't want to cooperate).

With CKEditor 3 there's a new option to solve this problem, "CKEDITOR.timestamp"
Its main use is a way to signal to your users the version of CKEditor, because they will have even greater problems trying to clear the cache. Each new release of CKEditor will have a different timestamp, so the users will load the new version of the files.

You can also this item while you are trying to develop some plugin. You just need to make sure that every time that the page is loaded a new timestamp is generated. A typical way to do it is (before creating your instances):

CKEDITOR.timestamp = (new Date()).toString() ;

But there's one gotcha here. That string is appended to every url in order to make it unique, and at least there's one place where using that will cause a little problem:
If your plugin is providing an icon for a custom button and you use that timestamp you won't see it in the toolbar, instead you'll get the first icon of the toolbar strip. This is due to the fact that such icon is loaded as a background image for the element, and the url that it's generated isn't valid and won't be used.
The workaround is to make sure that it doesn't contains anything that can cause problems:

CKEDITOR.timestamp = (new Date()).toString().replace(/[ \(\)\+]/g, "");

Of course you can use any other way to generate the random string that doesn't have this problem from the start, but I'm too used to just put the date whenever a unique url is required.

Update:

I knew that my solution was too complex and that I did saw something easier but I couldn't remember the place and it was in front of me all the time!. Just open ckeditor_source.js and uncomment the following line

// CKEDITOR.timestamp = ( new Date() ).valueOf();

Instead of generating a string and then removing unwanted characters, using valueOf() returns only a serie of digits so there is no problem, and by having it in ckeditor_source.js means that it's ready everytime that you are working with the source files without having to add the code to the page.

CKEditor events

2009-09-08T22:53:00.005+02:00

The new articles will be focused on documenting the events fired by CKEditor as currently there's no documentation besides the source code.

Events are the way to hook different pieces, the glue for the plugin architecture of CKEditor that allows to replace / add several parts without going nuts. In this regard, this doc page is a must read for anyone that really wants to understand the basics about how it works. If you don't read it then you'll be lost and you'll ask questions that have already been answered there.

Yes, that page is quite generic, so we have to looks at the API docs for the CKEDITOR.event information, here we can find out exactly the details about how those ideas have been implemented.

As a summary: an object might implement this Api, so you can listen to their events adding your listener. The syntax is similar to the standard DOM events, but it has some slight improvements like the ability to specify an object upon which the listener must be called without resorting to extra code and specify a priority for the listener (you might need this very few times, but it's nice that it's there).

As any other event system you can remove your listener, and if you need to, you can fire an event whenever you like, on an standard object, your own object, some standard event or your own event.

Something important must be remarked at this point: If you try to register a listener to a non-existing event you won't get any error, but of course it will never be executed. So don't try to put ckeditor.on('imageDeleted') ckeditor.on('fileAdded') or whatever. Unless you write the code to fire those events you are wasting your time. Why does the event system allows to do that: because you can create any event that you want, so the system just register your listeners, expecting that you know what you are doing and the event will be fired later by any other code.

So now we now the basic, let's look at the events of one object

CKEDITOR events

CKEDITOR is the main object of the whole API, and it can fire several events that are useful to do some basic and generic tasks

"loaded"
The first event is fired only if you have used the basic integration, obviously if you use the full code from the start as soon as your code is executed the core is ready (or you wouldn't be able to call CKEDITOR.on() ). Also, there's no editor sent in the eventInfo object.

"instanceCreated"
Each time an instance is created this event is fired, before it's configuration is initialized.

"instanceReady"
It signals that the initialization of an instance has finished.

"currentInstance"
Fired when an editor gets or loses focus. (After CKEDITOR.currentInstance has been updated. This is currently an undocumented property used only for the focus management ). No editor is sent in the eventInfo object. This is fired quite a lot, for example opening a dialog means that the editor loses focus, so the event is fired, and also when it's closed.

"dialogDefinition"
Fired upon creating the definition for a dialog. The event data are the dialog name and its definition. (this is the only event in CKEDITOR that sends some data in the eventInfo.data field). This event is fired when a dialog is launched for the first time in each CKEditor instance.

So that's all for the main CKEDITOR object. It's a short list, but enough to show a bug in my previous code to provide the seamless integration of textareas in CKEDITOR: Yes the CKEDITOR object doesn't fire any event when an instance is destroyed so that part of the code must be written like this:

// Hook each textarea with its editor
CKEDITOR.on('instanceCreated', function(e) {
 if (e.editor.element.getName()=="textarea")
 {
  var node = e.editor.element.$ ;

  // If the .nativeValue hasn't been set for the textarea try to do it now
  if (typeof(node.nativeValue) == "undefined")
  {
   // IE
   if (!document.__defineGetter__) return;
   // for Opera. Safari will fail
   if (!DefineNativeValue(node)) return;
  }

  node.editor = e.editor;

  // House keeping.
  e.editor.on('destroy', function(e) {
   if (node.editor)
    delete node.editor;
  });
 }
});

This just shows again that you must not trust anyone, test whatever you find and use it as a guideline, but always be ready to think that the person that wrote some example might not have tested under your same conditions, that some code has been changed meanwhile (for example I guess that the list of events of CKEDITOR might have increased in v3.2 for example, so if you read this article 2 years from now just think that I'm talking about the 3.0 version), or the code might be wrong because whoever wrote it was too drunk that day :-)

Hooking textarea.value with CKEditor, part 2

2009-09-06T16:16:00.004+02:00

Edit: this version is now obsolete, go here for the latest version.

Today I wanted to finish some tests and study better the problems that I found while trying to hook textarea.value with the contents of CKEditor.

As I thought the problem with Opera is just related to the use of the HTMLTextAreaElement.prototype, if the code is modified to work on each textarea then it works, so that only leaves out Safari&Chrome users as well as old IEs.

There are two bugs for Webkit, but it's impossible to know about any estimated about when they might get fixed: getter and setter doesn't work on native properties and lookupGetter and lookupSetter doesn't work in native properties.

Opera has several internal bugs tracking several issues with that code, but as Opera 10 has just been released I think that it might take a while to see a new version with the ability to work on the textarea prototype, but fortunately the workaround works for this code.

As I mentioned, there was also a problem in IE if you try to reuse a native property descriptor with another name. I've filed Object.defineProperty can't reuse directly the object returned by getOwnPropertyDescriptor but it can be either marked as invalid or remain there for quite a lot of time as there's no indication about when a new version of IE might be released.

So the new code that works in IE8 + FF3.5 + Op10 is this one: There's also a change to the event handling to fix a problem described in the events post.

// Modify the default methods in CKEDITOR.dom.element to use .nativeValue if it's available
CKEDITOR.dom.element.prototype.getValue = function()
{
    if (typeof(this.$.nativeValue) == "undefined")
        return this.$.value;

    return this.$.nativeValue;
}

CKEDITOR.dom.element.prototype.setValue = function( value )
{
    if (typeof(this.$.nativeValue) == "undefined")
        this.$.value = value;
    else
        this.$.nativeValue = value;

    return this;
}

// Hook each textarea with its editor
CKEDITOR.on('instanceCreated', function(e) {
 if (e.editor.element.getName()=="textarea")
 {
  var node = e.editor.element.$ ;

  // If the .nativeValue hasn't been set for the textarea try to do it now
  if (typeof(node.nativeValue) == "undefined")
  {
   // IE
   if (!document.__defineGetter__) return;
   // for Opera. Safari will fail
   if (!DefineNativeValue(node)) return;
  }

  node.editor = e.editor;

  // House keeping.
  e.editor.on('destroy', function(e) {
   if (node.editor)
    delete node.editor;
  });
 }
});


// This function alters the behavior of the .value property to work with CKEditor
// It also provides a new property .nativeValue that reflects the original .value
// It can be used with HTMLTextAreaElement.prototype for Firefox, but Opera needs to call it on a textarea instance
function DefineNativeValue(node)
{
    var originalGetter = node.__lookupGetter__("value");
    var originalSetter = node.__lookupSetter__("value");
    if (originalGetter && originalSetter)
    {
        node.__defineGetter__("value", function() {
                // if there's an editor, return its value
                if (this.editor) 
                    return this.editor.getData();
                // else return the native value
                return originalGetter.call(this);
                } 
            );
        node.__defineSetter__("value", function(data) { 
                // If there's an editor, set its value
                if (this.editor) this.editor.setData(data); 
                // always set the native value
                originalSetter.call(this, data)
                } 
            );

        node.__defineGetter__("nativeValue", function() {
                return originalGetter.call(this);
                } 
            );
        node.__defineSetter__("nativeValue", function(data) { 
                originalSetter.call(this, data)
                } 
            );
        return true
    }
    return false;
}

// Wrap this in an anonymous function
(function() {
if (Object.defineProperty)
{
    // IE 8  OK
    var originalValuepropDesc = Object.getOwnPropertyDescriptor(HTMLTextAreaElement.prototype, "value");
    Object.defineProperty(HTMLTextAreaElement.prototype, "nativeValue",
            {    
                get: function() { 
                    return originalValuepropDesc.get.call(this);
                },
                set: function(data) { 
                    originalValuepropDesc.set.call(this, data);
                } 
            } 
        );

    Object.defineProperty(HTMLTextAreaElement.prototype, "value",
            {    
                get: function() { 
                    // if there's an editor, return its value
                    if (this.editor) 
                        return this.editor.getData();
                    // else return the native value
                    return originalValuepropDesc.get.call(this);
                },
                set: function(data) { 
                    // If there's an editor, set its value
                    if (this.editor) this.editor.setData(data); 
                    // always set the native value
                    originalValuepropDesc.set.call(this, data);
                } 
            } 
        );
} 
    else if (document.__defineGetter__) 
{
    // FF 3.5 OK
    // Opera 10 fails for HTMLTextAreaElement.prototype, but it will work for each instance
    // Webkit fails: https://bugs.webkit.org/show_bug.cgi?id=12721
    if (!DefineNativeValue(HTMLTextAreaElement.prototype))
    {
        // We try to get the innerHTML getter for the body, if it works then getting the value for each textarea will work
        if (!document.body.__lookupGetter__("innerHTML"))
            alert("Safari and Chrome don't allow to read the originalGetter and Setter for the textarea value");
    }
} 
    else
{
    // detect IE8 in compatibility mode...
    if (document.documentMode)
        alert("The page is running in Compatibility Mode (" + document.documentMode + "). Fix that")
    else
        alert("Your version of IE is too old"); 
}
})();

Edit: this version is now obsolete, go here for the latest version.

Seamless replacement of textareas with CKEditor

2009-09-05T22:17:00.005+02:00

Edit: this version is now obsolete, go here for the latest version.

Everynow and then someone always pops up asking why they don't get the current contents of the editor if the read the value of the textarea. The answer is obvious: FCKeditor/CKEditor is a different object than the textarea so they must work with the editor, not with the textarea, but this might be more subtle when they are using some javascript framework to read all the form elements on form submit. In that situation the editor updates the value of its associated textarea using an event handler, it might run later than the read of the values and so the value that they get is the initial one.

What about making all of that automatic?

First step: textarea.value

In order to make it work we would need to use our own textarea.value property. In Firefox it's possible to do that since long ago, and IE 8 did bring this feature for us.

This would be the code to make it work for IE:

 var originalValuepropDesc = Object.getOwnPropertyDescriptor(HTMLTextAreaElement.prototype, "value");
Object.defineProperty(HTMLTextAreaElement.prototype, "value",
  {   
   get: function() {
    // if there's an editor, return its value
    if (this.editor)
     return this.editor.getData();
    // else return the native value
    return originalValuepropDesc.get.call(this);
   },
   set: function(data) {
    // If there's an editor, set its value
    if (this.editor) this.editor.setData(data);
    // always set the native value
    originalValuepropDesc.set.call(this, data);
   }
  }
 );

With this code we are modifying all the textareas in the page, if they have an .editor property associated, it will call it to read/write the data; if not, it will use the default system.

Believe it or not, that code is for IE, and it uses new ECMAScript accesor properties that so far no other browser has implemented, they have the first implementation and we should hope that the rest of the browsers write their parts when it's tested in Acid 4 or whatever.

For Firefox we can use this code:

    var originalGetter = HTMLTextAreaElement.prototype.__lookupGetter__("value");
    var originalSetter = HTMLTextAreaElement.prototype.__lookupSetter__("value");
        HTMLTextAreaElement.prototype.__defineGetter__("value", function() {
                // if there's an editor, return its value
                if (this.editor)
                    return this.editor.getData();
                // else return the native value
                return originalGetter.call(this);
                }
            );
        HTMLTextAreaElement.prototype.__defineSetter__("value", function(data) {
                // If there's an editor, set its value
                if (this.editor) this.editor.setData(data);
                // always set the native value
                originalSetter.call(this, data)
                }
            );

As you can see the idea is just the same, but the way to make it work is just different. It's a little nicer to use a single object as the property accessor, but it's not a big issue.

But for other browsers this fails. They have implemented the __defineGetter__ syntax, but Webkit (Safari & Chrome) doesn't allow to use getter/setters with native DOM properties, and in my first tests Opera seemed to work (at least partially) but failed with the final code. ~~I'll try to review the Opera problem, I think that it might work to alter the properties of a DOM object, but not on the prototype~~. You should read the follow-up post to get it working in Opera.

So we have the code for IE8 and Firefox that takes care to intercept the usage of any textarea.value, and is just linked to setting a property "editor" on that textarea DOM node. It could have been written in other ways, for example checking in CKEditor.instances for an instance matching the id or name of the textarea, but I just used this way.

Next step: avoid problems

Before writing the rest of the code, we need to think a little: when the form is submitted, or in general, whenever editor.updateElement() is called, it will set the textarea.value, but if we have it hooked to automatically update the editor we are wasting time, and what's worse, any selection and cursor position in the editor will be lost.

So it might be better to do a little modifications: besides altering textarea.value we can create a new property textarea.nativeValue that doesn't try to do anything fancy, it will call the original getter/setter without any relationship to CKEditor and we will be safe.

You might think that for IE you would need just to write a one line:

 Object.defineProperty(HTMLTextAreaElement.prototype, "nativeValue", originalValuepropDesc);

but that won't work, it just raises an error.
And even trying to use

   Object.defineProperty(HTMLTextAreaElement.prototype, "nativeValue", 
         {get:originalValuepropDesc.get, set:originalValuepropDesc.set});

in case that the object did include some special property that didn't allowed it to be reused also fails. So in the end the code is just like the one for the "value" property.

And then we do a little modification to the CKEditor routines so it tries to use that new property if it exist:

CKEDITOR.dom.element.prototype.getValue = function()
{
    if (typeof(this.$.nativeValue) == "undefined")
        return this.$.value;
    return this.$.nativeValue;
}
CKEDITOR.dom.element.prototype.setValue = function( value )
{
    if (typeof(this.$.nativeValue) == "undefined")
        this.$.value = value;
    else
        this.$.nativeValue = value;
    return this;
}

Joining the pieces

So we got every textarea on the page with our new .nativeValue property and CKEditor is modified to use it instead of the original .value; what we need to finish this magic is to set the .editor property on the replaced textareas so they know which editor they must use. And that's easy:

CKEDITOR.on('instanceCreated', function(e) {
    if (e.editor.element.getName()=="textarea")
        e.editor.element.$.editor = e.editor;
});

of course we need to do some cleanup whenever the editor is destroyed:

CKEDITOR.on('destroy', function(e) {
    if (e.editor.element.$.editor)
        delete e.editor.element.$.editor;
});

And that's all that you need.!

Now whenever any javascript tries to read the .value of a textarea that is linked to a CKEditor instance you'll get the current value of CKEditor, and if you write that .value then it will set that to CKEditor at the same time, no need to change anything in the rest of your code!!!

All the code

You just need to put this code in the page after the CKEditor script and the magic is done. Using the automatic replacement described in the first article about CKEditor you can use it without any change to your code, no matter how it does work as long as you restrict your users to Firefox 3.5 or IE8. Edit: look at the follow-up post for the code to include Opera in the supported browsers.

CKEDITOR.dom.element.prototype.getValue = function()
{
    if (typeof(this.$.nativeValue) == "undefined")
        return this.$.value;

    return this.$.nativeValue;
}

CKEDITOR.dom.element.prototype.setValue = function( value )
{
    if (typeof(this.$.nativeValue) == "undefined")
        this.$.value = value;
    else
        this.$.nativeValue = value;

    return this;
}

// Hook each textarea with its editor
CKEDITOR.on('instanceCreated', function(e) {
    if (e.editor.element.getName()=="textarea")
        e.editor.element.$.editor = e.editor;
});

// House keeping.
CKEDITOR.on('destroy', function(e) {
    if (e.editor.element.$.editor)
        delete e.editor.element.$.editor;
});

// Wrap this in an anonymous function
(function() {
if (Object.defineProperty)
{
    // IE 8  OK
    var originalValuepropDesc = Object.getOwnPropertyDescriptor(HTMLTextAreaElement.prototype, "value");
    Object.defineProperty(HTMLTextAreaElement.prototype, "nativeValue",
            {   
                get: function() {
                    return originalValuepropDesc.get.call(this);
                },
                set: function(data) {
                    originalValuepropDesc.set.call(this, data);
                }
            }
        );

    Object.defineProperty(HTMLTextAreaElement.prototype, "value",
            {   
                get: function() {
                    // if there's an editor, return its value
                    if (this.editor)
                        return this.editor.getData();
                    // else return the native value
                    return originalValuepropDesc.get.call(this);
                },
                set: function(data) {
                    // If there's an editor, set its value
                    if (this.editor) this.editor.setData(data);
                    // always set the native value
                    originalValuepropDesc.set.call(this, data);
                }
            }
        );
}
    else if (document.__defineGetter__)
{
     // FF 3.5 OK
     // Opera 10 fails
     // Webkit fails: https://bugs.webkit.org/show_bug.cgi?id=12721
    var originalGetter = HTMLTextAreaElement.prototype.__lookupGetter__("value");
    var originalSetter = HTMLTextAreaElement.prototype.__lookupSetter__("value");
    if (originalGetter && originalSetter)
    {
        HTMLTextAreaElement.prototype.__defineGetter__("value", function() {
                // if there's an editor, return its value
                if (this.editor)
                    return this.editor.getData();
                // else return the native value
                return originalGetter.call(this);
                }
            );
        HTMLTextAreaElement.prototype.__defineSetter__("value", function(data) {
                // If there's an editor, set its value
                if (this.editor) this.editor.setData(data);
                // always set the native value
                originalSetter.call(this, data)
                }
            );

        HTMLTextAreaElement.prototype.__defineGetter__("nativeValue", function() {
                return originalGetter.call(this);
                }
            );
        HTMLTextAreaElement.prototype.__defineSetter__("nativeValue", function(data) {
                originalSetter.call(this, data)
                }
            );
    }
        else
            alert("Opera and Safari doesn't allow to read the originalGetter and Setter for the textarea value");
}
    else
{
    // detect IE8 in compatibility mode...
    if (document.documentMode)
        alert("The page is running in Compatibility Mode (" + document.documentMode + "). Fix that")
    else
        alert("Your version of IE is too old");
}
})();

So, what do you think?

:-)

Edit: this version is now obsolete, go here for the latest version.

Creating CKEditor instances with Javascript

2009-09-04T20:08:00.004+02:00

This should be the final article about creating instances of CKEditor. The first one talked about the simple conversion of textareas and the second one about the new delayed loading feature.

This post will focus on how to create the editor in a more dynamical way (let's call that AJAX).

Replace or Append

One aspect that I didn't mention in the introduction to it, is that the replace function isn't restricted to textareas, as you can see in the examples, you can pass to it a DOM element, or an Id to be used with document.getElementById or a Name that matches a textarea in the page. So the first two options (DOM and Id) allow to use the editor with any kind of element (usually a div), not just textareas. A basic example is the divReplace.html sample (keep in mind that this is just a proof of concept, you will need to code quite a lot more in order to create a CMS with these features). The element being replaced isn't removed from the DOM, it just hidden with style="display:none; visibility:hidden" and the instance is populated with the innerHTML of that element.

Due to the usage of innerHTML and the way that it behaves in different browsers (specially IE) you might find that this isn't too useful, specially if you include any script in the source or any code that is processed at the server.

The appendTo function is the second option to dynamically create instances, and it also accepts as the first parameter a DOM element or an Id, but as the new editor will be created inside that element, it doesn't accept a name, and of course the element that you want to use as the parent must be a valid one (using it on a textarea is wrong and it won't work). An example to use this function is the ajax.html file.

Usually you will use appendTo with a newly created container, so it's empty, but just in case of doubt: appendTo obviously appends the CKEditor element as the last child of the container.

Notes about the creation

Whatever reference element that it's being used, it will be stored in editor.element (editor.element is a wrapper for the native DOM object that can be accessed in editor.element.$). If you are replacing a div or other non-form element, the Save button in the toolbar will be disabled. This should be obvious: its behavior is to update the reference element and then submit that form, if it can't submit the form then it can't save the data. You have two options in these situations: either remove the save button from your toolbar configuration, or create a mini-plugin that does take care to process the data in the way that you need.

The newly created instance will be named after the Id or Name of the replaced element, and if it doesn't have neither of those attributes or it isn't replacing an element, it will use an automatic counter. You can't use the .name property to rename an instance: the property will reflect the new value but it will remain with the old name in CKEDITOR.instances.

Both functions return the CKEditor object that has been created so you can keep working on it, but if you are using the fckeditor_basic.js integration, it might not be full featured until the full core is loaded and then it's really created. You can find this code in the ajax.html example to learn how to deal with this situation:

if ( editor.setData )
    editor.setData( html );
else
    CKEDITOR.on( 'loaded', function()
        {
            editor.setData( html );
        });

End of chapter

So I think that this covers all the current options related to creation of the instances. Of course, you could use directly the ckeditor constructor, but unless you are absolutely sure that you know what you are doing, you should avoid it.

In future releases you will have the option to use different plugins to some popular Javascript frameworks (the one in the works is for jQuery) so you can use CKEditor in a "native" way in that framework.

Delayed loading of CKEditor

2009-09-01T22:09:00.005+02:00

As I mentioned in the post explaining the way to create an CKEditor instance, now instead of including the normal ckeditor.js file, you can use ckeditor_basic.js file, a bootstrap that contains just the core functionality so the rest of the code can be loaded at a later time, avoiding delaying the initial load of the page.

You just need to replace

<head>
 ...
 <script type="text/javascript" src="/ckeditor/ckeditor.js"></script>
</head>

with

<head>
 ...
 <script type="text/javascript" src="/ckeditor/ckeditor_basic.js"></script>
</head>

By default (you could alter the packaged contents to remove/add plugins), ckeditor.js weights 260KiB, but ckeditor_basic.js is only 7KiB, so the advantage is that if you don't need to create an instance of CKEditor right from the start you can save those 260KiB in the initial load (of course you should have http compression enabled on the server, so the download size is smaller, but let's focus on the raw numbers to ease understand it)

When is loaded the rest of ckeditor?

At any time you can call CKEDITOR.loadFullCore() to get the full functionality ready. Before the page is loaded, you can set in CKEDITOR.loadFullCoreTimeout the number of seconds to wait before the core is automatically loaded, the default value is 0, meaning that it won't be loaded automatically.

If you try to create an instance of CKEditor before the Full Core has been loaded, then it will be loaded at that time, so the user will have to wait a little to get the full core and then the editor will be created.

If you are using the automatic replacement of textareas with class ckeditor (or defined with replaceClass), then if no matching textareas are found the core won't be loaded. The same thing happens if you use replaceAll.

How to use this info:

If you know that the page will always use some instance of CKEditor right from the start, then just forget about this, it won't help you, it's an extra http request and 7KiB downloaded that are wasted.

If you expect that the full functionality of CKEditor won't be used most of the time, you can use ckeditor_basic.js and then let code take care of loading the rest only when it's needed.

If you know that you don't need it at page load, but that usually an instance will be created shortly after, you can set some seconds in the CKEDITOR.loadFullCoreTimeout property.

If you are able to know that after some command the user will need CKEditor, you can load the full core at that time (remember that this method destroys itself after it has been called, so you must always use it detecting its presence as it's in the example):

// Check if the full core code has been loaded and load it.
if ( CKEDITOR.loadFullCore )
    CKEDITOR.loadFullCore();

But these are just some guidelines, you should be the one that knows your app, how it's being used, and of course remember that browsers have caches, so those 260KiB aren't so terrifying after you realize that on second load it's a hit in the cache and in fact it might be better from a point of view to use the full core in most situations. On the other hand, you might want to merge the basic code into the rest of the javascript of the page, and then it's just a little increase in the size of that javascript and CKEditor will load itself only when it's needed

Caution with the filenames

The loadFullCore just tries to load the file CKEDITOR.basePath + 'ckeditor.js', so if you want to use this boostrap technique you must leave the name as is, also if you try to embed the file into some system (like Asp.Net the WebResource.axd) then it will also fail, and there is no provision to make it work in those situations.

If you have renamed the ckeditor.js (if you don't use this bootstrap system) or ckeditor_basic.js (or have merged into other file), you might need also to do some adjustments, like setting CKEDITOR_BASEPATH (because the detection of CKEditor.basePath is based on the name "ckeditor"), and some times provide a CKEDITOR_GETURL implementation for the getUrl method. But this is too much for this post, someone that uses it might explain it better.

So if you find that something isn't working, be sure to use the default filenames, and if you can't then remember that you'll need to specify some data by yourself.

Creating an instance of CKEditor

2009-08-30T16:28:00.004+02:00

This is the second post about CKEditor, be sure to read first the prerequisites to use CKEditor.

As explained in the integration guide you must add the CKEditor library to the head of your document. I would like to add a little remark for the moment: instead of ckeditor.js you can use ckeditor_basic.js if you don't need the features before the page is loaded, it will load only a small stub and delay the full load to make the page ready quicker. I explain this feature in detail here.

So go ahead and add it:

<head>
 ...
 <script type="text/javascript" src="/ckeditor/ckeditor.js"></script>
</head>

Now the CKEDITOR object is ready to be used in your page. This is the entry point for all the CKEditor functionality.

The most common situation is to use a textarea for your content and replace it with CKEditor:

<textarea cols="80" id="editor1" name="editor1" rows="10">
&lt;p&gt;This is some &lt;strong&gt;sample text&lt;/strong&gt;. You are using &lt;a href="http://www.fckeditor.net/"&gt;CKEditor&lt;/a&gt;.&lt;/p&gt;
</textarea>
<script type="text/javascript"> 
  CKEDITOR.replace( 'editor1' ); 
</script>

This approach means that if the user is using an old browser that it's not supported by CKEditor, or they have disabled javascript they will get a plain textarea and they can still use your site.

Ok, so far I haven't said anything interesting, but I think that it's better to start step by step, reviewing what's available before explaining new things. So the next step is to look at the CKEDITOR object.

What about automatically converting the textareas to CKEditors without any javascript (besides the library of course)?

You just need to add the class "ckeditor" to you textareas and you're done! Look at the _samples/replacebyclass.html file.

If you want to the magic to work with other class names then you must use the replaceClass property. This is how your page would look if you have already some textareas with the class "html" and you want to use now CKEditor without any further changes:

<head>
 ...
 <script type="text/javascript" src="/ckeditor/ckeditor.js"></script>
</head>
<body>
<script type="text/javascript"> 
  CKEDITOR.replaceClass = 'html'; 
</script>
...

As you can see, with minimal changes to your existing pages you can use CKEditor.

Other times you might want to use CKEditor in all the textareas of your page, no matter what are their classes. Then replaceAll is your friend. As the replace call, you must use it only after your textarea, or if you must add it in the head of the document, use the document "onload" event (be careful: if you assign directly document.onload other script might want to also use it in the same "stupid" way and will erase your listener, or you could erase that other listener)

In fact, the replaceClass and replaceByClassEnabled is just some syntactic sugar to easily use the replaceAll at page load with a className.

The replaceAll method can be called in three ways:

No parameters: All the textareas are replaced
A string parameter: Only the textareas that have their class matching that parameter will be replaced
A function parameter: This is the most powerful option, each textarea will be passed to that function, along an empty config object that can be used to apply custom configuration options to each instance.

So if you want to replace all the textareas in the page, except those that have a class of "text" or whose id is "summary" you should use this code at the end of the page (or on the onload event):

<script type="text/javascript">
 CKEDITOR.replaceAll( function(textarea, config) {
  if (textarea.className=="text") return false;
  if (textarea.id=="summary") return false;

  return true;
 });
</script>

Finally there's the appendTo method, but for the moment I ~~can't figure out why that is interesting, so I won't bother to explain it~~ need to study it better to give my impressions about it.

Using CKEditor, prerequisites.

2009-08-30T15:39:00.004+02:00

This is the first post related to CKEditor, and I'm gonna try through several posts to guide you about how to use CKEditor in your page.

The first step is obviously to "install" CKEditor in your server.
I've quoted install because you just need to extract the zip to the place where you prefer. In the rest of these posts I'll assume that you have placed it in /ckeditor/ like the example in that page.

If you are looking for an ".exe" to install CKEditor, then you are trying to use the wrong tool. You should look at Kompozer to get a HTML authoring program for your computer

So now you can check the _samples folder.
Do it.
Test the samples to verify that they work, read them and check its source code. The samples are there because they can be useful in order to understand how to use the editor. If you ask questions that can be easily answered by looking at those samples people might not bother to reply to you because you are lazy.

Before we get any further I would like to make an important remark: CKEditor is only a javascript widget. It's behavior is like any other HTML form element, so if you are unsure about how to read a file at the server, save the data, manage user permissions or anything like that, then remember that you are placing your questions in the wrong place. CKEditor is not a Content Management like Drupal, DotNetNuke, etc.., it's not a replacement for FrontPage or DreamWeaver. It's just a <textarea> that uses HTML instead of plain text.

If you are not a developer then forget about installing CKEditor as you will need some experience about coding in order to create the rest of the site or modify those files to integrate CKEditor. In those situations you should:

Search for a CMS / Blog / eCommerce system that fits your needs.
Search for a plugin/tutorial that explains how to integrate CKEditor into your system selected in step 1. Google, Yahoo, Bing, whatever... write there "CKEditor" + your CMS and your might find someone that will help you. As CKEditor has just been released as a stable version, it isn't strange that those plugins aren't available, in that situation you can search for FCKeditor + your CMS and check there if that people is interested in creating a plugin for the new version. Making a donation can help!
If you have absolutely no idea about coding, then you will save a lot of time if you pick some hosting that comes preinstalled with some package that you can use, or, hire someone to install it for you.

The 3.0 release doesn't include the server side integration code, it's only javascript so if you don't want to learn some basic js coding, then you should wait a little for the 3.1 release.

So in order to use CKEditor, you should have your site up and running, and use <textarea>s in the place where you will later want to use CKEditor, everything must work, check that you can read and save data that includes quotes, single quotes and that it doesn't becomes distorted due to any server filtering.

For example, use this code as the source for the textarea and verify that it isn't altered although you load/save the content several times:

<p>This is some <strong>sample text</strong>.
You are using <a href="http://www.fckeditor.net/">CKEditor</a>.</p>
<form method="post" name="test"><textarea name="area"></textarea></form>
<p>Final &lt;&gt; quote '</p>

If you are unable to make your system work properly with that code, then you have some problem with your server and trying to use CKEditor won't help you to understand the problem, you'll say that it's due to CKEditor but it's just your code.

Now it's the time to read the second page in the developer docs: Integrate CKEditor in your site. I'll explain the creation options in the next post.

Upload progress for Firefox 3.5

2009-08-29T21:29:00.004+02:00

The new release of CKFinder 1.4 is due mainly to cover the integration with CKEditor 3, but it includes other little details, and I'm gonna talk about one of the here: the upload graph for Firefox 3.5

Firefox 3.5 might look boring for the users, it doesn't bring any special change to the interface or to the general options, but under the hood there are lot of changes for developers. Old bugs fixed, polishing, new features... And among those new features there is something special for us: the ability to read the files picked with an <input type="file"> from javascript. Previously the only option was to read the filename and then submit the form to the server, without any ability to know how long it's taking.

A little history

In order to provide a progress bar you had to use some special coding at the server, so it could provide a progress info and poll that periodically. In some context it's far easier than in others, some require proprietary components, some require just a little script, but it's not easy to get it ready for every environment.

Then the Flash uploaders appeared. Macromedia did add a nice API to flash that allowed to easily pick several files from the user computer (of course, it's the user the one that selects the files) and then upload that data to the server, with event notification so now you can find several (lots?) of libraries to do that. One example is SWFUpload. But as far as I know, all of them have a problem due to the flash plugin itself: in non-IE browsers it fails to send back to the server the proper cookies, so it ruins the ability to keep authentication in the upload process. The trick then it's to send the data for the authentication cookie along the request and then recreate the session at the server with that info, I know that the code to do that in PHP and Asp.Net it's available and you can easily add that, but I've never seen such workarounds working for Asp (I don't know about CF). And even in Asp.Net you might need to alter files (global.asax) that you can't touch "to show a progress bar".

So as you can't see there is no easy solution "that works for everyone", but in the future that can be different.

The present

Starting with Firefox 3.5 you can use a new (non-standarized) API of the XmlHttpRequest: sendAsBinary. This post at hacks.mozilla.org does explain it much better that I would be able to do in a lifetime.

So I went ahead and coded it for CKFinder.

Pros:
- No changes required at the server,
- It's based on feature detection, so if any other browser adds these APIs it will automatically work.
Cons:
- Only Firefox 3.5,
- We don't know how well it will perform with big files (1).

1: The Firefox API is based on reading the full contents of a file as a string and then sending it with a XHR, so if you pick a 1Mb file it means reading 1Mb of data, that looks easy. On the other side, if you are storing a 500Mb movie, then Firefox will go ahead and use in a moment 500Mb of additional memory. Wow, looks scary so we capped the feature so it's only triggered if the file is smaller than 20Mb.

The way that it's coded means that this is transparent to the user, he doesn't have to do anything and it will work. The form is just the same, the only change is the way that the data is sent to the server.

Other options

At the same time I evaluated the ability provided by Webkit that allowed to pass a file object to the XHR.Send() method, but it has some important drawbacks:

It's not possible to do feature detection on the ability, so it would need to be hardcoded using UserAgent strings. That's not nice
The file is sent to the server without any of the POST boundaries to wrap the data. That means that your standard code at the server won't work, you need to write special code to send the file name (easy) and then process the boundless data at the server (not so easy). In Firefox we have to add those boundaries, but the point is: It's possible to add them, so the server doesn't notice any difference between a standard form-post and this xhr.sendAsBinary()

There are lots of talk about this kind of features for inclusion in the new versions of XHR and related APIs, so I think that it's important to start testing what's available and provide feedback about what works and what fails.

I also tested the ability that Opera and Webkit offers to select multiple files with the <input type="file"> widget, and although it worked for Webkit, Opera did send the data using a set of headers that caused Asp.Net to consider it an attack, and crashed the AspUpload ActiveX from Persits (I didn't test it further as it was a dead road).

So in the future the ability to send multiple files with webkit might be added, also we will evaluate further the option to use a flash uploader so IE users get the option to both select multiple files and get a progress status, the important part is that the adjustments at the server side should remain within the CKFinder code, when you start requesting changes to global files then the problems start

Little bugs

Nevertheless, I don't think that the Firefox implementation is bug free.

The first problem is that the progress events are fired only when the server "consumes" the data. I mean: if you look carefully or put a sleep() at the server you will notice that the upload seems to stall at the end, although the data has been sent to the server, the browser doesn't notify that, it waits there, and looks strange.

As I said, reading the full file in memory doesn't look nice, it should be possible to request sending a file and the browser would read it just like it does with a normal form POST, it can read it little by little as it needs and with minimum overhead. In that situation we wouldn't need to restrict the maximum size, and this is important because getting progress info is more interesting when the file grows bigger.

If you notice any problem with this feature, please report it so we can look at it and fix it ASAP.

CKEditor released

2009-08-27T22:08:00.002+02:00

After a long time, finally the first stable version of CKEditor 3.0 has been released.

There are still some important features that are missing in order to do a smooth upgrade fro FCKeditor 2.x, but nonetheless this release is very important to really show what's coming with this new version.

I might add some follow up posts with small snippets of code about how to do some basic things with this version, trying to cover some areas that for the moment are lacking proper documentation.

These are the current articles:

Installing PHP in IIS 6 (windows 2003)

2009-08-08T16:15:00.001+02:00

Some time ago I tried to install PHP in a test machine with Windows 2003 and IIS, so I could do some tests more easily. At that time I failed to get it working. The theory is simple, I found several tutorials explaining how to do it, but I wasn't able to get nothing but a "404 page not found" whenever I requested a .php page in that server.

Today I decided to try again. Quite a lot of things have changed in this time.

PHP has setup a separate site to handle installing PHP in Windows. Unfortunately the site is not as friendly as it seems that they are planning, but at least it's clear that they acknowledge the fact that there's a need for help installing PHP in windows. Besides the downloads it seems that there's little more in that site at the moment, but that download page is a little daunting:

Reading the sidebar you can see that you need to get the VC9 versions to install it in IIS, and the VC6 are meant to be used with the Apache server. But:
Thread safe or Not Thread safe?
Zip, Installer or Debug Pack?

Wouldn't it be better to move that Debug pack to somewhere else?

I'll skip some steps, and I would like you to introduce you this page that explains how to configure FastCGI and PHP in IIS.

You could have done the two first steps like I did, I downloaded the installer for PHP-non threaded-vc9 and when I tried to run it and configure for "IIS FastCGI" it warned to first download and install the FastCGI extension.

But you won't get the explanation about how to configure the FastCGI extension, so keep reading that page. I tried to do the automatic configuration using the script, but I got an error, so I don't know what's wrong. I tried to verify then all the steps according to he manual configuration and it seemed to be OK. But I got again a "404 page not found" trying to load any php page.

The next step was removing all of it and try with this automated installer for PHP in IIS . Yes, now Microsoft is hosting a whole site devoted to support for PHP in IIS, so this looks like a first stop when you try to get it working or troubleshoot something related to IIS and PHP. Wow.

After installing that "Web plataform installer" it took care of the rest by itself, each product was downloaded and installed, and I guess that it might have done that "configure FastCGI" in the bundle.

But again it didn't work!!!

The difference for me was that this time I knew that I was using the correct files, it's a tested installer, so I can't blame it on me due to having picked the wrong file in the PHP downloads (in this case I've noticed that they are using PHP 5.2.10 instead of the latest one PHP 5.3 that I picked).

So I tried to look more carefuly at it and then I noticed that under the "Default web site" properties it doesn't have assigned the .php script mapping. It was done correctly at the "Web sites" (parent folder), but not on the site itself. For some reason that setting didn't propagate to the child nodes, so I "edited" it and pressed OK, and it asked whether to update the value in the child sites. I said YES, and Now PHP Works!!!

As a summary:

The problem that I had was that the setting was correct for the "Web sites" node, but the real website node didn't get that setting applied, I guess that I might have messed previously (as I said this is a test machine) and those automatic scripts didn't try to update it.

SWFObject plugin Update

2009-08-06T22:47:00.001+02:00

Almost two months ago the fine folks at SWFObject did release the 2.2 version, so finally I've modified the FCKeditor plugin to make it use that version by default.

What does it means to you?

-If you don't use my plugin, not too much. Maybe you can take a look at it anyway if you are a FCKeditor user and don't like embeds.

-If you use the plugin, but are using a version of SWFObject hosted in your server, then you don't need to upgrade my plugin. Anyway, you might want to upgrade your copy of SWFObject, and if you place it with a different filename, then the upgrade of my plugin might be useful or you might end up including in the pages a link to the old library and another to the new one. Sorry, I didn't thought about it.

-If you are using the plugin and are relying on the externally hosted library, then it would be good to upgrade the plugin. The caveat is that you need to open and save again any page with a reference to the plugin to get it updated (unless your CMS has some option to do a search&replace in all the content). The good part is that even if you don't touch the existing content, the new files will use the new version.

Enjoy it

Imgmap plugin update

2009-08-02T15:38:00.001+02:00

Adam has been working on the imgmap code, and recently has released a new version to improve compatibility as well as fix some issues.

So finally I've upgraded the demo and the download link. If I ever forget again, just remember that the imgmap project is hosted at Google code.

I'll try to review these days all the mails that I have in the queue.

Even Microsoft knows it

2009-07-22T23:01:00.001+02:00

Just today I was a little surprised to read the System requirements for SharePoint Server 2010.

Two quotes:

To ensure the best possible experience across multiple browsers we’re focusing our SharePoint 2010 engineering efforts on targeting standards based browsers (XHTML 1.0 compliant) including Internet Explorer 7, Internet Explorer 8 and Firefox 3.x. running on Windows Operating Systems. In addition we’re planning on an increased level of compatibility with Firefox 3.x and Safari 3.x on non-Windows Operating Systems. Due to this focus Internet Explorer 6 will not be a supported browser for SharePoint Server 2010.

And

Q: What about Internet Explorer 6 and SharePoint 2010 publishing sites?
A: The Web Content Management features built into SharePoint 2010 will provide a deep level of control over the markup and styling of the reader experience. These features will enable customers to design pages that are compatible with additional browsers for viewing content, including Internet Explorer 6. A standards based browser such as Internet Explorer 7, Internet Explorer 8 or Firefox 3.x will be required to author content.

Yes, you are reading correctly.

Even Microsoft aknowledges that IE6 is a PITA, so you'll need something newer in order to author content there.

Little by little the web is moving forward, as more of these announcements popup everywhere people will finally realize that IE6 is a dead end, and that they must upgrade their browser if they want to use the new tools.

The reasoning should be easy:
Do you want to use the new tools? -> Use a new browser.
Do you want to keep using your old browser? -> You'll have to keep using tools and pages developed some years ago. Good luck with that!

Don't be afraid, IE8 doesn't require to install any WGA validation on your computer, it won't eat your children. Yes, it has bugs, but as the web moves to the future, the new webs are tested with the new browsers, and little by little IE6 fails into oblivion, so you'll see that more and more pages break in your old browser.

Stand up and say No to IE6! ;-)

Google Maps v3

2009-06-01T22:43:00.002+02:00

Just last week Google announced the third version of the Google Maps API.

It's a full rewrite, so for the moment it can't be used to replace the current maps in most of the sites (features like polylines and polygons are missing at the moment), but it can be tested and I might start porting the current plugin for FCKeditor to use the new API.

Why should I care about it if it isn't ready?

One of the first claims that you see is the compatibility with mobile browsers, that's nice. Improved speed is also welcome. Modularization means that less code is loaded and everything will work better, but....

NO KEYS REQUIRED!!!

(Sorry for the caps)

So when the new version of the plugin is released, you'll be able to use it in any site without worrying about getting and storing those stupid keys. If you have a site that it's served under different names it will work without any extra magic. OK, one problem might remain: the static maps do still require the key, but if it isn't available the rest of the functionality should work.

Things might go like this:
A version 2.3 for use in FCKeditor 2.x with the Maps Api 3
A version 3.0 for use in CKeditor 3.x with the Maps Api 3. This one will be easy to remember :-)

Of course, that 3.0 version might take a while, the v3 maps must get back enough of the functionality from the current version so it can be used without problems, and CKEditor v3 must be released and then I have to rewrite all the code so it can work with the new CKEditor API.

As you can imagine, rewriting all the code is not a pleasant task, and due to the work with new versions some unexpected bugs might arise that needs to be fixed at the other side.

Write Area 0.8.0 released

2009-04-14T22:20:00.002+02:00

If you have installed WriteArea then soon you'll get the updated version.

It finally adds tooltips for the toolbar buttons, and two new buttons besides the "save" button.

The first one allows to save the current content to a file in your computer, great if you want to keep drafts of any kind of templates around. The second button is obviously the one to load those files, the icons might not fit exactly with the rest but I'm not a designer and I always rather focus on the most important things.

Now that CKEditor 3 is getting closer everyday I don't know if next update will be based still on the 2.6 line of FCKeditor, or if it will start using that fresh new code. Some of the advantages of the new code doesn't apply the same way inside chrome than it does in a website, but on the other side it might open new opportunities, they might need some time to check and test the ideas so such future update might get delayed quite a while.

There are other ideas for the current code, but they also take time, I wish that there would be a way to code everything that goes through my mind.

(null) requests from IE8

2009-03-20T19:59:00.001+01:00

I've noticed since the release of the IE8 Beta 2 some strange request for non-existing pages: the requests are something like this "http://www.mydomain.com/(null)"

The only thing in common between those request is the user agent, always IE8 using the Trident 4 engine:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)

It might include other toolbars or add-ons, but that's the common part for all of them. Most are using XP, but there is also some Vista requests.

The only page that I've been able to find so far is this thread that is focused just in how to ignore those request, instead of trying to understand the reason why are generated.

I'm afraid that now that the final IE8 has been finally released the number of such bogus "(null)" requests will increase at a very fast pace, so the only solution will be to set a rule to ignore it as just another bug in IE8 and don't get flooded with the 404 error.

The pain of supporting IE6

2009-03-15T13:04:00.003+01:00

In this day and age it's a pain the fact that IE6 is still out there. Every web developer that have spend a little time trying to make a page or script work cross-browser and include IE6 in the set of supported browsers knows it.

I guess that if everything goes right and MS doesn't make any big mistake the release of Windows 7 will be a tremendous help in order to see IE6 go away. We all know that too many companies have been holding on XP due to the bad words about Vista, but for the moment they have managed to get good press for W7, so it won't be strange that not too long after it's released more and more companies that have been delaying the upgrades to their workstations or that have bought new ones but immediately replaced Vista with XP will be more positive to get Windows 7 and that way the included IE8.

Movements like the one started in Norway are a step forward, most of the average user doesn't know anything about internet or a browser, so when they see a similar message in every page that they visit they might get a clue and finally update to IE7 or (if we are really lucky) to any of the other browsers. Of course this isn't the first movement, there are previous ones we just need to send the message out, it doesn't matter where you did read it. The statistics show that following the current trends IE6 should slip to something like 10% usage at the end of this year. And I guess that the release of IE8 will help that number to get even lower.

As stated too many times, the usage between home and office is very different and the message usually only will be able to force the change at homes, but what happens when they go back to the office and their browser there doesn't behave the same way that it does at home?, when they can't use tabs? when the pages look slightly wrong? At some time they will be able to force the change of policies and get the IE7 update and that's good.

But this isn't just about the users and their browsers. If you are a web developer you can help every body: don't create pages in Quirks mode. As soon as you add the correct doctype to your pages you have done the right thing, it will be much easier to create pages that will behave the same way in different browsers and will make some of the IE6 problems go away. Of course it isn't perfect and IE6 must die, but you will be able to forget about it for a little while. You can read about the goodness of Standards mode by a CSS Expert

What does it mean that you use standards mode for anyone else?

As long as you use any third party library, a lot.

If the developers of any javascript library can forget about supporting IE6 and its Quirks mode it means that they have one browser/mode less to test on. Not only that, every other browser also have slight differences in Quirks mode, so it means a lot of time saved just by a little change to your pages. As you see, you don't need to force the change on the users to make the web go forward, just say no to Quirks mode.

If you want to use an updated script for your page, why can't you update your page so it follows the standards?

More voices are starting to cry out "that's enough" and some have suggested setting Dec 31th, 2009 as the end date for IE6 support. I think that's a good movement forward: we can't force people to change their browsers, but we can't waste our time and money supporting such a beast that doesn't allow us to focus in newer features, simpler code,and in general look forward instead of being forced to code the same way that we had to do eight years ago.

I will be glad to hear from everybody that they won't be supporting new developments on IE6+QuirksMode any longer, the sooner the better.

GoogleMaps 1.98

2009-02-15T21:40:00.001+01:00

This release fixes a little problem using the GoogleMaps_PublicKey setting and adds Chinese and Norwegian translation.

Of course, no new work is expected in the 1.x versions.

Releases

2009-02-01T22:15:00.001+01:00

I wanted to post something about several releases of different products, but I didn't have the time until now.

Let's start from oldest to the most recent.

CKFinder 1.3

This release fixes all the problems (at least for asp) known in previous versions, it's the work of several months trying to debug each and every report from the users.

Adding over that, it also includes some enhancements like ability to select the thumbnails themselves and remember the last selected folder.

ImageMap 2.1

I still need some time to update the demo page (and zip) in my server. This is update is just the job of Adam, and the parts related to the FCKeditor plugin are the ability to use Zoom and general bug-fixes and memory leaks. I'll try to really test it asap but I'm a little busy :-(

Internet Explorer 8 RC1

It seems that this release can be really tested, they have fixed lots of bug (included the two that I reported related to FCKeditor), improved performance, and I guess that we all really should test it to avoid finding two months after release that we didn't test it and it did include some regression that makes us suffer again. I don't expect any other releases shortly, just like IE7 I guess that we will have to wait a lot for something new, so this is the time for us to test it and check that it's really getting closer to the rest of the browsers. Let's hope that hopefully IE8 along the release of Windows 7 (I guess that it will be released much sooner than most of the people expects it) makes IE6 fade away.

FCKeditor 2.64

This is one of the last releases of the 2.x series of FCKeditor. It includes lots of bug fixes, I would had included even more little fixes but time is finite and it isn't possible to do everything that one would like to. This release isn't just bug fixes, it also includes support for table headers and a zero-configuration online spellchecker. If you are using any 2.6x version it's a no-brainer to update, your users will be pleased if they ever faced any of the bugs and you shouldn't have any problem to use it.

Let's remember also, that the 3.x versions are called CKEditor and you can start taking a look at it right now with the first beta that has been released, the online demo of the nightlies is available here. Almost everything is being rewritten, it isn't an easy task but the results so far are looking great.

GoogleMaps v2.1 finished (including user docs and bug fixes)

2009-01-24T17:22:00.001+01:00

Finally I've updated the documentation for the end user regarding the new features available in the Google Maps plugin version 2.1, but I've fixed also some little details that did appear after the initial testing period.

All the current customers of the v2 will receive shortly a mail with the new zip.

Some clarifications regarding the plugin:

If you want to use the plugin for free, then you must use the v1 code. It's free to use wherever you want, you can test it in that page and then download it and install it in your server to use with FCKeditor.

If you appreciate the work involved to make that version work, or if you want to use all the new features and want to use the v2 plugin, then you must contact me (until I setup an automatic system), the license for a single site is 15€, if you are any kind of OEM or company that want to use it for several sites, you can get a general license for 50€.

Of course, you should really test the free version before trying to use the v2, as the requirements and setup procedure are just the same. If you have the v1 working, to upgrade to the v2 you just need to replace the plugin folder and that's all, no extra job. There's no online demo or download trial of the v2 plugin, this is all javascript, so it's not worth for me trying to implement any kind of security to avoid the people that want to get everything for free.

Text markers and static maps with GoogleMaps plugin

2009-01-06T22:42:00.001+01:00

I've finished the coding of the new 2.1 version of the GoogleMaps plugin, the main highlights for this new version are:

Text markers.

You can add your text on the map, aimed at providing an always visible caption for the details that you want to remark.

The title field of normal markers now it's shown as a text besides the marker, and you can add any other text in the map using the Text tool.

This feature is based on the ELabels script provided by Mike Williams, I have simplify it a little to remove unwanted features and decrease its size.

Static images generation.

Ok, the previous version did generate a static image and then loaded the map, but this version does provide an option to not generate any script at all, and most important: it's able to edit again those images.

In the previous versions you were able to copy the image around or manually remove the script from source code, but if you tried to edit it again, it didn't recognize any of its data, so it wasn't very useful. Now it can generate the image without any scripts and then recover all the data that it's used on that image (I mean: data as text labels, areas, kml overlays... won't be recovered because they aren't used in the static maps).

This can be useful if you want to provide the option in a kind of forum where anybody can create data, but you don't want them to use any script due to obvious security reasons.

The scripts now are precompressed using YUICompressor in order to improve loading time, if you want to use the original files in order to make any adjustment or debug anything you just have to rename the files.

Now I need to update the docs and then it will be send to the current users. If you want the script and until I set up an automated system you can mail me at amla70 at gmail dot com and I'll provide you the PayPal info.

Optimizing the generation of gifs in .Net

2009-01-01T21:28:00.004+01:00

While debugging some problems that a client had with CKFinder I found out that the thumbnails that were generated using the asp.net code of gif files were in reality png files, just a little oversight and should be easy to fix. Previously the code did test only for jpg files in order to adjust the quality, and the rest of extensions did were saved with

oResampled.Save( targetFile );

But as I said, the .Net framework doesn't check the extension of the file that you want to generate, instead it uses the png format.

So the new code just needed to do a switch:

switch ( extension ) { case ".gif": oResampled.Save( targetFile, System.Drawing.Imaging.ImageFormat.Gif ); break ; case ".png": oResampled.Save( targetFile, System.Drawing.Imaging.ImageFormat.Png ); break ; case ".bmp": oResampled.Save( targetFile, System.Drawing.Imaging.ImageFormat.Bmp ); break ; }easy fix, isn't it?

You're wrong, for some strange design decision at MS, decreasing the palette from full color to 256 colors uses the infamous "web safe" palette, so your page will look again like those done at the start of the times, back when Nestcape was synonymous to Internet.

Why has the .Net team gone that way at this time and age?. I don't care, I didn't want to know why it's done that way, I just wanted to know how to do it the right way, how to specify a proper palette for the new file.

So searching a little you can find this very interesting article at MSDN that explains everything that you want to know about gifs and colors, it has links to other resources that try to explain the miracle that is a web safe palette, but it has been years since I saw a system that wasn't able to work with 24 bit-images.

That article does even include a sample that shows exactly how to do the quantization of images and provides also an implementation of an Octree palette generator. Too good to be true :-)

So there we go, add the class and quickly I see that there are some strange attributes on the classes. "unsafe", uh?

Let's recap: the article was written for the .Net Framework 1.1, and nowadays the servers in hosted providers are using mostly (AFAIK) Asp.net 2.0 in medium trust, so that code won't work at all.

Fortunately there was another nice blog by Brendan Tompkins that did found this same problem and does provide an explanation of the required changes in order to run properly. So I tested and now I didn't get the same compilation problems that I had with the original code, the unsafeness seemed to have gone away.

But when I tested really with medium trust, oh no!, a System.Security.SecurityException! Did I make something wrong?

I reviewed the changes and used directly the modified classes, nops, no way, it fails. Reading the comments I found that other people also reported the same problem but no one answered them. Could it be that initially the code did work in .Net 2.0 but some patch later the behavior was changed and now the calls to Marshal aren't allowed?

Searching to find the solution to this problem hasn't been successful, no one seems to know a solution and I spent one or two days reading everything that seemed interesting trying different combinations of search terms. Even trying to find another method to do the quantization hasn't been fruitful, there are questions posted in different places but no one has provided a positive answer.

Obviously I don't need to read the raw memory of the picture, using GetPixel seems that should be enough to create the palette, but this isn't the final solution because to generate the new picture with the specially created palette I need to specify the color/index of each pixel, and when you try to use SetPixel, you get:

"SetPixel is not supported for images with indexed pixel formats"

And again the solutions to this problem suggest to use the LockBits and then writing directly to memory, but that will fail in Medium Trust.

To recap:

If you're running in High Trust, CKFinder 1.3 the asp.net or asp version (with asp.net handling) will create gif thumbnails correctly
If you're in Medium Trust the call to create the 256-colors image will fail, and so far we haven't been able to find any solution. The GetPixel method is useful only for half of the process, it does still require direct memory access to create the new image so it hasn't been implemented. In this situation the "gif" image is really a 24-bit color png, not optimal and if someday the browsers stop sniffing the content of images they won't be shown, but hopefully before we reach that day MS would have released .Net v8 with some api to control the color-reduction method and/or SetPixel method expanded to handle indexed images.

Fixing bugs for Write Area

2008-12-29T23:28:00.001+01:00

Finally I've started fixing the most annoying bug in Write Area, the lack of tooltips, and thanks to this post by Zoolcar9 I've been able to fix the problem by using a xul file that embeds the html page instead of showing it directly.

It has lead to other code changes so now I have to review that everything keeps working.

Meanwhile I've added a save/load pair of buttons, so you can save your drafts on your computer. I've to review here that the encoding of the files is done properly as the docs state that it isn't utf safe by default.

For the moment it's saving just the content of the <body>, but I guess that I'll create some full html files just in case anyone wants to doubleclick them.

(for the new icons I've picked the load/save file in the Crystal pack by Emeraldo, but if anyone else has a good suggestion just drop a note here)

Write Area 0.7.5 available as experimental download

2008-12-27T19:29:00.001+01:00

I've uploaded the xpi with the new version of Write Area. Until it's approved you need to go to the "all versions" page in order to see it, by default the AMO it's showing only the 0.7 version even if it's incompatible with the 3.1 betas due to the previoulsy mentioned bug 469203.

At the same time I upgraded the FCKeditor core, so now it includes all the new features and fixes since the 2.6.1 SVN that I grabbed months ago. That means this list for the officially released versions and this list for the current changes in SVN since 2.6.3

I'll leave a few days and if no one reports any special problem I'll request the approval to make it the official version.

The magic line

2008-12-20T00:19:00.001+01:00

Thanks to Robert O'Callahan for providing an easy workaround, now I can start testing WriteArea in Firefox 3.1. All that was needed was a background-color:#FFF for the <html> and now it's working again :-)

Of course, using FCKeditor 2.6.1 is boring, so I've updated to the current SVN, and now some of the modifications aren't even needed anymore because the problem has been fixed directly in the FCKeditor main line. Anyway, working with SVN makes very easy the upgrade process and I had a script ready so it takes care of the packaging and removal of unnecessary files in order to re-package it as an extension for Firefox.

So very soon a new version will be ready, just some testing that nothing is too broken and I'll release it.

PD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre

The GoogleMaps 2 plugin is finally ready

2008-11-30T17:51:00.001+01:00

It has taken quite longer than I expected in order to get the new functionality ready, but there was lot of internal changes, some small ones, other big ones that required testing, adjusting, fixing bugs, then a new idea to add a little detail and all the testing was needed again.

I have already explained the main ideas behind the new version: removing some limitations, and giving more power to the user. Of course there are lots of other things that can be done with the Google Maps API, but it would requiere someone a lot of dedicated time in order to put everything in a single interface, and also make it usable by plain users (the ones that ask "the installer now says 'Next', should I press it?)

Unfortunately as this is just javascript and this version is not open source I can't provide a demo so you can test it because then it would be trivial to copy it. I don't think it's worth my time to write/use any kind of obfuscation so you'll have to judge based on the 1.97 demo and checking the new manual. (an advice to any 'smart guy': don't bother trying to guess filenames, there's no zip uploaded and if I upload the data, it will be available only under a password protection), only the install guide is available.

One month later...

2008-11-26T23:00:00.001+01:00

It's funny how sometimes the events can make it look like something is pulling the strings, but it happens that version 1.3 of the SwfObject plugin was released on 26th of September. Just one month later I released the 1.4 version that made it possible to use it with any site offering the typical <object> or <embed> code.

And now, exactly one month later another version is ready.

This one is even easier to install, now you only have to install this plugin and add the line to load it in your fckconfig.js file. The swfobject libreary will be loaded by default from the Google hosted servers. You can read about it in the SwfObject wiki: http://code.google.com/p/swfobject/wiki/hosted_library

Of course, you can keep on using your own hosted version, nothing has changed about that.

The other changes are related to people trying to paste videos. Well it turns out that even easy is not enough for some of them, and instead of trying to paste the code marked as "copy this video to embed this video" they want to paste the url of the page.

Ok, no problem, now some of those servers are automatically detected (YouTube, GoogleVideo, MetaCafe and the new MTV music). It's very easy to add new urls, but I don't wanna waste the time with it, there are too many sites around, and that people should learn to copy the correct code ;-)

Lastly a CDATA wrapper has been added to make those ones using XHTML pass validation.

The demo and download page are still the same: http://martinezdelizarrondo.com/swfobject/

SWFObject, even easier to use

2008-10-26T12:42:00.001+01:00

The new 1.4 release of the SWFObject plugin for FCKeditor does add automatic detection of typical flash embedding code:

<object width="425" height="344"> <param name="movie" value="http://www.youtube.com/v/nj2hewPBQh0&hl=es&fs=1"></param> <param name="allowFullScreen" value="true"></param> <embed src="http://www.youtube.com/v/nj2hewPBQh0&hl=es&fs=1" type="application/x-shockwave-flash" allowfullscreen="true" width="425" height="344"></embed> </object>

So pasting that line in the Url field of the flash dialog will parse it and the movie will be properly embeded in your page.

It also adds two configuration options to specify the minimum flash version for your movies and the path to the Express Install movie if you want to use it. Check the documentation of the SWFObject project to use those features.

What's new for GoogleMaps v2

2008-10-09T21:42:00.002+02:00

Some people might want to hear about this.

Lately I've been working on the new version of the Google Maps plugin, there are several parts that I've wanted to improve for a long time, and finally I've decided that it's the time to start coding it.

New loading system.

The maps won't stop the rest of the page, the google js files are loaded only after the rest of the page has been loaded or it can be delayed until the user really wants to use the map.

Static preview

While the full map isn't ready a static preview will be shown. This means also that the map will be visible for thos with javascript disabled.

Colors.

Yes, different markers should have different colors. Ditto for the lines or areas. Also width, opacity...

Areas

Ups, did I said that?, yes, multiple lines and multiple areas. Note: the static preview doesn't show the areas, it's a limitation of the static API.

Html comments

Embedding an instance of FCKeditor in a dialog used inside FCKeditor? are you crazy? maybe, but it works.

Selection of features.

Select the controls that you want to show: zoom standard/small, area overview, scrolling...

Loading KML files

That way you can import external data or create a complex map in Google Earth and display it online.

Over 60% of that is already coded, at least the most complex features, so I am optimistic that it will be ready "soon", but testing and then writing the new documentation might be a stop point, it's boring and sucks, mostly because the people doesn't read it and ask basic questions over and over again.

I guess that it sound very good, maybe too good to be true, but there is one caveat: Surely it won't be free. It will be cheap, but it will require buying a license as coding all of that means a lot of work, and you might have heard that there is some economic crisis around there. The current version will be available for free and you can use it, but if you want the advanced features you'll need to spend a little money on it.

EasyUpload update and integration for Rails

2008-10-01T18:35:00.001+02:00

You can find in the demo the download for the latest version of EasyUpload.

Meanwhile, Gastón Ramos has created a plugin for Ruby on Rails that integrates FCKeditor and the EasyUpload plugin (previous version)

Updated swfobject plugin

2008-09-26T18:35:00.001+02:00

IE, what to say about it. The browser you love to hate.

If you want the SWFObject to run in it you'll need to get the updated plugin, hopefully there are no more bad surprises hidden there.

Goodbye embed, Hello SWFObject

2008-09-21T12:32:00.001+02:00

When I first released the GoogleMaps plugin, I did mention that it included some code that could make "easy" the task to integrate things like SWFObject in FCKeditor, and it was just a matter of someone willing to code it or sponsor such development.

Recently I've been asked to carry that task for InControl Solutions, I've included also some extra code to allow editing of Flashvars and everything is available in the demo for the new swfobject plugin for FCKeditor.

What could be improved?

The ability to edit the alternative content
Using the static publishing method
Development of additional plugins for specific Flash usage based on this one (I mean, reusing most of the code)

But for the moment I don't have plans to do any of those tasks, so just check that it works for you and use it.

Maps plugin with a nice preview

2008-09-20T23:39:00.001+02:00

As I mentioned in my last entry, the recent update to the Google Maps static API menas that finally it was time to release the new version. As you can see in the version log the feature to use a preview inside the editor was added some months ago, but it only worked for hybrid maps, it was slightly confusing, so in order to avoid wasting the time replying over and over again (yes, there is people that doesn't read the docs and even ask how to install this plugin) I decided to not release it except for the people that had cooperated in its development.

There's still a difference between the final map and the preview: the static api doesn't allow to use encoded (compressed) paths, so until they fix this issue the path won't be shown. Yes, I could get the points and generate the path, but I think that it's more work that it is worth, after all this is just a preview inside the editor

Check it in the demo and upgrade your version, it's a drop in replacement.

The static GoogleMaps now allow to use all the map types

2008-09-11T15:44:00.001+02:00

We have been waiting for it since it was launched, and now finally they have allowed to use all the map types with the static API.

I guess that means that I finally should release a new version of the GoogleMaps plugin :-)

Not a review of IE8beta2

2008-08-29T22:54:00.001+02:00

Everybody will offer you a review of the new beta 2 of Internet Explorer, so I won't bother to do it as you won't read it ;-)

Instead I'll just point out that in a 5 minutes test drive I was able to make it crash constantly, so I've created a simplified testcase and filed a bug in the MS Connect.

I'm not sure about what to expect here from MS. On one hand every crasher should be taken seriously, the tab crash restoration system is very good, but anyway it's a really unexpected situation that should be handled better. I don't think that they have announced the plans for the next version, would it be a Beta3 or RC1 ?

Releasing another beta makes sense because although there have been lots of improvements in this version, it still have lots of thing to polish, opacity isn't supported, dynamic VML doesn't work, there are a bunch of crash reports. I'm not sure that many developers are going to adjust their sites at the moment in this state of things, so it won't be tested properly and there might be still some other issues that are not gonna be known. A RC should be something that can safely be renamed as the final version because all the work that it's planned has been done and there are no big issues pending, and I'm a little sceptical that they can manage to fix all the big issues without another public beta in order to test that they have been fixed and nothing new has been introduced.

For example, the editing part wasn't ready for Beta1, this new version works quite better in FCKeditor, but even using the latest nightly if you try to insert a table it's done at the start of the content, (I guess that it will fail also with other elements, but I haven't done too much research about it), and the fact is that many times the errors can't be discovered just in one session. Some parts are clear and can be tested very easily, but other times it's the interaction between some elements the one that can trigger the problem.

Another example is the wrong dimensions for the content of the dialogs, seems related to the overflow:hidden in the body of the content, but why does it affect it that way, and sometimes it's displayed properly and then it goes wrong?

Trying to apply patches in FCKeditor for a beta that might change in drastic ways for the next release doesn't make sense, what we need are nightly builds of IE8 and more detailed info about the problems that they are working on. Yes, mark as invalid any ticket in Connect regarding new features, just give as a IE8 that does work at least as well as IE7 and that aims to be as good as the rest of the browsers.

Write Area: It's Alive

2008-08-16T23:51:00.001+02:00

Finally, after waiting for almost three months since the release of version 0.7 , the extension has been approved in AMO and you can install it in Firefox without the need to be registered!!!.

Wow, I didn't thought that it would take that long since I created the first prototype at the end of 2007. The code itself didn't take too long, there were only a few problems due to the restrictions of being in chrome and a few differences (one problem that still remains is the fact that no tooltip is shown in the toolbar icons, I still haven't tried to find out if it's just a bug or there is some workaround that doesn't means rewritting the toolbar with XUL.

One interesting fact about running inside chrome (besides the fact that the clipboard buttons work without the need of any other special setting) is that images from the clipboard can be pasted inside the content.

Yes, that means that if you have a document with some images inside and try to paste it inside Write Area, those images will be shown while you are editing (trying to do it in any other site won't show anything because it's using a path to your computer). But when you press the save button the images will remain in your Hard Disk, and they won't be shown in the final web.

But let's think about it: Write Area is running as an extension, it has the ability to read local files, so that means that when the Save button is pushed, I can check if there's any image in the content that it's pointing to the local disk, and send it to a web server, get the proper path to use that image and replace the original reference with this one.

Interesting...

It needs a little coding and a way to know where to send the pasted files.

Wouldn't it be really nice? You just write your content, prepare any screenshot and paste directly there, and when you press Save everything is uploaded (or maybe even after pasting, the file is automatically uploaded while you keep on writing)

Ok, let's not digress any longer and install Write Area right now!