[2.0] New WYSIWYG editor

Mark threads with "[2.0]" for discussions about features in the longer-term future, "[1.6]" is for short-term. This is not the place for general discussions or plugin or template requests. Only features that are approved to happen by the core team should be listed here for better structuring.
User avatar
garvinhicking
Core Developer
Posts: 30014
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: [2.0] New WYSIWYG editor

Post by garvinhicking » Wed Jun 26, 2013 11:24 am

Hi!

First of all, many thanks to Ian for laying the groundwork to see how CKEditor can be put to s9y's use.

Thanks to onli who beyond a doubt pointed out to me that s9y's BSD license can actually include CKEditor and for stepping forward to using the latest and greatest ckeditor in the core. I myself have not yet been able to check it out, but I am sure this will make greate progress.

Ian, do you have any remarks about the integration? Some things that use advanced features of CKEditor could still benefit from a specific plugin, mostly the updating of CKEditor within a plugin and maybe using alternate media libraries or whatever. Or maybe some things that can now be better done in the core, if it already includes ckeditor?

Best regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
yellowled
Regular
Posts: 6988
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: [2.0] New WYSIWYG editor

Post by yellowled » Wed Jun 26, 2013 1:32 pm

It's awesome to have a nice WYSIWYG editor in the core (which also hopefully will be less prone to security issues than Xinha), so thanks to everyone involved in making this happen. (If you've ever seen the new backend with Xinha compared to CKE from a designer's POV, you'll know why I'm weeping a little here.) I also just saw that the 2.0 core version now actually has s9y media db integration, which is awesome++.

We should use the chance to preconfigure CKE properly, e.g. remove functions which don't make sense. As of now, I would remove the “style” dropdown and the “strikethough” button. The first one generated inline styles (Eow!), the second does not emit the proper HTML markup.

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
onli
Regular
Posts: 2190
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] New WYSIWYG editor

Post by onli » Wed Jun 26, 2013 1:39 pm

yellowled wrote:As of now, I would remove the “style” dropdown and the “strikethough” button.
That's not really my interest anymore, i just made a few changes to the order as a suggestion. The code for that is definied in templates/2k11/admin/wysiwyg_init.tpl, pure js. Feel free to change that to your liking after this discussion, and give me a hint if my help is needed.

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] New WYSIWYG editor

Post by Timbalu » Wed Mar 12, 2014 12:24 pm

Issue #72 (https://github.com/s9y/Serendipity/issues/72)

Bundled CK editor in 2.0 is still 4.1.2. Current version in CKE Plugin – as of writing – is 4.3.3.

I would like to start working on this.

I assume the core shipped WYSIWYG-Editor should not be a (core) plugin, to get enabled the same way, and has to stick to the /htmlarea directory.

