Support

Account

Home Forums Bug Reports Bug: WYSIWYG field with visual editor disabled

Bug: WYSIWYG field with visual editor disabled

  • I’ve stumbled across an issue in the create_field function in core/fields/wysiwyg.php when the user editing a post with a WYSIWYG custom field has the visual editor disabled.

    This happens when editing an existing post, as the data is stored correctly the first time, but to an unsuspecting user, would be modified to contain wrapping <p></p> tags.

    On line 142, wp_richedit_pre is used, automatically populating the WYSIWYG field with the appropriate custom field, but then wraps it in <p></p> tags. When this is then saved, the <p> tags are stored in the custom field too.

    In my case, this caused issues when using the WordPress oEmbed functions to convert YouTube URLs to embedded content.

    The code in the create_field function should intelligently detect whether the user has the visual editor disabled or not, and as such should use the wp_htmledit_pre function instead of wp_richedit_pre if the user has the visual editor disabled.

    The current code led to existing custom field content unexpectedly having paragraph tags added, and then stored with the content in the database.

  • Hi @chrishutchinson

    Interesting! Just to clarify, you are talking about the user specific option to disable Rich Content Editing?

    Thanks
    E

  • Yep, that’s the one! I’ve attached a screenshot of the option, just to clarify.

    Thanks,
    Chris

  • Thanks mate.

    I’ll add this to the to-do

  • Hi @chrishutchinson

    Thanks again for the bug report.
    I have successfully reproduced the error and have included some logic to use both the functions mentioned above!

    You can download the latest github version to see the code in action.

    Thanks
    E

Viewing 5 posts - 1 through 5 (of 5 total)

The topic ‘Bug: WYSIWYG field with visual editor disabled’ is closed to new replies.