WordPress 4.8.1 Adds a Dedicated Custom HTML Widget

When WordPress 4.8 was released last month, it introduced TinyMCE functionality to the Text widget. Unfortunately, this caused issues for those who use Custom HTML as the Visual editor often strips out portions of the code.

WordPress 4.8.1 Beta 1 is available for testing and addresses this problem by including a dedicated Custom HTML widget.

“For advanced users or any user who needs to paste in HTML snippets, there is now a dedicated ‘Custom HTML’ widget that is specifically for adding arbitrary HTML to your sidebar,” Weston Ruter, said.

“This widget will retain the application of the widget_text filters, in addition to having a new dedicated widget_custom_html_content filter.

“For use cases that involve adding content to your sidebar, the Text widget will continue to feature the same Visual editing interface that the post editor has (TinyMCE).”

Users who access Text widgets that have Custom HTML in WordPress 4.8.1, will see a note at the top of the widget that suggests using the Custom HTML widget.

TextWidgetNotification

If a user pastes or types HTML into a text widget with the Visual editor active, WordPress displays an Admin Pointer suggesting that they use the Text tab instead or use the Custom HTML widget.

TextWidgetAdminPointer
Text Widget Admin Pointer

The Custom HTML widget works similar to the Text widget in WordPress 4.7 and below.

CustomHTMLWidget
Custom HTML Widget

Sites that have existing Text widgets containing custom HTML that may be modified by the Visual editor, are opened in a legacy mode.

Legacy mode retains the old Text widget interface, including the checkbox on whether or not to automatically add paragraphs. This change prevents the Visual editor from altering code.

Ruter says the ideal way to test these improvements is to install it on a staging site that has Text widgets containing HTML and are known to be problematic in WordPress 4.8. After upgrading, check to see if the widgets open in legacy mode.

WordPress 4.8.1 is scheduled to be released on August 1st. Please report any bugs or errors you encounter in as much detail as possible to the WordPress Alpha/Beta section of the support forums.

20

20 responses to “WordPress 4.8.1 Adds a Dedicated Custom HTML Widget”

  1. That’s probably good news. I’ll admit that I wish one widget handled all that, but that may be asking too much.

    I had noticed that HTML could be busted in the same way that you can do it in the post editor:

    You go into text mode in the editor, stick in some HTML, and save. So far, good. Then you go back in for some reason, and you’re in Visual mode (or switch to it). If you happen to save then, whether changing something or not, the HTML (or shortcode, etc.) might bust.

    Given that both contexts use Tiny, this is no surprise.

  2. I don’t get the point of all these widgets. All functionality can be handled with one HTML + TINY like it is in WP editor. Special image widget, special text widget … what will be next – Text with bold font? Why WP is every update more complicated and bloated? This way after few years WP will need Microsoft-like, complicated lost in the legacy engineers to maintain it. Adding this and that would be not huge issue, if the system is modular and parts are removed after new are added. But the status is, that while something is there, it will stay there until the end of WP.

      • One day one theme designer will recognize that for white background, five menu items, black text … (in your case, dark background and white text obviously) he don’t need to learn JavaScript, bc. he don’t need it. Also one user will recognize that he don’t need a pop up communicating with API if he want to show online a big fish he get during last weekend. Then something cool will happen.
        Some nice movement already exist in the area of flat-file or static websites systems.

  3. Still think it should be one simple “stay out of my code” checkbox wherever you can type anything, to make it take and accept the input as plain text and not butt in, likely with “but still add [ ] line breaks [ ] paragraph breaks” below it if checked. And maybe a separate “do not replace characters” checkbox too, if you want everything exactly as typed, no “nice” quotes, apostrophes, dashes and so on, symbols not replaced with codes, that sort of thing.

    And if switching between checking and unchecking, so between visual and plain, it would switch the view accordingly, revealing code if box is checked, showing how it’d look if the box is unchecked. No different widgets, tabs, whatever, just something to click right under the editing area, wherever it is, simple and consistent.

  4. Widgets are legacy and their continued use shouldn’t be encouraged. Breaking while enhancing existing ones, creating new ones, etc shouldn’t be a focus of any WP release this year. It would save people grief.

    Widgets are more problematic than shortcodes but unlike shortcodes they’re also theme and widget area dependent with no official way to change that behavior. The whole “inactive widgets” situation just needs to go away.

    The Widgets code could be removed from core, along with the Widgets screen and the customizer enhancements now that Gutenberg is going the blocks route. To leave it in is just legacy bloat since they’ve already decided widgets and shortcodes are legacy. Talk about your mixed messages. LOL.

    • Oh really Matt? Well..if so you could have even told this:

      WP is legacy and its continued use shouldn’t be encouraged.

      WP is getting more problematic than other CMSs. The whole “cluttering” situation just needs to go away.

      Instead of just removing widgets and reinvent their functionalities with some other called features what if you invented proper media handling to tell the least? Somehow that area just never gets the improvements it would really need. If there are so many devs willing to contribute to core, they should improve that area first instead of touching/removing anything that already exists, works and people rely on.

  5. Agree 100% with Cavalary above. Should just be an option per page, post, widget, etc. The movement toward semantic, cleaner code and all that is excellent, I get it. But let’s stay on target. Up to here with Tiny’s filters stripping code and having to write functions or use CSS to circumvent that. Then again, maybe I just don’t see the whole picture.

  6. The approach to so many of these features seem to drift more and more into Microsoft’s overarching philosophy. They say, we’ve come up with these really neat improvements which our test marketing says everyone wants. Now take the improvements and shut up. What to break from the crowd and do things differently from others? Don’t expect any cooperation from us-our marketing knows what is best.

  7. I just updated to 4.8.1. I found that on one of my sites a portion of the page suddenly looked very strange afterward, with extra space above a particular site area.

    This was a text widget with just a shortcode in it, nothing else.

    It was tricky to track down – unlike most such appearance quirks/errors, it wasn’t CSS this time. I tracked it down to paragraph opening and closing tags with no content.

    After fiddling some more, I replicated the problem in the same way I did in my other comment above. (to reiterate) If I stick HTML code or a shortcode into a text widget, make sure there are no extra spaces, and save it in Text mode, all is well. If I go back in, change nothing, make sure there are no extra spaces, and happen to save it in Visual mode, this magic annoying extra bit of empty paragraph code appears, and things look funny.

    It sort of seems like wpautop gone awry. :)

    I’m thinking that if someone has their CSS set to add no padding or margins for paragraphs, this may slide by unnoticed on their site, even if the errant P tags are there.

    The good news – the Custom HTML widget seems to be working.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.