IPB3: wysiwyg editor

[coe]

Will there be an wysiwyg editor that works well on the IPB3 release like in ip dynamics (referencing another thread comment). The current although functional wysiwyg is appreciated but very limiting. Something at the caliber of

tinymce, http://tinymce.moxiecode.com/
fkc editor, http://www.fckeditor.net/

would be much more appreciated and I'm sure welcomed by the entire cross platform groups. Unsure why it's not included on the current releases. Perhaps a unforeseen licensing issue.

The current version unfortunately does not have compatibility with certain fruit based computing operating systems on the browser of choice.

thanks.

[Cybertimber2009]

I can't quite tell because I haven't used either of those, but what is the IPS wysiwyg missing in comparision to those?

I see a text paste, word (rte?) paste... but I think they already include that on the back end. A paste is a paste wysiswg handles that automatically. Table functions we don't have... though I'm not sure how often they are useful in posts though.

The rest is handled with BBcode (such as the media tags), no need for the find (posts aren't that long), file & picture upload is handled seperatley, etc etc.

[Strike X]

Would be nice to have wysiwyg plugins.

[Brett B]

There is a Rich Text Editor (RTE) which can be enabled in your settings.

[coe]

I can't quite tell because I haven't used either of those, but what is the IPS wysiwyg missing in comparision to those?

I see a text paste, word (rte?) paste... but I think they already include that on the back end. A paste is a paste wysiswg handles that automatically. Table functions we don't have... though I'm not sure how often they are useful in posts though.

current version missing:
safari support
ex. http://tinymce.moxiecode.com/examples/full.php#
shortcut keys
essentially all word tools required to compose online. Especially usefully for wiki elements or copy and paste from word documents to threads.
and many more....

[Brandon D]

Would be nice to have wysiwyg plugins.

I thought about this... a lot of the popular web apps out there have it to where you can install and switch out editors with ease. I don't think IPB does this because IPB would conflict with a lot of those editor's licenses, and vice versa. At least I think, not for sure.

[Stallyon]

Unfortunately, even open source licences do restrict it's use in commercial software. It's considered profiting from what is meant to be free. Just remember that even free software has a licence and some are incompatible with commercial licences. Just look at SMF and I think it was Joomla!. Developers have to be very careful and either develop their own (which is what I think IPS has done) or try find a licence that would allow it's use in their software.

[coe]

So is IPB in the process of developing a true wysiwyg editor?

Which is cross platform supported?



Has anyone successfully integrated a true wysiwyg into IPB?

[bfarber]

Our WYSIWYG is not going to be up to the level of a WYSIWYG-only package, but I'm not sure what you find wrong with it. To my knowledge, it does work on Safari, Opera, Firefox and IE consistently (that is to say, it works the same across all of these browsers).

[coe]

Brandon,

Thanks for the reply.

These are the following issues:

1. Not supported on the Safari Browser (Rich Text Editor requires either IE6+, Mozilla / Firefox or Opera 9+) even on the current release. So the toggle of adding and removing content doesn't work just keeps adding bb code. Where the user has to manually remove the code or add it. The bbcode is displayed and the behavior is not the same as in firefox on the same platform.
2. No shortcut support. You have to click on the interface to apply the format. Fine for small posts when there are large posts. It's very inconvenient.
3. Unable to copy and paste formatted text from office applications retaining format.
4. Table support
5. Always useful to copy and paste html (if allowed) and be able to edit the source.

[Alex K.]

Testing..

The RTE doesn't work in Safari for me. (Safari 4 beta / Win7)

Shortcuts such as ctrl+b and ctrl+i work for me in Firefox, but not Safari.

[bfarber]

Brandon,

Thanks for the reply.

These are the following issues:

1. Not supported on the Safari Browser (Rich Text Editor requires either IE6+, Mozilla / Firefox or Opera 9+) even on the current release. So the toggle of adding and removing content doesn't work just keeps adding bb code. Where the user has to manually remove the code or add it. The bbcode is displayed and the behavior is not the same as in firefox on the same platform.

2. No shortcut support. You have to click on the interface to apply the format. Fine for small posts when there are large posts. It's very inconvenient.

3. Unable to copy and paste formatted text from office applications retaining format.

4. Table support

5. Always useful to copy and paste html (if allowed) and be able to edit the source.

1) I don't use Safari and was unaware that it (still) didn't work on Safari. That's something we can look into. :) I'm sure there are reasons, but it would be nice to have Safari support if at all possible.