There are some questions to solve before:
  • Can I purge the Xinha and previous htmlarea(js) occurences to replace CKEDITOR fully into /htmlarea directory without any other old Editors?
  • If any (Garvin?) objects this isn't possible because of compatibility, would it be a solution to port the XINHA core part into a (additional) plugin and then cleanup /htmlarea for the use of CKEDITOR singulary? If so, I would also need to know, why we should keep the old in there, without actually giving access to it? ;-)
  • We would need to agree which CKE plugins we add to it. (This is an urgent need for switching modes in combo with the ML, for example). I have some experiences on this by the plugin development.
  • There is an issue left with the core CKEDITOR and the S9y tpl js, which is a Milestone beta for me. (I changed the MS therefore) It still does not recognize staticpage nuggets, since they are build independently (see my note to https://github.com/s9y/Serendipity/issues/92). With my CKE Plugin this is not a problem, since I wrote a general function for all textareas. If we all can concur having that in the core CKE, I will implement it.
  • Another (minor) issue - worth some words - is an agreement about using or purging the standard 2-line button groupment. Currently it is set to a 1-liner, to keep the responsive backend mode easy.
    Though I understand the reason, I don't like that and would like to support the 2-line standard by option, like the plugin does.
    But this would need to have the current backend sidebar/content ratio to be slightly wider (*) for staticpages, to keep the 2-liner appear nicely on desktops. Else it is useless work to change the current 1-liner.
I would like to have an answer for point 1 to 4 at least. Thank you.

(*) In mean, reduce margin left from sidebar, between sidebar and content and right from content a little bit. Just as an example hint, set max-width to 84em in @media only screen and (min-width: 1024px) { #top > div, main { } } would do.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
yellowled
Regular
Posts: 6988
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: [2.0] New WYSIWYG editor

Post by yellowled » Wed Mar 12, 2014 1:00 pm

Timbalu wrote:Currently it is set to a 1-liner, to keep the responsive backend mode easy.
“easy” sounds as if it would make writing CSS easier. That's not the case. The 2-liner is simply wasting screen real estate on smaller screens. I still think the best solution would be to just add an option so users can decide between 1-line and 2-line mode, if that's possible.
Timbalu wrote:Though I understand the reason, I don't like that
“I don't like that” is your personal preference. I'm sorry, but while you surely are entitled to that, it's just not a good argument.

I still don't quite see the advantage the 2-liner offers, but we've discussed this before to some extent. I don't see you being even willing to consider the 1-liner, so all I am asking for (for the sake of our users, not for me; I don't even use a wysiwyg editor) is an option to switch, if technically possible.
Timbalu wrote:(*) In mean, reduce margin left from sidebar, between sidebar and content and right from content a little bit. Just as an example hint, set max-width to 84em in #top > div, main { } would do.
No, it would not “do”. it would work only on screens which offer enough room for 84em (in standard text size), which means screens (window sizes, actually) at least 1344 pixels wide. While that may be a somewhat standard desktop resolution these days (I, for one, still mostly work in 1280px width), it would not help in resolutions below that, i.e. 1024-1342 pixels. That does, for instance, mean it would not work on an iPad in landscape mode.

I can actually give you more space in the content area, but not much. Can you estimate or even say how much more space you need (in pixels)?

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] New WYSIWYG editor

Post by Timbalu » Wed Mar 12, 2014 1:23 pm

YL, you exactly picked with admirable precision the least important point. :)

You are right. It is a matter of screens larger than 1344 pixels. I can't measure exactly the pixel I would need for the content, since you used percents for the sidebar and content, with good reasons.

The more I think about it, an option for a 2-liner break, like I suggested, and a change to the css width is sort of useless and my 'personal preference' has to get used to this "floating" toolbar, I assume.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
yellowled
Regular
Posts: 6988
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: [2.0] New WYSIWYG editor

Post by yellowled » Wed Mar 12, 2014 2:17 pm

Timbalu wrote:YL, you exactly picked with admirable precision the least important point. :)
No, I picked the (only) point I could actually answer. :)

As for the CKE plugins to be bundled, I'm kind of ambivalent since I don't use a wysiwyg editor myself. You did a great job with the CKE plugin for 1.7.x, so I would suggest just using the same plugins used there (if that makes any sense). If you need to add plugins to accomodate for the integration into the core in 2.0, my only suggestion would be to keep it lean, i.e. only add plugins which are required in some way, shape or form.

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
garvinhicking
Core Developer
Posts: 30014
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: [2.0] New WYSIWYG editor

Post by garvinhicking » Wed Mar 12, 2014 3:17 pm

Hi!
Can I purge the Xinha and previous htmlarea(js) occurences to replace CKEDITOR fully into /htmlarea directory without any other old Editors?
I would say so, yes. No reason to keep that old stuff floating around. One wish: If possible, include as little PHP code from CKEditor as possible. In the past we've often had security issues with bundled PHP scripts of Xinha or htmlarea (Spellchecker and Image Manager) and because of that had to release new s9y versions, even though we did not utilize their PHP scripts.
If any (Garvin?) objects this isn't possible because of compatibility, would it be a solution to port the XINHA core part into a (additional) plugin and then cleanup /htmlarea for the use of CKEDITOR singulary? If so, I would also need to know, why we should keep the old in there, without actually giving access to it? ;-)
Shouldn't be needed. Ideally, the serendipity_event_xinha plugin would work in 2.0 so we don't need any Xinha parts in the core anymore.
We would need to agree which CKE plugins we add to it. (This is an urgent need for switching modes in combo with the ML, for example). I have some experiences on this by the plugin development.
Sure, which ones do you propose? I don't have knowledge with CKE, so I don't know anything. :)
There is an issue left with the core CKEDITOR and the S9y tpl js, which is a Milestone beta for me. (I changed the MS therefore) It still does not recognize staticpage nuggets, since they are build independently (see my note to https://github.com/s9y/Serendipity/issues/92). With my CKE Plugin this is not a problem, since I wrote a general function for all textareas. If we all can concur having that in the core CKE, I will implement it.
Sounds good, can you propose a diff so I can see what exactly would be needed? On the other hand, the ideal way would be to fix the Spawn/Core API so that other WYSIWYG plugins can properly put nuggets into WYSIWYG as well, not only CKE.
Another (minor) issue - worth some words - is an agreement about using or purging the standard 2-line button groupment. Currently it is set to a 1-liner, to keep the responsive backend mode easy.
Though I understand the reason, I don't like that and would like to support the 2-line standard by option, like the plugin does.
To me ideally it would be 1-line and floating automatically depending on window size. The rest I don't understand ;)

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
onli
Regular
Posts: 2190
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] New WYSIWYG editor

