In accordance with the answer from Zuul, the problem occurs when removing the iframe
of the GIFT. For this reason, my suggestion is to destroy the editor before ordering (making it a simple textarea
) and recreate it after the same.
Firstly, the option is used clone
so that the element being dragged is not itself div
, but a clone of it (this prevents the element from being removed from the DOM when starting the sorting, but only hidden):
$("#e").sortable({
helper:"clone",
Thus, the helper it will still look like the editor being moved - only empty. The original element will still be in the DOM, intact but invisible.
Like the helper is an exact copy of the element to be moved, it also has a iframe
. One can popular this iframe
with a copy of the editor’s own data, so it looks more like the original element. The code below is just an example, it is probably possible to improve more (the appearance is very similar, except for some details in fomatação):
start:function(event, ui) {
// Encontra o id do textarea original (melhor usar classes...)
while ( event.originalEvent )
event = event.originalEvent;
var id = $(event.target).closest("#e1, #e2").find("textarea")[0].id;
// Acha os dados do editor e os copia pro helper
var copia = CKEDITOR.instances[id].getData();
ui.helper.find("iframe").contents().find("body").html(copia);
Then the editor is destroyed at the beginning of the sorting process. As it is hidden, no visual changes are perceived:
CKEDITOR.instances[id].destroy(false);
},
Finally, when releasing, the editor is recreated:
stop:function(event) {
while ( event.originalEvent )
event = event.originalEvent;
var id = $(event.target).closest("#e1, #e2").find("textarea")[0].id;
CKEDITOR.replace(id);
}
});
Example in jsFiddle. One problem with this method is that after destroying and recreating the editor all revision history is lost (i.e. undo and redo), as well as any "state" that the editor kept before the destruction. Unfortunately I have nothing to suggest in this sense...
Another small inconvenience is the helper, that ideally should be an identical copy of the content being moved. I don’t think it’s simple to do this with the editor you use iframe
(iframe
s are a bit "boring" to work with due to security issues), but it may be possible to improve the cloning method.
Warning: It should be noted that using the sortable
this way is subject to a UX problem: if you click on the blue/red area and drag, everything ok, but if you click for example on one of the buttons of the editor and accidentally move the mouse, it starts an ordering (which can be kind of annoying for the user).
One way to avoid this would be to use a handle
to restrict in which part(s) of the div
can drag the element - instead of the div
entire. Example. Or maybe you get something by intercepting the click on capture phase and preventing the drag start when it occurs within the iframe
(I don’t know how to do this using the sortable
, there is no "beforeStart" method or anything like that...).
This already gives me a very good direction in solving the problem. Your example still has a bug, when I change places other times the Ckeditor ends up getting lost. I will try to investigate it here. If you have any idea what might be going on please update here!
– Joao Paulo
Hmmm... With Firefox running on Linux I can run Ckeditor up and down multiple times without losing content... In due course I will further analyze this problem and update the answer!
– Zuul
@Joaopaulo Most likely the problem happens when you click on something inside the editor itself and drag. See at the end of my answer for an explanation and possible solution. By the way, my suggestion is quite similar to this, it just changes the way you do it. And in both cases, moving the element loses the edit history (undo and redo). Maybe more things get lost too, I don’t know... If the solution B of this answer works (i.e. without having to destroy and recreate the editor), it should be the best option.
– mgibsonbr