[Update] CKEditor4CMSimple_XH 2.1

[Holger]

Hello Community,

I've just released a new Version of CKEditor for CMSimple_XH which is compatible with the new XH 1.6 beta and contains the latest stable of CKEditor.

Changelog:

Version 2.1

Installation hints:
Skins have changed - check your configuration and clear cache

Changes:
- CKEditor 4.2.1
- Dropped compatibility support for Internet Explorer 7 and Firefox 3.6
- Compatible with CMSimpl_XH 1.6
- Skin "MoonoBlue" added, "Kama" removed
- Added "Insert <pre>" plugin in "full" toolbar
- Fixed a bug in IE where the browse server buttton
triggers a "Content has changed" alert
(thanks to Christoph (cmb), http://www.3-magi.net and Stefan Job)
This bug is fixed for IE9 in the shipped ckeditor-core too

Download: http://cmsimple.holgerirmler.de/en/?Plugins:CKEditor

KR
Holger

[cmb]

Hello Holger,

I've noticed an issue regarding the dropdowns for styles, format etc. on Google Chrome (30.0.1599.69 m). Steps to reproduce:

1. Switch to edit mode
2. Click inside the edit area (e.g. inside a paragraph)
3. Click the format dropdown box
4. Click the font dropdown box

Expected result: the font dropdown box opens and keeps open to allow to select a font.
Actual result: the font dropdown box opens and immediately closes again.

It's the same with other combinations of dropdowns. It seems that the editor forgets the current cursor position. Actually that's a minor issue, as the user can set the cursor position again, but it might be somewhat annoying.

I just found out that this happens only when the "autogrow" plugin is active.

Christoph

[Holger]

Hi Christoph,

I've noticed an issue regarding the dropdowns for styles, format etc. on Google Chrome (30.0.1599.69 m).

I can confirm it. Seems to be an issue with Chrome and the autogrow-plugin.
I've not seen that on FF for example.

If you search ckeditors bugtracker you'll find a lot of problems regarding the autogrow-plugin with chrome. But they're years old and should be fixed already .
Maybe I should make the autogrow-plugin as configurable feature (we've talked about that in another thread).
It seems to be a nice feature but when you use it the first time it's a bit confusing IMO. And, to be honest, I don't like the jumping editorarea when you focus the editor after pageload.
But OTOH having a editarea without vertical scrollbar is really useful IMO.

I think I spend this feature a new config-option in the next release.

Holger

[svasti]

Hi Holger,

some feature requests:

The German field for the "format" drop down is too small. Was too small also in former versions, I changed it, don't remember exactly where I did it, somewhere hidden in the skin. (Bei mini1 ist die Zahl hinter dem Wort "Überschrift" nicht mehr zu sehen.)

The other suggestion would be to rearrange and partially rename the format dynamically, so that the new page producing headers (e.g. h1-h3) are separate from the normal headers (e.g.h4-h6).
The page producing headers could be renamed somewhat like "level #1 pageheader" etc.

svasti

[Holger]

Hi Svasti,

The German field for the "format" drop down is too small. Was too small also in former versions, I changed it, don't remember exactly where I did it, somewhere hidden in the skin. (Bei mini1 ist die Zahl hinter dem Wort "Überschrift" nicht mehr zu sehen.)

The easiest way to fix that is to increase the width of the class .cke_combopanel

Code: Select all

.cke_combopanel {
    height: 170px;
    width: 180px;
}

But that must be done in the compressed css-file of every skin. I'm searching for a way to make that "update-proof". Any ideas? (beside my "poor man" BUILD.PHP-Skript )

The other suggestion would be to rearrange and partially rename the format dynamically, so that the new page producing headers (e.g. h1-h3) are separate from the normal headers (e.g.h4-h6).
The page producing headers could be renamed somewhat like "level #1 pageheader" etc.

There had been some discussions about that in the past and I'm not sure how to handle this. On some installations I've removed <h1> to <h3> complete from the editor and told the user to create pages with the pagemanager.
It might be a good idea to handle this by a configuration - option. But I won't propose just to move the page producing headers to the end of the option-list. IMO they should not appear in the list at all - if the user does not understand the special meaning. And I would welcome that this is handled the same way with all editors.

Holger

[Tata]

On some installations I've removed <h1> to <h3> complete from the editor and told the user to create pages with the pagemanager.

As the end user, I liked very much the oEdit feature (on t he very beginning of CMSimple v. 2.4), where the headers were immediately accessible as H1-H3 buttons (I added also H4-H6 with different design there). So here would be also IMHO reasonable to extract these attributes from the drop down list and add them higher accessibility. All other standard selectors (maybe even compliant to HTML5 - DIV, P, SPAN, ACR, FIGURE, FIGURECAPTION etc. :http://www.w3schools.com/html/html5_new_elements.asp) might be thought about.

[svasti]

I moved the subject of the paragraph format list to an new thread, because:

And I would welcome that this is handled the same way with all editors.

svasti

[cmb]

The easiest way to fix that is to increase the width of the class .cke_combopanel
[...]
But that must be done in the compressed css-file of every skin. I'm searching for a way to make that "update-proof". Any ideas?

If there is any common stylesheet or a config option, the definition could be inserted there (adding !important for the rules, if necessary). However, IMO this issue should be solved by the CKEditor developers somehow.

[svasti]

Hi Holger,

I have one request for the coming verions of ckeditor4XH.

I am building a website for somebody and using CKeditor and find it a bit irritating that the height of the editing box is jumping around. At first it takes the $cf['editor']['height'] value, but as the focus is in the edition box, the height resizes to beome so small that only the actual text is seen. It is nice that the height increases when a lot of text is entered, but I would prefer that it never gets smaller than the $cf['editor']['height'] value, so that jumping is minimized to cases when a lot of text is on a page.

svasti

[Holger]

Hi svasti,

I don't like that "jumping editor" too and I think I've overseen a configuration option in that release.
For the next version I've already made some changes to that feature.

In the meantime you could try to add

Code: Select all

autoGrow_onStartup : true,

to your init_*.js, just below the line

Code: Select all

height : '%EDITOR_HEIGHT%',

.

That won't give you under all circumstances a editor area with a minimum size of the configured height, but it minimizes the "jumping" a lot.

All other solutions require hacking the CK- or the AutoGrow-Plugin code, which seems to be not really an option.


Holger