Post by onli » Wed Mar 12, 2014 3:22 pm

Timbalu wrote:Can I purge the Xinha and previous htmlarea(js) occurences to replace CKEDITOR fully into /htmlarea directory without any other old Editors?
Note that the current ckeditor is already under htmlarea. I don't mind removing xinha entirely, but it is not strictly necessary.
If any (Garvin?) objects this isn't possible because of compatibility, would it be a solution to port the XINHA core part into a (additional) plugin and then cleanup /htmlarea for the use of CKEDITOR singulary? If so, I would also need to know, why we should keep the old in there, without actually giving access to it? ;-)
We certainly should be able to provide xinha a a plugin, if we want to. The argument for keeping it is "because it might still be used in another, custom backend interface". But i doubt that case exists.
We would need to agree which CKE plugins we add to it. (This is an urgent need for switching modes in combo with the ML, for example). I have some experiences on this by the plugin development.
What are we talking about here?
There is an issue left with the core CKEDITOR and the S9y tpl js, which is a Milestone beta for me. (I changed the MS therefore) It still does not recognize staticpage nuggets, since they are build independently (see my note to https://github.com/s9y/Serendipity/issues/92). With my CKE Plugin this is not a problem, since I wrote a general function for all textareas. If we all can concur having that in the core CKE, I will implement it.
That is *not* an issue that blocks the beta, as it is not something that would introduce users to change that is not easily revertable and they might get accustomed to. it is perfectly fine to restore missing functionality later on.

That said, why exactly doesn't it work with them? I thought the old api was restored? Is the editor JS spawned, but it doesn't react to the class/ids of the staticpage textareas, or is this another issue?
Another (minor) issue - worth some words - is an agreement about using or purging the standard 2-line button groupment. Currently it is set to a 1-liner, to keep the responsive backend mode easy.
Though I understand the reason, I don't like that and would like to support the 2-line standard by option, like the plugin does.
But this would need to have the current backend sidebar/content ratio to be slightly wider (*) for staticpages, to keep the 2-liner appear nicely on desktops. Else it is useless work to change the current 1-liner.
I'm happy to see this is already resolved. I don't see at all why the editor should need more space than it alreads uses, and why a 2-line-toolbar would need more horizontal space to be able to use more vertical space.

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] New WYSIWYG editor

Post by Timbalu » Wed Mar 12, 2014 4:04 pm

garvinhicking wrote:I would say so, yes. No reason to keep that old stuff floating around. One wish: If possible, include as little PHP code from CKEditor as possible. In the past we've often had security issues with bundled PHP scripts of Xinha or htmlarea (Spellchecker and Image Manager) and because of that had to release new s9y versions, even though we did not utilize their PHP scripts.
garvinhicking wrote:Shouldn't be needed. Ideally, the serendipity_event_xinha plugin would work in 2.0 so we don't need any Xinha parts in the core anymore.
Alright. I suppose we all agree happily to this. Sure I know about the security flaws we had in the past, that is why I would never add a samples directory... for example.
garvinhicking wrote:Sure, which ones do you propose?
At least all the ones I added to support S9y internals, like the procurator plugin... (by interest read the ckeditor plugin release thread).
garvinhicking wrote:Sounds good, can you propose a diff so I can see what exactly would be needed? On the other hand, the ideal way would be to fix the Spawn/Core API so that other WYSIWYG plugins can properly put nuggets into WYSIWYG as well, not only CKE.
That will be more work I assume... I do not know if that will be possible.

