Support » Fixing WordPress » How to Disable Visual Editor in The Text Widget

Viewing 15 replies - 16 through 30 (of 42 total)
  • The Classic Text Widget plugin was released yesterday, the exact functions as the previous text widget:

    https://wordpress.org/plugins/classic-text-widget/

    You can switch over in bulk (sort of) with instructions here:

    https://christinacreativedesign.com/how-to-bulk-replace-the-4-8-wordpress-text-widget-with-the-classic-text-widget/

    Also…
    In order to copy and transfer the HTML, JS or PHP code to another widget or plugin, before editing, rename and replace the class php file of the widget (wp-includes/widgets/class-wp-widget-text.php) with the version prior to 4.8
    This works correctly

    @_regeek – The code you provided did not prevent corruption of my previously saved text widget coding.

    Ref:
    remove_filter(‘widget_text_content’, ‘wpautop’);

    Plugin I wrote doesn’t disable the visual editor – put it does re-introduce the add paragraph check box. Solves most of my issues but don’t think it covers all the code mangling ( although I’m not seeing code mangling but then maybe my tags are ok )

    https://wordpress.org/plugins/add-paragraphs-option-to-text-widget/

    Me also have the same issue.

    Please find a solution to disable the visual editor in widgets. I want only text editor in all widgets.

    The same problem, the site is down and the html code created by site developer is modified by WP 4.8 into a widget text.

    I had to to use the backup of database to get back the good code (more than 10,000 lines of HTML into 20 widgets…).

    The basis principle of text widget was to inject html code tested elsewhere into WP display using directly the widget or the corresponding shortcode. This feature is broken and replaced by some grub with 4.8.

    This comes from a crazy idea by somebody who ignores the basic concepts of SGML->HTML.

    A basic principle : no chars CR, CRLF, TAB used commonly into editors are taken in account by html interpreter (html parser + graphic generation, this special chars are replaced by who writes the code by &xxxx; codes or tags as <br> new line, and to create paragraphs into text <p></p>).

    The previous version with the option “treat the “change-line” as paragraph”, the option “auto generate paragraphs” was an infringement to concepts but it was an option, then the code (syntax is generally tested by other ways) was always preserved when the option was not choosen.
    Generally if the basic html rule were used into the html code the result using this option was an invalid code able to crash any site, server and browser if the content was not a very simple text.

    Any editor developer had always two main problems :

    • Write using WYSIWYG and generate good html code (parsable without error)
    • Be able to show any HTML code into their WYSIWYG editor

    This problem was absent from previous version and problem have been added unconsciously.
    The problem is that it is not an addition of a new feature but an important change in basic features which simply suppresses the use of html into text widgets replaced by some grub.

    For interpreters, a first problem was that, sometimes, the code submitted to display was wrong, then they had to check the code before and reformat with some hypothesis or send warnings on display about errors found (as Phpstorm does).
    Another problem has been and still exist is that the WYSIWYG editor is not always able to display any nevertheless valid code (for example SVG draws).

    The idea to add a WYSIWYG editor to widget text is not basically foolish, it can be a useful option for some simple widget text (avoids to have a main HTML source code into an editor like PhpStorm (parser, syntax manager and test on browsers) from which the code is copied into the text widgets.

    But the idea to change the source code given by the developer (admin-webmaster) to fit hypothesis of the interpreter on the content defined by the site developer is pure delirious.

    So, it is not a bug it a main conception error.

    Best regards

    Trebly

    Yes, there are some heated discussions on this in a couple of Facebook forums as well:

    Advanced WordPress
    https://www.facebook.com/groups/advancedwp/permalink/1529658927096316/

    Genesis WordPress
    https://www.facebook.com/groups/genesiswp/permalink/1534964056554786/

    Small update – my plugin mentioned above I have added disabling of the visual editor in the text widget as default, now.

    There you go!

    Thank goodness I updated to 4.8 on a staging server first. The visual editor on text widgets is buggy as hell. I’m seeing it insert the code for the “Save” button for the widget itself:

    `<span style=”border-radius: 2px; text-indent: 20px; width: auto; padding: 0px 4px 0px 0px; text-align: center; font: bold 11px/20px ‘Helvetica Neue’,Helvetica,sans-serif; color: #ffffff; background: #bd081c no-repeat scroll 3px 50% / 14px 14px; position: absolute; opacity: 1; z-index: 8675309; display: none; cursor: pointer;”>Save</span>

    Why the devs thought it was a good idea to make a text widget a non-text widget is beyond me. It’s a solution looking for a problem. Introduce a rich text widget as a new option. This was poorly conceived and implemented IMO. On a side note, I find the constant updates to WP problematic. Security updates, yes, but it’s becoming a major task to test any new version as WP becomes more and more complicated. </ rant>

    • This reply was modified 1 year, 3 months ago by  bahead.

    Additionally, WordPress is long overdue for a “Code” widget that is specifically for placing raw code (shortcodes, javascript, SVG, HTML, etc.). This is what people would have been using if it had been available, and then now the addition of the visual editor to the text widget would not be breaking anything, and would have been the welcome addition it was hoped to be…

    This change caused an ongoing crisis on dozens of my sites as users went and edited a widget like they usually do, but then had all the code-containing widgets insta-break on them.

    Sure one can use:

    remove_filter('widget_text_content', 'wpautop');
    remove_filter('widget_text_content', 'wptexturize');
    remove_filter('widget_text_content', 'capital_P_dangit');
    remove_filter('widget_text_content', 'convert_smilies');

    but that doesn’t help keep any code from being mangled when changing over to the visual editor and back to text (and it always defaults to “Visual” now).

    • This reply was modified 1 year, 3 months ago by  j893.
    • This reply was modified 1 year, 3 months ago by  j893.

    Update… They are working on a “Code” widget:
    https://core.trac.wordpress.org/ticket/40907

    Hi,
    I’ve got a weird issue too. The editor is removing the links that I’m coding in the text!.. Even when using the ‘text’ editor instead of ‘visual’ and even if using the link button that is made available..
    Any hook that we can implement in our functions.php?
    thanks

    WPML adds Multilingual Text Widget to panel, it is so fortunately free from WYSYWIG Visual Editor and does not break the code.

    @yerio – Thank you!! Your little functions script saved our site. The auto formatting of the new text widgets is indeed troublesome when it clashes with scripts and styles.

Viewing 15 replies - 16 through 30 (of 42 total)
  • The topic ‘How to Disable Visual Editor in The Text Widget’ is closed to new replies.