2) There is shortcut support when the RTE is in use. As you pointed out you'll need to test with Firefox to see this. Ctrl + b for instance will bold the highlighted text.

3) This isn't something with "our WYSIWYG" exactly, and we would run into the same issue if we integrated any other WYSIWYG editor. The problem is that applications can do a number of things to get content looking in a particular fashion. For instance, you can use "i" tags, "em" tags, or use CSS to apply italicization. That's all fine, and any WYSIWYG will show you it that way. However, for very obvious reasons we cannot simply insert whatever HTML comes through into the database to be shown on the next page load. We have a strict parsing routine that strips away all HTML tags that we would not allow, then parses through the remaining to ensure they are correct as compared to what HTML tags the WYSIWYG editor would have issued. If we integrated any other editor, we'd be forced to do the same thing for security reasons, so you still wouldn't be able to simply plop in HTML from any source and expect it to come out that way all the time. When you're working with a blog that on you can post in, for instance, you don't have these security concerns. When you're working with forum software where anybody and everybody does post, you do.

4) We have no intentions of adding table support into the WYSIWYG. Too many novice users would screw up the insertion and ultimately break site layouts.

5) The WYSIWYG allows you to edit the raw source. You toggle it with a button at the top left of the editor.

[jagowar]

I know safari was mentioned but any word on getting chrome to work with the wysiwyg? Its not loading on my chrome test setup (windows 7 beta).

[coe]

3) This isn't something with "our WYSIWYG" exactly, and we would run into the same issue if we integrated any other WYSIWYG editor. The problem is that applications can do a number of things to get content looking in a particular fashion. For instance, you can use "i" tags, "em" tags, or use CSS to apply italicization. That's all fine, and [i]any[/i] WYSIWYG will show you it that way. However, for very obvious reasons we cannot simply insert whatever HTML comes through into the database to be shown on the next page load. We have a strict parsing routine that strips away all HTML tags that we would not allow, then parses through the remaining to ensure they are correct as compared to what HTML tags the WYSIWYG editor would have issued. If we integrated any other editor, we'd be forced to do the same thing for security reasons, so you still wouldn't be able to simply plop in HTML from any source and expect it to come out that way all the time. When you're working with a blog that on you can post in, for instance, you don't have these security concerns. When you're working with forum software where anybody and everybody does post, you do.

Actually, the ability copy and paste formatted text is more a platform related issue. However, other WYSIWYG (javascript based tinymce/fckeditor) do support the ability to retain formatting and the ease of just copying and pasting formatting including tables generated in a document is effortless and a enormous time saver in representing content accurately.

I would urge some serious reconsideration for that functionality.

[bfarber]

Actually, the ability copy and paste formatted text is more a platform related issue. However, other WYSIWYG (javascript based tinymce/fckeditor) do support the ability to retain formatting and the ease of just copying and pasting formatting including tables generated in a document is effortless and a enormous time saver in representing content accurately.

If you make a word document with the formatting you are referring to and paste it into the RTE, it will show in that formatting (excluding any CSS on the site that alters how elements display of course). If you switch the editor to view source you will see that it has indeed saved what you pasted into it.

The problem, as I said, is that when you SUBMIT the content, IPB strips lots of HTML tags that we don't allow, then converts what you submitted to bbcode. Many times what you submitted isn't expected content, so it doesn't get converted, and then is stripped out.

I would urge some serious reconsideration for that functionality.

You could always make a table bbcode. ;) While the RTE wouldn't support it unless you modified it to do so, you could at least allow tables to be submitted then. In any event, the availability of any such support would be based upon demand.

[coe]

If you make a word document with the formatting you are referring to and paste it into the RTE, it will show in that formatting (excluding any CSS on the site that alters how elements display of course). If you switch the editor to view source you will see that it has indeed saved what you pasted into it.

The problem, as I said, is that when you SUBMIT the content, IPB strips lots of HTML tags that we don't allow, then converts what you submitted to bbcode. Many times what you submitted isn't expected content, so it doesn't get converted, and then is stripped out.

If the basic supported text is available. The other could be modified by the raw code if html is allowed.

You could always make a table bbcode. ;) While the RTE wouldn't support it unless you modified it to do so, you could at least allow tables to be submitted then. In any event, the availability of any such support would be based upon demand.

Personally I have no objection but this option would be for our user base that would opt not to and in all honesty if the software could be modified to adjust this why should they? It's just an ease of use that we trying to implement utilizing IPB. This functionality would be of course a preferred integration in the higher demanding enviroments that might exclude the general user base but would be very advantageous to IPB over its competitors.