Fixing the Spawn/Core API for other plugins, would be something for the one having broken it, I suppose, if it is not aready fixed by my last commit for https://github.com/s9y/Serendipity/comm ... ed5ae830da html nugget plugins. We will have to investigate this.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] New WYSIWYG editor

Post by Timbalu » Wed Mar 12, 2014 4:11 pm

onli wrote:What are we talking about here?
Please read my answer to Garvin and the ckeditor plugin release thread for details.
onli wrote:That is *not* an issue that blocks the beta, as it is not something that would introduce users to change that is not easily revertable and they might get accustomed to. it is perfectly fine to restore missing functionality later on.
Since the upper questions have been stated yes, this is ok for me.
onli wrote:That said, why exactly doesn't it work with them? I thought the old api was restored? Is the editor JS spawned, but it doesn't react to the class/ids of the staticpage textareas, or is this another issue?
Please see for yourself. If I had the time to describe it in detail, I would be able to fix it myself on the fly.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
onli
Regular
Posts: 2190
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] New WYSIWYG editor

Post by onli » Wed Mar 12, 2014 4:14 pm

Please see for yourself. If I had the time to describe it in detail, I would be able to fix it myself on the fly.
Hmpf. Note that I'm a not happy about that, since you closed the corresponding issue and stated that it works.

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] New WYSIWYG editor

Post by Timbalu » Wed Mar 12, 2014 4:29 pm

No, sorry, that is not the point. The fix fixes the use of all possible plugins, I assume, which rely on functions_plugins_admin.inc.php passed to plugin_config.tpl, via the hook.

Like I already wrote, Staticpages will need an extra workaround/fix in the core or in itself, for other editor plugins than CKEDITOR, since staticpage builds spawnnuggets independently.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
onli
Regular
Posts: 2190
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] New WYSIWYG editor

Post by onli » Wed Mar 12, 2014 4:35 pm

Ok (though I'm not certain what you mean with giving a php-file to a tpl, but I will check your commit later and see). That we will solve, we should be able to copy the approach in 1.7. Or was that broken there as well?

Regarding the plugins, by skimming the plugin thread I did not see anything regarding the plugins. You might want to present them here in a short fashion if you want our input before integrating them.

User avatar
garvinhicking
Core Developer
Posts: 30014
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: [2.0] New WYSIWYG editor

Post by garvinhicking » Wed Mar 12, 2014 5:01 pm

Hi!

I think what we need to do is actually check Serendipity 2.0 with those plugins (in order of importance):

* serendipity_event_ckeditor
* serendipity_event_tinymce
* serendipity_event_xinha
* serendipity_event_fckeditor (if that doesn't work, I wouldn't pay attention)

With each of those WYSIWYG plugins we'd need to check:

* Will it replace the Core's CKEditor instance properly (event hooks "backend_wysiwyg", "backend_wysiwyg_finish" and "backend_wysiwyg_nuggets")?
* Will it be able to process blog entry bodies
* Will it be able to process blog extended bodies
* Will it be able to process HTML nugget contents
* Will it be able to process Staticpage contents
* Does it provide a button to the s9y media library, and if so, does it work? (serendipity_event_xinha for example points to serendipity_admin_image_selector.php)
* Does serendipity_event_emoticonchooser work with this WYSIWYG component?
* Does serendipity_event_autosave work with this WYSIWYG component?
* Does serendipity_event_wikilinks work with this WYSIWYG cpomponent?
* Does serendipity_event_faq work with this WYSIWYG component?
* Does serendipity_event_includeentry work with this WYSIWYG component?
* Does serendipity_event_youtube work with this WYSIWYG component?

... and if not, try to fix the problems. Best case: Inside the core. OK case: Inside the plugin file (simply due to BC so that WYSIWYG users might not necessarily need to upgrade their plugin, even if they should). The plugins I listed to test with all make use of checking for those WYSIWYG editors, so it might be good to also test them with the bundled CKEditor (search for "htmlarea" within their codes).

I'm afraid to ask, but: Any takers? :-)

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

Locked