Jump to content


Photo

Editor isHtml not fully working


The new editor 'isHtml' flag, while it can be set from the backend, does not remove the button and add the message like it does when you check the box on the topic post form.

This means when you go to add or edit a post in the forums, the checkbox controls the functionality. If you have an application (like IP.Content) where the option can be configured from the ACP and there is no front end checkbox/form field, setting setIsHtml() behaves differently and does not work correctly.

From IP.Content, I call this and set it to true. The end result is that the editor is simply set to STD mode by default, but the user can change it back to RTE.

Expected behavior: The button should be removed and the message should be shown underneath the editor (it would be ideal if there was a way to override the message shown as well, as the message may need adjusting in other areas, such as IP.Content, when the user is unable to control the behavior, etc.).

Status: Fixed
Version: 3.3.0
Fixed In: 3.3.2


10 Comments

There isn't a standard editor interface for the HTML checkbox. The app developer is expected to add it where relevant to their posting view and tie it into the framework.

In a future version, we can consider making it a standard editor element but that means it'll have to be moved, likely under the editor.
The problem is, for IP.Content, there is no public "Use HTML" checkbox. The administrator determines in the ACP if HTML is allowed in the field or not, and the end user submitting the content has no public option for this.

Thus, the only thing we can do in this scenario is set setIsHtml() to false. The problem is, this does not actually have the same effect as allowing HTML when submitting a topic in the forums, and subsequently the user ends up with a different experience (and potentially mangled HTML if they switch the editor back and forth).
Oh, I understand now.

I can make that change.
It's not a *huge* deal. It works (after I fixed the associated bugs in Content), but the main problem is they can toggle the editor which as we know will break their HTML if they do. If I can prevent that, it would be more consistent I think.
Is this the issue causing my articles edits to show CODE instead of the usual WYSIWYG editor?

evrytime we post a new article in IP.Content we use the WYSIWYG editor... but when we try to edit it goes back to showing code and the WYSIWYG editor is turned off (it can be turned on) but its very VERY annoying... most of my editors hate me because of this change...

is there a way to mantain WYSIWYG editor always on? I dont like it to switch automatically in every edit...'i eant it to be default,
I can't find any changes to correct this, after testing locally and reviewing SVN. This still seems to be an issue.

@ran3v4 - unfortunately, no. If you allow HTML in an editor field it should disable the RTE completely as of IP.Board 3.3.0. RTE + allowing HTML is no longer supported (go to post a topic, enable HTML for the post, and watch as the editor is disabled). This bug report is about making this behavior consistent with editors utilized by IP.Content (basically, when we specify that HTML is on, the toggle button needs to be removed and STD mode forced enabled).
Brandon,

It should be done automatically.

Can you give me an example of where this is for IP.Content?
1) Do a fresh default installation of IP.Content
2) Under Other Apps -> Content -> Articles -> Manage Fields click on "Teaser Paragraph"
3) Change the "Allow HTML" option to one of the two yes options.

(Make sure you SVN updated from yesterday, because I fixed a related bug yesterday)

4) On the front end, go to the articles page (can go to Other Apps -> Content -> Pages and click the small green arrow next to articles.html as a shortcut to the page from the ACP)
5) Click the Add Article button (it won't show if you don't have permission to add articles)

Here is where the bug is presented. If you are allowing HTML in the field, we call the isHtml() method of the editor, and it should (1) set the field as STD and (2) remove the toggle button so the user can't swap it back to RTE. It does #1, but not #2.

Posted Image
Is there some sort of manual change I can apply to fix this prior to 3.3.2?

I assume this fixes it not just in the ACP, but in the 'add' UI in the main site UI right?

P
No there is no fix available as it requires to edit multiple files, you'll have to wait for 3.3.2.