If you updated to 4.8 WordPress you’ll notice a lot of nice improvements, but there is one thing that was done that I felt was like an artist over-working her painting: changing the Text widget to use a rich text editor. There are already plugins for that. The old pre 4.8 text widget was a way to add little snippets of html in your widgetized areas (aka sidebars). In many Genesis child themes, we rely on the text widget (pre 4.8) for arbitrary html. Now the new rich text editor does pretty much what the WordPress filters do in a post: strip empty tags and add paragraphs around line returns, so it wreaks havoc on the output IF you edit the content with the updated widget and your html wasn’t completely minified when you pasted it in there.
You can read up about this issue here and here.
When I noticed this, first I thought I’d use a filter and a shortcode, but that didn’t work out. Instead I forked the pre 4.8 text widget class and turned it into a plugin, then I asked for someone else to fork that and do the finishing touches for the WordPress plugin repo. Victor Font did just that and now, while we wait for the approval (takes a few weeks), you can download the zip at the WordPress repository with the link below:
Download the Classic Text Widget Plugin
Check out the Classic Text Widget docs and other information in the WordPress Plugin repository.
How to Use
The slow way of doing it, you would manually copy out the code from the Text widget to the the Classic Text Widget. That can take a long time if you have many sites to update. But doing it this way will also be a problem because, depending on what was in the Text widget, it can be empty (this happened with FontAwesome) for me and others with similar empty tags using pseudo elements in CSS. So what I did was to view the site in the browser before I touched the widgets and get my parsed html from the source code. This is very time consuming.
Here is a much faster and safer way to bulk transfer if you are not adept at using phpMyAdmin and tweaking wp_options table (and possibly others) for serialized data (which is tricky to work with).
First get the new plugin:
Download the Classic Text Widget Plugin
Install it and activate it using the upload plugin button. Read your screen.
Then install and activate the Widget Importer Exporter Plugin from the WordPress repo.
Using that plugin, export your current widgets to a .wie file.
On your local drive, duplicate the .wie file that was generated and rename it something else. Open that renamed .wie file in a code editor (not a word processor).
Find and replace all using the following 2 strings (exact). Make sure you are at the top of the file.
Find:
"text-
Replace:
"classictextwidget-
Don’t forget any of the string including the " and the -.
Note that this is not a curly quote, it’s the inch mark and the dash is a hyphen.
Now using the Widget Importer Exporter plugin, import that renamed .wie file you just found and replaced inside. Don’t worry: existing widgets will not be replaced, the only ones that will be ADDED are duplicates of the text widget but are using the new Classic Text widget. Yay, way faster than by hand and your content stays intact.
The final step is to toggle each sidebar/widetized area and either drag to inactive or delete the ones that are titled “Text: xxxx” and NOT “Classic Text Widget: xxx” or “Text” and NOT “Classic Text Widget” if you didn’t have titles in your widget.
All the best,
Affiliate Notice: I have affiliate links all over the place for companies I recommend. By purchasing through these links you help to support my family and to keep my blog going.
Thanks! You rock!
Would the text replacement not also change the #text-xx ID of the widget, so if you used that #id in your css you would still have a problem? Which you can solve by doing a search & replace in style.css… so more work.
(first time in years that I am profoundly unhappy with WordPress)
Yes, more work. Everything in your CSS using
#text-is now#classictextwidget-. I have been using the plugin “Widget Classes” and using a semantically correct class on the widget instance so I don’t need to do this. I recommend doing that so whether you change to this replacement widget or the html widget coming out in 4.8.1 you don’t have to touch your CSS.There was nothing wrong with using #text-5 p to style something, probably since the first appearance of the Text Widget, so now you you would need 2 more plugins/widgets to do this… For now I will go against to what I have been preaching… I will update but very slowly and maybe not until this html widget appears that should have been in this release in the first place.
Nothing wrong with it, yet it’s not semantic. Widget Classes plugin has no impact on front end, it adds a field to your widget instance. HTML widget will not use #text-, so more work will still happen.
Hi Christina,
Just for my understanding – why do you refer to ‘semantic’ ?
The example I give comes from being delivered designs where a certain design element is only used once, so for many years it as been enough to take the fastest solution #text-xx { some style}
only if you can spare the time to answer.
I just like to put a class on a widget that when I go through my stylesheet(s) I can understand by looking at the class name what it was used for, even if only one time usage. So if I had form it would be named .
form-sidebar-xxor something with-form-in the class name so I can search for it easier as well.First of all, thank you for your work! I think this classical widget can be useful for those who do frequent edits, and don’t want to wait till the 4.9 version, which will probably fix this behaviour. However, I should point out that the new widget actually works *as long* as you are in the Text tab. The problem is that, by the time you get to the Text tab, your original code is lost. So, the real frustration is getting your old code back. There are a couple of solutions to this. Your original code is still in the WordPress database: you can export your database, and look for it there. Or, maybe you kept a copy of it somewhere on your computer.
If you follow these instructions, then you won’t have that disappearing html when switching. You can also get the parsed html if your site was cached by waybackmachine or google. Before I figured this way out, I used my browser window for the html of all the FontAwesome or other disappearing and filter formatted php.
4.8.1 is going to have an html widget, but it is very likely that it will not be an automatic fix. So using this technique to copy over the content will prevent the missing content. One widget of mine had multiple FontAwesome spans and it was just an
in its place.Hi thanks for this Christina, I followed it to the letter but still can’t see my widgets frontend. Nada! I am using a Genesis Aspire theme. I had some CSS class and html in my original old text widgets. If I refresh the site, I see them for a nano second but then they don’t show. I have no idea what to do now. The CSS I used wasn’t prefixed with text widget but I just used things like #homehighlight , for example, to create a color box behind some text. Am I now supposed to rewrite the CSS to add #classictextwidget before any other CSS class or ID I had? I also have divs like one-half first. I am at my witts end over this blessed update! The site is one for a friend who has to launch asap and now this hits us holding us up. I am now at a loss. Hoping you might have some pointers on my next steps. Tnx!
The way you described, you don’t have to use the id for widget in this situation. As far as briefly showing up and disappearing, I would remove the
fadeup-effectclass on your front-page.php widgets. See if that resolves it and let the content show up as normal (no fade in). The Theme developer needs to help you, I have never used Aspire theme. It would require some time to trouble shoot what the issue is. Be sure that you have cleared cache and are not getting any js errors.Thank you, and i’m waiting for 4.8.1 to release soon.
Awesome Christina, thank you so much for this solution!
OMG, you are awesome! Like you, I have some spans for my social icons, so this solution really helped a lot. Many thanks!
This plugin was a great idea but the more serious problem remains- how is it that the wordpress core team made this change without realizing the havoc it would wreak and are they adjusting their thinking to avoid a repeat of this mess? They need to emphasize testing and not messing sites up rather than getting out as many ‘improvements’ as quickly as they can.
I agree. But the immediate need is a fix on the day you upgrade and things break.
Thank you so much for this!
Cheers!
Thanks a million for the plugin!