Do you want to restore the classic widgets editor in WordPress?
The release of WordPress 5.8 removed the classic widgets editor in favor of Gutenberg widget block editor to control your website widget areas.
In this article, we’ll show you how you can disable widget block editor in WordPress, step by step.
Why Restore Classic Widgets in WordPress?
The widget block editor offers a lot of the same functionality as the classic widget editor. Plus, it gives you more control over the appearance of your widgets.
However, if you’ve been using WordPress for a while, then you may be more comfortable using the classic widget editor on your WordPress website.
Or, you enjoy the simplicity of the classic widget editor and want to disable widget blocks, like how some users prefer disabling the block editor.
That being said, let’s take a look at how to restore the classic widget editor in WordPress. Simply use the quick links below to jump straight to the method you want to use.
Method 1. Restore Classic Widgets by Using a WordPress Plugin
The easiest way to restore the classic widget editor is by using the Classic Widgets plugin. This plugin is developed and maintained by the WordPress core team.
First thing you need to do is install and activate the plugin. For more details, see our beginner’s guide on how to install a WordPress plugin.
Upon activation, your WordPress blog will go back to the classic widget editor. There are no settings for you to configure.
Now, you can navigate to Widgets » Add New in your WordPress admin panel to go to the widget dashboard.
To add new widgets, simply drag a widget to an available widget area.
Then, you can customize the widget settings. Make sure you click the ‘Save’ button to save your widget.
If you want to use widget blocks at any point in the future, then simply deactivate the plugin.
Method 2. Restore Classic Widgets by Adding Code to WordPress
Another way to disable widgets blocks is by adding code to WordPress. If you haven’t done this before, then see our beginner’s guide on how to copy and paste code in WordPress.
Do you want to show Google Maps on your WordPress website?
If you’re running a local business, then displaying Google Maps on your site can help users easily find your location. It can also help improve your site’s search engine visibility so you can attract more website visitors.
In this article, we will show you how to add Google Maps in WordPress.
Why Add Google Maps in WordPress?
Did you know that Google Maps is the most popular navigational app on all platforms?
If you have an office or physical store address, then adding Google Maps to your WordPress website makes it easy for users to quickly locate your physical stores, restaurants, or retail outlets. This helps you attract more customers and generate more business.
Not only that, but embedding Google Maps can also improve your WordPress SEO. According to Google, 46% of all searches are local. Adding Google Maps to WordPress can boost your local SEO and improve your visibility in local searches.
Now there are two ways to embed Google maps in WordPress, and we will show you both of them.
The benefit of the second method is that it follows all local SEO best practices, so if you use it, then Google will start to include your location on Google Maps. It will also display your business information like name, logo, address, phone number, open hours, and more in local search results.
Below are the quick links that you can use to go to the section you prefer:
That being said, let’s see how you can add Google Maps to WordPress.
How to Add Google Maps in WordPress without Plugin
If you just want to quickly embed Google maps in a WordPress post or page, then you can use the default iFrame method.
Simply go to the Google Maps website and type in any street address in the search area.
Next, you need to click the Share icon and it will show a popup with the option to either Send a location link or Embed a map. You need to select the Embed a map option.
After that simply copy the HTML code for Google maps, and then open the page where you want to embed the map. Inside the block editor, you need to add a Custom HTML block.
Now you can simply paste the embed code you copied from Google maps, and then update or publish the page to preview the changes.
This method works for quickly embedding Google maps, but it doesn’t give you maximum SEO benefits.
If you’re a small business, restaurant, or online store with either a single or multiple physical location, then we recommend using the next solution to maximize your Local SEO rankings because it uses proper open graph data to help you rank higher in Google.
How to Add Google Maps to WordPress with Local SEO Plugin
The best way to add Google Maps and optimize your site for local SEO is by using All in One SEO (AIOSEO).
It’s the best SEO plugin for WordPress because it helps you get higher SEO rankings without editing code or hiring a developer. Over 3 million professionals use AIOSEO to improve their search engine rankings.
For this tutorial, we’ll be using the AIOSEO Pro version because it includes the Local SEO feature and other powerful optimization options. There is also a free version of AIOSEO that you can use to get started optimizing your site for search engines.
First, you’ll need to install and activate the AIOSEO plugin in WordPress. For more details, please see our tutorial on how to install a WordPress plugin.
Upon activation, the plugin will launch the setup wizard. You can click the ‘Let’s Get Started’ button to configure the plugin. If you need help, then please refer to our guide on how to properly set up All in One SEO in WordPress.
Next, you can head over to All in One SEO » Local SEO from your WordPress dashboard.
Then click the ‘Activate Local SEO’ button to get started configuring the local settings.
Once the Local SEO addon for WordPress is activated, you can add a single location or multiple locations in AIOSEO and display them on Google Maps. We’ll show you how to add both to your website.
Adding a Single Location
To add your locations, business information, open hours, and more, first you need to go to the ‘Location’ tab under All in One SEO » Local SEO.
If you have a single physical location, then keep the ‘Multiple Locations’ option set to No.
After that, scroll down to the ‘Maps’ section to pin your exact location.
Simply enter your address in the ‘Enter a query’ field and Google Maps will show your location.
Once you’ve entered your location, don’t forget to click the Save Changes button.
Adding Multiple Locations
If you have more than one physical location, then you’ll need to enable the ‘Multiple Locations’ setting under the ‘Location’ tab in Local SEO.
After that, a new Locations menu will appear in your WordPress admin panel.
Go ahead and navigate to Locations and then click the ‘Add New’ button.
Once you’re in the WordPress editor, scroll down to the ‘Map’ section.
Here you can enter your address in the ‘Enter a query’ field.
After entering your location on the map and adding location information, go ahead and click the ‘Publish’ button.
You can now repeat this step and add as many locations as you want for your business.
Once you’re finished adding your locations, you can go to the ‘Maps’ tab back in the All in One SEO » Local SEO menu.
Here you will have to enter a Google Maps API key.
Now, let’s see how to create an API key for Google Maps.
Creating a Google Maps API Key
To start, you’ll need to visit the Google Maps Platform website and click the ‘Get Started’ button.
After signing in with your Google account, you’ll need to set up a billing account.
Google Maps Platform has pay-as-you-go pricing, and they offer the first $300 of monthly usage for free for all users. For most websites, that will easily cover a simple map embed like the one we’re creating in this tutorial.
Don’t worry, they will not charge you any fees unless you manually upgrade to a paid account.
To get started, go ahead and click the ‘Create Billing Account’ button.
Next, you can select your country and choose what best describes your organization from the dropdown menu.
Once you’ve selected this information, click the checkbox for Terms of Service and then click the ‘Continue’ button.
On the next screen, you’ll need to enter your phone number for verification and click the ‘Send Code’ button.
After verifying the code, the next thing to do is enter your business name, payment method details, and billing address.
Once you’ve entered these details, click the ‘Start my Free Trial’ button.
Next, you’ll be asked a series of 4 questions about your organization and how you’ll use the Google Maps Platform.
Google Maps will ask about your primary goal for using the platform, which industry you’re in, select a use case, and your company size.
After answering these questions, go ahead and click the ‘Submit’ button.
You’ll now see a popup with your Google Maps API key.
You can copy and save this key in a text file for future use.
Now that you’ve created a Google Maps API key, you’ll need to head back to your WordPress dashboard to enter it in AIOSEO Local SEO settings.
Configuring Google Maps Settings in WordPress
You can now go back to All in One SEO » Local SEO from your WordPress dashboard and then navigate to the ‘Maps’ tab.
Go ahead and enter the Google Maps API Key in the ‘API Key’ field. You’ll see a preview of the map in AIOSEO as soon as you add the key.
Next, you can scroll down to edit the map settings.
AIOSEO lets you display Google Maps using a Gutenberg block, shortcode, widget, or PHP code. It also lets you choose different map styles and add a custom marker to your map.
Don’t forget to click the ‘Save Changes’ button when you’re done.
Displaying Google Maps in WordPress
Next, you can add Google Maps to any WordPress post or page. To start, simply edit or add a new page on your website.
Once you’re in the block editor, click the ‘+’ button at the top and add the ‘AIOSEO Local – Map’ block anywhere on the page.
After that, your Google Map will be added to the page.
AIOSEO also lets you edit the map settings from the options on your right. For instance, you can show labels and icons, add a custom marker, and edit the map’s width and height.
If you have multiple locations, then you can select which location to highlight by choosing from the options given in the menu on your right.
Simply click on the ‘Location’ dropdown menu and select your preferred location to display on your website.
Once you’re satisfied with your settings, go ahead and publish the page.
Now you can visit your website to see Google Maps in action.
You can also add Google Maps to your site’s widget section, like the sidebar or footer.
To start, head over to Appearance » Widgets from your WordPress admin panel. Next, click the ‘+’ button and add the ‘AIOSEO Local – Map’ widget block where you’d like to display your location.
After that, you can edit the widget settings.
For example, you could add a title, change the width and height of the map, choose which location to display if you have multiple locations, and edit the label.
That’s it!
Now when you update your website you’ll see Google Maps in your widgets area.
We hope this article helped you learn how to add Google Maps to your WordPress site. You can also check out our guide on the best WordPress plugins for small business, and our expert pick of the best identity theft protection service for entrepreneurs.
If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.
I was doing my Advent of UI Components, and I stumbled upon the from-font value for the text-decoration-thickness CSS property. I was curious about it, so I did a little research and I think what I found (and learned) is both interesting and worth sharing.
If the font file includes information about a preferred thickness, use that value. If the font file doesn’t include this information, behave as if auto was set, with the browser choosing an appropriate thickness.
So, the from-font value is used only if the font file has the definition for the thickness of the line. Otherwise, browsers use the auto value, which tells the browser to choose the thickness. I wanted to find out how that works, so I made a few demos comparing it to the other values.
Demo 1: text-decoration-thickness: auto
In the first demo, I wanted to see how the auto value for thickness works with under, over, and strikethrough lines for the default font family.
I didn’t find anything particularly interesting here, except that some combinations don’t work very well for strikethrough text (if you ask me). For example, using a wavy decoration with strikethrough isn’t readable, but that might be the desired output in some scenarios, I guess.
Demo 2: text-decoration-thickness: 0px
In the second demo, I wanted to see how the text works with thin lines.
The lines work with paragraphs or smaller text, but the thin strikethrough line doesn’t work very well with large text as the strikethrough line is hard to detect.
I also learned that you cannot set the line thickness below 1px. In the demo, the line thickness is set to 0px, but the browser renders a 1px line anyway.
Demo 3: text-decoration-thickness: from-font and font-weight
Next, I wanted to see if the text-decoration-thickness: from-font declaration changes with the font weight. On the left, the value is set to from-font; on the right, the value is set to auto.
The from-font value doesn’t seem to follow changes to the text’s font weight, at least not with when Roboto is the font family. There is no difference between how big or bold the text is set. The line thickness is the same if the value is set to from-font.
It is worth noting that Firefox renders the line thickness the same for both values, so my guess is that Firefox actually uses the from-font value for the auto value.
Demo 4: text-decoration-thickness: from-font and font-family
In this final demo, I wanted to see how the from-font value works with different font families. It doesn’t impact the paragraphs or the smaller font sizes because it renders the smallest value, 1px. The difference is visible for the bigger font sizes, like default <h1> elements, but only if you look very closely. Also, the strikethrough line is once again too thin on bigger text. This is something that font designers and developers might consider when designing and defining fonts.
Browser support
You can most certainly use the text-decoration-thickness property today since most modern browsers support this property.
So, should you use it?
Although the from-font value might seem like a good idea, I don’t think it should be used just yet. There are too many inconsistencies with the default text-decoration-thickness value across the browsers (which Šime Vidas has covered in great depth), so it is no surprise that the from-font value is still not working that well. Maybe the from-font value should be defined in percentages or some other relative unit so that it changes with the font size. Maybe font designers feel that it shouldn’t work that way. Either way, it seems like more discussion is warranted to nail down the property value’s default behavior and how it renders.
I am using the from-font value on my personal site for the link underlines in the articles, and I think it works great. The line is subtle, but it still communicates the interaction.
I look forward to seeing more options for the text-decoration-thickness in the future.
The advent of block themes delivers more creative power into the hands of users, but there are times when theme authors may want to lock down key elements of a design and its designated content areas. First introduced in Gutenberg 11.6, the upcoming WordPress 5.9 release will include a new API for locking blocks.
Template level locking has been available in Gutenberg for a few years, allowing developers to lock the template on the UI so that users can’t manipulate the blocks. This new API offers more granular control that can be applied on the block level and override template locking.
“Instead of applying a lock to all inner blocks, you can apply it selectively to individual blocks via the lock attribute,” Marcus Kazmierczak said in the dev note. “The block level locking would supersede the inherited templateLock value. You can choose to lock moving or removing a block.”
One of the primary use cases for locking individual blocks, cited in the ticket proposing the new API, is where one might lock the “post-content” block of a single template so users can’t remove it.
“Another use case that we’re building for is having a Checkout Block with different blocks that act as fundamental steps, we don’t want people to delete or move those steps since they’re fundamental and their order is also important, but we want to allow people to select them, access settings, and insert blocks in between them,” WooCommerce engineer Seghir Nadir said.
Kazmierczak’s dev note demonstrates how developers can lock a specific block in a pattern and explained how block level locking is not inheritable.
“If a block is locked from being removed, its children can still be removed,” Kazmierczak said. “If you want to apply locking on children as well, add templateLock to the inner block component, or templateLock attribute to supporting blocks.”
For more information on the new locking mechanism, check out the Block Editor Handbook and the code examples in the dev note.
I was killing some time browsing my CodePen feed for some eye candy and didn’t need to go past the first page before spotting a neat CSS hover effect by Adam Argyle.
I must’ve spent 10 minutes just staring at the demo in awe. There’s something about this that feels so app-like. I think it might be how contextually accurate it is in that the background color slides in from the left, then exits out through the right. It’s exactly the sort of behavior I’d expect from a mouse-in, mouse-out sort of interaction.
Whatever the case, I fired up a fresh pen and went to work recreating it. And it’s not super complex or anything, but rather a clever use of transitions and transforms paired with proper offsets. Quite elegant! I’m actually a little embarrassed how long it took me to realize how the mouse-out part works.
Here’s how I tackled it, warts and all.
“I bet that’s using a transition on a background.”
That was my first thought. Define the background-color, set the background-size and background-position, then transition the background-position. That’s how I’ve seen that “growing” background color thing done in the past. I’ve done that myself on some projects, like this:
If I could do the same thing, only from left-to-right, then all that’s left is the mouse-out, right? Nope. The problem is there’s nothing that can really make the background-position transition from left-to-right to left-to-right. I could make it do one or the other, but not both.
“Maybe it’s a transform instead.”
My next attempt was jump into transforms. The transform property provides a bunch of functions that can transition together for slightly more complex movement. For example, the background can “grow” or “shrink” by changing the element’s scale(). Or, in this case, just along the x-axis with scaleX().
But like I mentioned, there isn’t a way to isolate the element’s background to do that. Going from scaleX(0) to scaleX(1) scales the entire element, so that basically squishes the link — content and all — down to nothing, then stretches it back out to its natural size which is a totally different effect. Plus, it means starting with scaleX(0) which hides the whole dang thing by default making it unusable.
But a pseudo-element could work! It doesn’t matter if that gets squished or hidden because it isn’t part of the actual content. Gotta put the background on that instead and position it directly under the link.
a {
/* Keeps the pseudo-element contained to the element */
position: relative;
}
a::before {
background: #ff9800;
content: "";
inset: 0; /* Logical equivalent to physical offsets */
position: absolute;
transform: scaleX(0); /* Hide by default */
z-index: -1; /* Ensures the link is stacked on top */
}
“Now I need ::before to change on hover.”
I knew I could make ::before scale from 0 to 1 by chaining it to the link element’s :hover state.
a:hover::before {
transform: scaleX(1)
}
Nice! I was onto something.
Sprinkle a little transition fairy dust on it and things start to come to life.
Again, this is where I sorta got stuck. Something in my head just wasn’t clicking for some reason. As per usual, I ran over to the CSS-Tricks Almanac to see what property might’ve slipped my mind.
Ah, yes. That would be transform-origin. That allows me to set where the transform starts, which is not totally dissimilar from setting the background-position like I tried earlier. The transform could start from the left instead of its default 50% 50% position.
I was already transitioning ::before to scaleX(1) on link hover. If I reversed the transform-origin from left to right at the same time, then mayyyybe the highlight goes out the opposite of how it came in when the mouse exits?
Are you seeing the ‘Comments are closed’ message on your WordPress posts?
This message is displayed when comments have been disabled on a post. However, some users report seeing the message unexpectedly.
In this article, we’ll show you how to fix ‘Comments are closed’ in WordPress.
What Is the ‘Comments Are Closed’ in WordPress Error?
The comment area of your WordPress blog allows your website visitors to give feedback, ask questions, offer their own point of view on the topic, and respond to other comments.
Comments are disabled on all WordPress pages by default, and you won’t see the ‘Comments are Closed’ message on pages. However, you can still follow the steps below to open comments on your pages as well as posts.
For blog posts, you can disable comments on specific posts or on your entire WordPress website. For example, you may wish to disable comments on an announcement post.
When you disable comments on a post that has at least one comment, you will see the message ‘Comments are closed.’ This explains to your visitors that even though there are comments on the post, no further comments can be left.
If you disable comments on a post that has no comments, then you won’t see the ‘Comments are closed’ message. WordPress will simply not display the comment form.
Perhaps you’re seeing the ‘Comments are closed’ message on your website unexpectedly. While WordPress is easy to use, some error messages can be hard to troubleshoot for beginners. That’s why we put together a list of the 50 most common WordPress errors and how to fix them.
This message is most likely being shown because of a WordPress setting that’s not configured correctly. That’s because WordPress has comments settings in multiple areas, which can make it hard for beginners to find the right settings to fix the problem.
In this post, we’ll walk you through all the settings you should check in order to reopen the comments on your blog posts.
With that being said, let’s look at how to fix ‘Comments are closed’ in WordPress.
Comments are often closed on a WordPress site because at some time in the past a setting was checked was that disables comments on new posts by default.
You can check this setting by navigating to Settings » Discussion. Here you’ll find a set of checkboxes that control how comments are handled on new posts.
The first setting to look at is ‘Allow people to post comments on new articles’. This box should be checked so that the default setting for future posts is to allow comments.
Next, look at ‘Automatically close comments on articles older than XX days’. This setting is useful if you don’t want users to be able to comment on older posts. However, if you want to allow comments on all posts, then you should make sure this box is unchecked.
Once you’re happy with the discussion settings, make sure you click the ‘Save Changes’ button at the bottom of the screen to store the settings.
This will make sure comments are open on all new posts you create. But it will not enable them on posts that have already been created.
That’s what we’ll do in the next step.
Enable Comments on a Specific Post
This method will show you how to enable comments on existing posts one at a time. However, if you wish to enable comments on many posts, then you should follow the ‘Enable Comments in Bulk’ method that we cover below.
If you use the block editor on your WordPress site, then you need to scroll down the settings pane on the right of the screen until you come to the Discussion panel.
Now you should click on ‘Discussion’ to expand the options, and then make sure the ‘Allow comments’ box is checked.
Once you click the Update button at the top of the screen to save the setting, comments will be enabled for this post.
You should repeat these steps to enable comments on other blog posts. You can also follow the same process to enable comments on WordPress pages.
How to Display the Discussions Panel if It Is Hidden
While the Discussions panel is displayed by default, it may be hidden on your website. If you can’t find it, then you will need to click the Options icon at the top right of the screen. This icon looks like 3 vertical dots.
You then need to click on ‘Preferences’ and navigate to the ‘Panels’ tab. Once there, you can toggle the ‘Discussions’ switch on so that the panel is displayed.
Enable Comments on a Specific Post (Classic Editor)
If you are using the classic editor, then the steps for enabling comments on a post are a little different. Here, the Discussion meta box is hidden by default. To display it, you will need to click on ‘Screen Options‘ at the top right of the screen.
Next, you should check the Discussion box under ‘Screen elements’. After that, simply click ‘Screen Options’ again to return to your post.
You can now scroll down to the bottom of your post where you will find the Discussion meta box. You should make sure the ‘Allow comments’ box is checked.
After you click the Update button to save the setting, comments will be enabled for this post.
Enable Comments on Posts in Bulk
If you need to enable comments on multiple posts, then you can update them in bulk. To do that, navigate to the Posts » All Posts page where you will find a list of all of your posts.
You need to select the posts that have comments disabled by clicking the checkbox next to each post.
After that, you should choose ‘Edit’ from the Bulk Actions dropdown box and then click the ‘Apply’ button. This will open the bulk edit screen.
Here you need to click the ‘Comments’ drop down menu and then select ‘Allow’.
Don’t forget to click the ‘Update’ button to change the setting for all selected posts.
How to Select All Posts At Once
If you want to enable comments for every post on your website at once, then following the steps above would take a lot of time if you have hundreds of blog posts on your site.
To do it faster, there are a few extra steps you should take. First, you will need to make sure that all posts are displayed on a single page.
You can see a count of all the posts on your website under the ‘Posts’ title at the top of the screen. If you have 20 posts or less, then they are already displayed on one page. If you have more than 20 posts, then you will have to increase the number of items per page.
To do that, you should click ‘Screen Options’ at the top of the page. Then, under Pagination, find the ‘Number of items per page’ setting. Here you will need to type a number larger than the total number of posts on your site.
For example, if you have 65 posts on your website, then you could type the number 70.
After that, you need to click the ‘Apply’ button and all of your posts will be displayed on one page. You can now click ‘Screen Options again to hide the settings.
You can now select every post on your site by simply clicking the checkbox next to ‘Title’.
To enable comments on all of these posts, you should click ‘Bulk Actions’ then ‘Edit’, and follow the steps we covered earlier in this section to change the Comments setting to ‘Allow’.
Note: We don’t recommend trying to update hundreds of blog posts at once if you have slow web hosting, since your site may time out or freeze up before completing all the updates.
Check for Incompatible Themes or Plugins
If you have tried all of the steps above and comments are still disabled on your site, then it may be because of an incompatibility with your theme or one of your plugins.
Sometimes poorly coded WordPress themes may wrongly display the ‘Comments are closed’ message even when comments are open.
To check if your theme is the problem, you should navigate to Appearance » Themes and temporarily activate some other theme.
If the ‘Comments are closed’ message is now fixed, then your theme is the problem. You can ask the theme developer to fix the issue. For more details, see our guide on how to properly ask for WordPress support and get it.
Alternatively, if you’re an advanced user, then you can try to fix the issue yourself. You need to refer to our guide on how to disable comments in WordPress, and then follow the instructions under ‘Remove “Comments Are Closed” in WordPress’.
If you think a plugin may be causing the issue, then you can head over to Plugins » Installed Plugins and make sure you haven’t installed a plugin designed to disable comments, such as Disable Comments. If you have, then simply disable that plugin and test to see if comments are now working.
If comments are still closed, then you need to test for incompatible plugins. You’ll need to temporarily deactivate one plugin at a time by clicking its ‘Deactivate’ link.
Now test to see if comments are enabled on your site. If they are still not working, then this plugin is not the problem. Simply click its ‘Enable’ link and move on to the next plugin.
Lea Verou made a Web Component for processing Markdown. Looks like there were a couple of others out there already, but I agree with Lea in that this is a good use case for the light DOM (as opposed to the shadow DOM that is normally quite useful for web components), and that’s what Lea’s does. The output is HTML so I can imagine it’s ideal you can style it on the page like any other type rather than have to deal with that shadow DOM. I still feel like the styling stories for shadow DOM all kinda suck.
The story of how it came to be is funny and highly relatable. You just want to build one simple thing and it turns out you have to do 15 other things and it takes the better part of a week.
Huh! I did not realize that CSS custom properties had their own resolution behavior for how !important works in their values. Uh, despite writing a guide about them. 😬 But hey it’s now updated.
div {
--color: red !important;
color: var(--color);
color: yellow;
}
It kinda feels like red should win, but because !important is ultimately stripped from the custom property value, yellow wins it out. And it’s not because the color declaration comes last — if color: red !important; was the first declaration, then red would win.
But it’s not like !important is just stripped and ignored; it’s used in a scoped way, affecting which custom property value wins. But then !important is gone when that value is applied. Stefan’s example:
div {
/*
`!important` overrules the
other `--color` definitions
*/
--color: red !important;
color: var(--color);
}
.class {
--color: blue;
}
#id {
--color: yellow;
}
This feels weird (to me) as you’d think yellow declared on #id would win because it has the highest specificity. But that’s the deal with the scoped behavior — !important makes red the winner, then is applied to the color as such.
I was reading Jake’s “Cross-fading any two DOM elements is currently impossible” which is a wonderfully nerdy deep dive into how there is no real way to literally cross-fade elements. Yeah, you can animate both of their opacities, but even that isn’t quite the same. Turns out there is a Chrome/WebKit-only CSS function call called -webkit-cross-fade() that does the trick. MDN says it’s specced, but the implemented version differs, so it’s a bit of a mess… but it does exist:
The first thing I thought of was: if one of the images was just a blank transparent image, wouldn’t that apply partial transparency to the other one? And thus it’s kind of a proxy for background-opacity (which doesn’t exist but feels like it should).
It doesn’t work in Firefox but it does in everything else. Plus, you can test for support right in CSS and do something different if this isn’t just an enhancement.
@supports (background: -webkit-cross-fade(url(), url(), 50%)) {
/* Only apply the idea if supported, do the Firefox fallback outside of this */
}
Upon hearing “sticky footer” these days, I would think most people imagine a position: sticky situation where a footer element appears fixed on the screen while in the scrolling context of some parent element.
That’s not quite what I’m talking about here. “Sticky footers” were a UI concept before position: sticky existed and they mean something slightly different. The idea is that they stick to the bottom of the screen, even when the content of the page isn’t enough to push them there. But if there is enough content, they are happily pushed down.
We covered five ways to do this in years past, which included techniques that are somewhat modern, including calc(), flexbox, and CSS Grid.
Enter a sixth challenger! Reader Sílvio Rosa wrote in with this:
(Probably easiest to check out on a medium-sized desktop screen, which is kinda where sticky footers matter the most anyway.)
It’s pretty much just this:
html, body { height: 100%;}
body > footer {
position: sticky;
top: 100vh;
}
What I like about it is that it doesn’t require any special extra wrapper for non-footer content.
It’s also a little brain-bending. When I see top: 100vh; I think well that won’t work because it will push the footer outside the viewable area. But that’s the clever bit. It will do that no matter how big the footer is (no magic numbers), and then the sticky positioning will “suck it back up” to stick along the bottom edge. But it will never overlap content, so it’s happy to be pushed down below content, which is a core tenant of the sticky footer pattern.
Bonafide CSS trick alert! Nelson Menezes figured out a new way (that only works in Firefox for now) that is awfully clever.
Perhaps you know that CSS cannot animate to auto dimensions, which is super unfortunate. Animating from zero to “whatever is necessary” would be very helpful very often. We’ve documented the available techniques. They boil down to:
Animate the max-height to some more than you need value, which makes timing easing imprecise and janky.
Use JavaScript to measure the final size and animate to that, which means… using JavaScript.
Nelson’s technique is neither of those, nor some transform-based way with visual awkwardness. This technique uses CSS Grid at its core…
Unbelievably, in Firefox, that transitions content inside that area between 0 and the natural height of the content. There is only a little more to it, like hiding overflow and visibility to make it look right while maintaining accessibility:
That’s wonderful. Let’s get some stars on this issue and maybe Chrome will pick it up. But of course, even better would be if auto height transitions just started working. I can’t imagine that’s totally outside the realm of possibility.
The go/no-go deadline for deciding on features for WordPress 5.9 was set for October 12 but the conversation was pushed back two days. Today, the core leadership for this release announced that everything in the previously-proposed scope for 5.9 will be moving forward.
Users can expect block themes, template and template part editing flows, the new default Twenty-Twenty Two block theme, the Styles interface, design tools, the Navigation Block, all manner of UI improvements, and pattern insertion directly from the Pattern Directory. Héctor Prieto, who is assisting with technical project management on the release, emphasized that many of these features are still in progress:
To note, not all of the above are currently ready, but there is some level of confidence that they can be by the time of 5.9.
A new WordPress 5.9 Must-Haves project board on GitHub shows a broad overview of the issues contributors are focusing on to get the release ready.
Prieto also published an exhaustive transcript of the meeting. There were no strong objections on specific features moving forward but there seemed to be a general acknowledgment that some features are still in a beta state. Those present at the meeting agreed that some kind of beta label might be advantageous where users could be directed to the Gutenberg plugin for faster updates to features that are still not fully polished.
One particularly challenging feature has been navigation. “I think from my perspective, the thing I was a bit worried about was the navigation menu flows, which I think we did a lot of progress over the last few weeks,” Gutenberg lead engineer Matías Ventura said. “And I think we need to set some good boundaries there.
“There has been a lot of work in also supporting sort of mega menus where you have in your sub-menus, you have images and paragraph any sort of block, which is cool. But there’s also like the 80% of cases where you just have a few links, and we need to ensure that that experience is as best as we can make it. I think we’re in a better place. And I think we’ll get there.”
Beta 1 is expected November 16, and the official release is scheduled for December 14. If you want to see an early demo of WordPress 5.9, check out the recording of the meeting below:
By default the Gutenberg Block Editor loads its default CSS/stylesheet on the front-end of your WordPress site. This is fine for most cases, but there may be situations where you want to disable the Gutenberg styles for whatever reason. For example, my free WordPress plugin, Disable Gutenberg, enables users to disable the Gutenberg Block Editor and restore the Classic Editor. Included in the plugin settings is an option called “Enable Frontend” that lets users enable or disable the Gutenberg CSS/styles as desired. This quick DigWP tutorial explains programmatically how to disable Gutenberg styles on the front-end.
Bonus: Disable Gutenberg plugin also enables restoring of Classic Widgets!
Why?
One reason why people may want to remove extraneous/unnecessary CSS/stylesheets from loading is improved site performance. So by disabling the Gutenberg CSS when it’s not needed, that’s one less asset that needs to load for every page request. That can have a huge cumulative effect on the performance of your WordPress site.
FYI the default Gutenberg stylesheet looks like this when included in the source code of your web pages:
Without further ado, here is the magic code snippet sauce to add to your WordPress-powered site. You can add this code using a plugin such as Code Snippets, or you can add directly via theme (or child theme) functions.php, or add via simple custom plugin. Many ways to add the following code:
This script disables the default Gutenberg stylesheet wp-block-library, and it also disables the theme-specific Gutenberg stylesheet (if applicable) wp-block-library-theme. That’s all it does, plain and simple.
Note: To re-enable the Gutenberg styles, simply remove the above code snippet.
Bonus: Disable other block stylesheets
In general, any WordPress stylesheet can be disabled using the WP core function, wp_dequeue_style(). For example, if you are using WooCommerce and the Storefront theme, you may want to prevent their related Gutenberg Block CSS/stylesheets from loading on the front-end. To do it, modify the previous code snippet so it looks like this:
The wp_dequeue_style() function is what’s doing all the work here. It is very effective and can be used to disable any stylesheet that is registered with WordPress. Check the docs at WordPress.org for more details.
One for the road..
The code techniques so far are kept very minimal for the sake of clarity. But as you probably know, there is much more that can be done when customizing asset loading and so forth. For example, you can add conditional logic so the stylesheets will be disabled only under certain conditions.
To give you an idea of the possibilities, here is a “real-world” example showing how Disable Gutenberg conditionally disables the front-end styles depending on user preference in the plugin settings.
Again this is just an example taken from an actively developed plugin. So much more is possible, as WordPress core provides all sorts of useful functions with which to work. So have fun and build something creative :)
Note: The above code snippet taken from the Disable Gutenberg plugin is for example purposes only; so don’t try to use it on any live site. Instead if you want to explore, download the plugin and examine the source code.
Viewing patterns from the WP Block Patterns homepage.
Andrew Starr, the owner of UXL Themes, has cobbled together a new project around block patterns. His new site, aptly named WP Block Patterns, allows users to preview any WordPress.org-hosted block themes and patterns together.
The project does not allow visitors to download anything or ask them to sign up. It is a basic demo system, one that WordPress.org should consider at some point.
Visitors can choose any block pattern. Then, they can select any theme to see what they look like together. It is a quick way to test patterns and themes without actually adding them to your WordPress installation.
For example, a user can view the Team Social Cards pattern — one that I had a hand in creating — along with Anders Norén’s Tove theme.
From Gutenberg Hub’s landing page templates to EditorsKit’s ShareABlock collection, the block system has allowed developers to experiment with unique sites for end-users. Because everything is built upon a standard, I am guessing we will see even more of these creative projects in the future. WP Block Patterns is another step in that journey.
This was not always the plan for the WP Block Patterns site. Starr set out to blog about patterns after their feature release in WordPress 5.5. After only publishing a single post, the project fell to the wayside. Fortunately, inspiration struck.
“I have a site that I use as my reference point when providing support for my themes,” he said. “This site has a blend of varying content and code that allows me to quickly switch/preview any of my themes, without the need to actually change the active theme in the admin, or maintain a different site for every theme.”
In the process of making improvements to his theme-switching functionality, the domain came up for renewal. He had planned to let it expire but decided to see if he could come up with something to do with the site.
“I got the inspiration to use the theme switcher in conjunction with content from block patterns,” said Starr. “If I hadn’t been working on my script at the same time as I coincidently received the domain expiration message, I probably wouldn’t have had this idea.”
Currently, he is manually installing the themes on the site but may have to automate it in the future as more block themes are released. However, he is pulling patterns and categories directly from the WordPress.org API, which is periodically updated.
The site only showcases 100% block themes. Technically, it should work with any that supports editor styles. Starr said it had never crossed his mind to showcase non-block themes.
“I have been keeping my eye on the releases of FSE themes, checking out every block theme that I come across, and it just sort of seems that block themes are the future, and classic themes feel like a step backwards now after investing so much time working with block themes,” he said. “The site would work just fine with classic themes, but there are so many available I’m not sure how to make it manageable or select which themes to feature (and which ones to leave out). I guess that’s also something I’ll have to think about as the number of block themes increases.”
Thus far, Starr has released two block themes, Hansen and Pria, through his UXL Themes brand. Users can preview both via the site. However, he is already working on his next project.
“As a proof of concept, I am working on a classic theme that will have the functionality to also be a block-based theme when FSE is available in core,” he said. “The idea is that the user will not notice any front-end differences when the theme ‘switches’ from classic to block-based, but the user will gain the new FSE admin tools, with the user’s classic customizer modifications switched over intact to the new Site Editor. I have found that there are compromises that need to be made when getting classic and FSE to work together seamlessly in a single theme, so I am not sure whether this will be released generally.”
He also teased a project related to FSE that is neither a theme nor a plugin. However, he was not ready to share any details just yet.
Nick Diego released the Icon Block plugin last week. Unlike similar blocks that are available, it does not rely on a third-party library. Instead, it caters to the developer and DIY crowd, allowing them to add any SVG directly to the editor.
Diego is the author of the Block Visibility plugin, which is just a little over a year old and shaping up to be the best project in the space. Over the summer, he expanded it with a pro version that adds value with more niche options. When it comes to the block editor, he has thus far shown a willingness to find creative solutions to problems with a focus on a well-rounded user experience. His latest plugin seems to be no different.
Piecing together the pricing page for Block Visibility is what pushed him to create Icon Block. He had a massive feature list and was hand-coding the icons via the HTML block.
Block Visibility pricing table.
“I threw this little block together this week after becoming very annoyed at using HTML blocks for SVG icons (and not wanting to use a block library),” said Diego. “My goal was to build a simple SVG icon block using basically all native WP components. And as more functionality is added to core (margin, responsive controls, etc.), I will add them to the block.”
The result was a success. It checks a lot of boxes for such an icon solution that leans into the WordPress block system.
At its core, it allows end-users to copy and paste any SVG code into a text field and have it render in the editor and on the front end.
Adding a basic icon.
However, it does not stop there. It uses a range of core components and block-supported features to round out the solution. It supports must-have features like colors and alignment. Users can adjust the icon size, padding, and the border-radius while linking it to any URL.
One feature I want to see tacked on is a set of border style, width, and color controls. That is more of a nice-to-have extra than a priority.
Adjusting the icon’s colors, size, spacing, and border-radius.
Supporting core components would have been fine for a launch, but Diego took that extra step and added custom functionality. The Icon block has a “rotate” button that allows users to turn the icon in 90° increments. It also has buttons for flipping the icon horizontally and vertically.
There are tons of use cases for such icon plugins in the WordPress editor. One of the more common scenarios is a simple set of boxes with a graphic at the top.
Boxes with icons.
With Icon Block, this is simple enough to do by using the Columns block, dropping in custom icons, and customizing them. However, there is so much more that is possible.
The missing pieces are on WordPress’s end. Currently, there are not many robust solutions for building horizontal layouts. It makes it tough to align icons next to text.
The recently-added Row variation on the Group block shows promise. The experience is a bit fussy, but it is possible to place the Icon block next to a Paragraph, as shown in the following screenshot. I built a quick pricing table with check icons.
Pricing columns with icon list.
There is no way to control the spacing between items in each row from the interface yet. I wanted my icons a bit closer to the text.
The other issue is that this should be a list. There is no reason to repurpose other blocks to build the layout. However, the List block does not allow users to nest blocks.
These are not issues of the Icon Block plugin. It just shows a reasonably common use case that WordPress should make possible. This would make these types of plugins far more powerful.
There is support for an icon block to land in the Gutenberg plugin and, eventually, make it to WordPress. Gutenberg Project Lead Matías Ventura opened a ticket in 2019 to explore the idea of allowing users to insert SVGs directly into the editor. If this ever made it in, it would more likely be a visual selector that does not allow end-users to add custom code. Diego’s block might still exist as an alternative solution with more flexibility in that case.
While the plugin could serve as a perfect solution in its current form to a large share of the WordPress community, Diego has plans for improving it. He is considering adding an icon selector for users who do not want to add SVG code. By default, this would show the built-in WordPress icons. However, he also has plans to allow third-party developers to extend it with custom “icon packs.”
CSS ::before and ::after pseudo-elements allow you to insert “content” before and after any non-replaced element (e.g. they work on a <div> but not an <input>). This effectively allows you to show something on a web page that might not be present in the HTML content. You shouldn’t use it for actual content because it’s not very accessible in that you can’t even select and copy text inserted on the page this way — it’s just decorative content.
In this article, I’ll walk you through seven different examples that showcase how ::before and ::after can be used to create interesting effects.
Note that for most examples, I am only explaining the parts of the code that deal specifically with CSS pseudo-elements. That said, all of the CSS is available in the embedded demos if you want to see the code for additional styling.
Styling Broken images
When a user visits your website, their internet connection (or a factor beyond your control) might prevent your images from downloading and, as a result, the browser shows a broken image icon and and the image’s alt text (if it’s actually there).
How about showing a custom placeholder instead? You can pull this off using ::before and ::after with a bit of CSS positioning.
First, we need to use relative positioning on the image element. We are going to use absolute positioning on one of the pseudo-elements in a bit, so this relative position makes sure make sure the pseudo-element is positioned within the content of the image element, rather than falling completely out of the document flow.
img {
display: block; /* Avoid the space under the image caused by line height */
position: relative;
width: 100%
}
Next, let’s create the region of the broken image effect using the image’s ::before pseudo-element. We’re going to style this with a light gray background and slightly darker border to start.
<img> is a replaced element. Why are you using ::before pseudo-element on it? It wont work!. Correct. In this scenario the pseudo-element will show in Chrome and Firefox when the image fails to load, which is exactly what you want. Meanwhile, Safari only shows the styling applied to the alt text.
The styling is applied to the top-left corner of the broken image.
So far, so good. Now we can make it a block-level element (display: block) and give it a height that fills the entire available space.
We can refine the style a little more. For example, let’s round the corners. We should also give the alt text a little breathing room by giving the pseudo-element full width and absolute positioning for better control placing things where we want.
If you stopped here and checked your work, you might be scratching your head because the alt text is suddenly gone.
That’s because we set content to an empty string (which we need to display our generated content and styles) and cover the entire space, including the actual alt text. It’s there, we just can’t see it.
We can see it if we display the alt text in an alternate (get it?) way, this time with help form the ::after pseudo-element. The content property is actually capable of displaying the image’s alt attribute text using the attr() function:
The generated content is colliding with the actual alt text in Firefox.
A quick fix is to target the alt attribute directly using an attribute selector (in this case, img[alt]), and target similar styles there so things match up with Chrome.
Now we have a great placeholder that’s consistent in Chrome and Firefox.
Custom blockquote
Blockquotes are quotes or an excerpts from a cited work. They’re also provide a really great opportunity to break up a wall of text with something that’s visually interesting.
I want to look at another technique, one that incorporates ::before and ::after. Like we saw with the last example, we can use the content property to display generated content, and apply other properties to dress it up. Let’s put large quotation marks at the start and end of a blockquote.
Firefox 91
The HTML is straightforward:
<blockquote>
<!-- Your text here -->
</blockquote>
Note the position: relative in there because, as you’ll learn, it’s essential for positioning the blockquotes.
As you’ve probably guessed, we’re going to use ::before for the first quotation mark, and ::after for the closing one. Now, we could simply call the content property on both and generate the marks in there. But, CSS has us covered with open-quote and close-quote values.
blockquote::before {
content: open-quote;
/* Place it at the top-left */
top: 0;
left: 0;
}
blockquote::after {
content: close-quote;
/* Place it at thee bottom-right */
bottom: 0;
right: 0;
}
This gets us the quotation marks we want, but allow me to button up the styles a bit:
We have ordered (<ol>) and unordered (<ul>) lists in HTML. Both have default styling dictated by the browser’s User Agent stylesheet. But with ::before pseudo-element, we can override those “default” styles with something of our own. And guess what? We can use emojis (😊) on the content property!
While this is great and all, it’s worth noting that we could actually reach for the ::marker pseudo-element, which is designed specifically for styling list markers. Eric Meyer shows us how that works and it’s probably a better way to go in the long run.
The customization is all thanks to modifications added to the <input> element via the ::before and ::after pseudo-elements. But first, here is some baseline CSS for the <form> element:
We’re not quite there, but see how the checkbox element is displayed.
We’re going to “hide” the checkbox’s default appearance while making it take up the full amount of space. Weird, right? It’s invisible but still technically there. We do that by:
changing its position to absolute,
setting the appearance to none, and
setting its width and height to 100%.
input {
-webkit-appearance: none; /* Safari */
cursor: pointer; /* Show it's an interactive element */
height: 100%;
position: absolute;
width: 100%;
}
Now, let’s style the <input> element with its ::before pseudo-element. This styling will change the appearance of the input, bringing us closer to the final result.
input::before {
background: #fff;
border-radius: 50px;
content: "";
height: 70%;
position: absolute;
top: 50%;
transform: translate(7px, -50%); /* Move styling to the center of the element */
width: 85%;
}
Next, we need to create the “toggle” button and it just so happens we still have the ::after pseudo-element available to make it. But, there are two things worth mentioning:
The background is a linear-gradient.
The “toggle” button is moved to the center of the <input> with the transform property.
Try clicking on the toggle button. Nothing happens. That’s because we’re not actually changing the checked state of the <input>. And even if we were, the result is… unpleasant.
The fix is to apply the :checked attribute to the ::after pseudo-element of the <input>. By specifically targeting the checked state of the checkbox and chaining it to the ::after pseudo-element, we can move the toggle back into place.
We can decorate images with borders to make them stand out or fit more seamlessly within a design. Did you know we can use a gradient on a border? Well, we can with ::before (there are other ways, too, of course).
The core idea is to create a gradient over the image and use the CSS z-index property with a negative value. The negative value pulls the gradient below the image in the stacking order. This means the image always appears on top as long as the gradient has a negative z-index.
.gradient-border::before {
/* Renders the styles */
content: "";
/* Fills the entire space */
position: absolute;
top: 0;
left: 0;
bottom: 0;
right: 0;
/* Creates the gradient */
background-image: linear-gradient(#1a1a1a, #1560bd);
/* Stacks the gradient behind the image */
z-index: -1;
}
figure {
/* Removes the default margin */
margin: 0;
/* Squeezes the image, revealing the gradient behind it */
padding: 10px;
}
Gradient overlays
This is similar to what we did in the previous example, but here, we’re applying the gradient on top of the image. Why would we do that? It can be a nice way to add a little texture and depth to the image. Or perhaps it can be used to either lighten or darken an image if there’s text on top it that needs extra contrast for legibility.
While this is similar to what we just did, you’ll notice a few glaring differences:
See that? There’s no z-index because it’s OK for the gradient to stack on top of the image. We’re also introducing transparency in the background gradient, which lets the image bleed through the gradient. You know, like an overlay.
Custom radio buttons
Most, if not all, of us try to customize the default styles of HTML radio buttons, and that’s usually accomplished with ::before and ::after, like we did with the checkbox earlier.
Firefox 91
We’re going to set a few base styles first, just to set the stage:
::before should be positioned at the top-left corner of the radio button, and when it’s checked, we change its background color.
.form-input::before {
/* Renders the styles */
content: '';
/* Shows that it's interactive */
cursor: pointer;
/* Positions it to the top-left corner of the input */
position: absolute;
top: 0;
left: 0;
/* Takes up the entire space */
height: 100%;
width: 100%;
}
/* When the input is in a checked state... */
.form-input:checked::before {
/* Change the background color */
background: #21209c;
}
We still need to iron a few things out using ::after. Specifically, when the radio button is checked, we want to change the color of the circular ring to white because, in its current state, the rings are blue.
.form-input::after {
/* Renders the styles */
content: '';
/* Shows that it's interactive */
cursor: pointer;
/* A little border styling */
border-radius: 50px;
border: 4px solid #21209c;
/* Positions the ring */
position: absolute;
left: 10%;
top: 50%;
transform: translate(0, -50%);
/* Sets the dimensions */
height: 15px;
width: 15px;
}
/* When the input is in a checked state... */
.form-input:checked::after {
/* Change ::after's border to white */
border: 4px solid #ffffff;
}
The form label is still unusable here. We need to target the form label directly to add color, and when the form input is checked, we change that color to something that’s visible.
Click the buttons, and still nothing happens. Here what’s going on. The position: absolute on ::before and ::after is covering things up when the radio buttons are checked, as anything that occurs in the HTML document hierarchy is covered up unless they are moved to a new location in the HTML document, or their position is altered with CSS. So, every time the radio button is checked, its label gets covered.
You probably already know how to fix this since we solved the same sort of thing earlier in another example? We apply z-index: 1 (or position: absolute) to the form label.
.form-label {
color: #21209c;
font-size: 1.1rem;
margin-left: 10px;
z-index: 1; /* Makes sure the label is stacked on top */
/* position: absolute; This is an alternative option */
}
Wrapping up
We covered seven different ways we can use the ::before and ::after pseudo-elements to create interesting effects, customize default styles, make useful placeholders, and add borders to images.
By no means did we cover all of the possibilities that we can unlock when we take advantage of these additional elements that can be selected with CSS. Lynn Fisher, however, has made a hobby out of it, making amazing designs with a single element. And let’s not forget Diana Smith’s CSS art that uses pseudo-elements in several places to get realistic, painting-like effects.
Do you want to create short links to your WordPress blog posts or pages?
Short links are useful for sharing in your emails, Facebook messages, and even text messages.
In this article, we will show you how to generate short links using a plugin, and how to add the ‘Get Shortlink’ button back to the classic WordPress editor.
Why Create a Short Link in WordPress?
Sharing your web content on social media can build user engagement and bring new users to your website. But pasting in long links or URLs isn’t always the best way.
That’s because some social media platforms will limit the number of characters you can use. A shorter URL gives you extra space for more useful content, which can lead to more engagement and traffic to your WordPress website.
That’s why URL shortener services like Bitly and TinyURL were originally created. They take a long link and make it shorter so that it doesn’t take up as much space.
For example, if you’re using SEO-friendly URL structures, then you might have long URLs that look something like this:
Our short link for that post saves a lot of space:
http://wpbeg.in/b6xh7G
Note: We’re using a custom domain, wpbeg.in, for our short links, which is a bit more technical to set up and would require you to purchase another domain. We have a separate tutorial on how to create your own customized short URL.
In the past, WordPress made it easy to get a short link to your blog post or page. There was a Get Shortlink button located right next to the permalink area of the classic editor.
However, if you recently started your blog, then you will not see this feature on your WordPress site because it was removed after WordPress version 4.4. WordPress still creates the links, but the button has been removed.
Still, there are a few ways you can get short links for your WordPress posts and pages.
We’ll cover the best link shortener plugin, plus a couple of ways you can restore the ‘Get Shortlink’ button in the classic editor. Simply click the links below to jump straight to each option:
Method 1: Create Short Links Using the Pretty Links Plugin
We’ll start with a method that works for everyone. The Pretty Links plugin doesn’t rely on the classic editor and will create its own short link out of any URL.
It works with all links, including pages outside of your blog or website. So, besides letting you share your own content, it’s also the perfect tool for shortening affiliate links.
Note: There is a Pro version of Pretty Links with more powerful features like keyword auto-linking and link categories and tags, but for this tutorial we will be using the free version.
Once you activate the plugin, a Pretty Links section is added to your WordPress dashboard. To create your first short link, you need to go to the Pretty Links » Add Link page.
Next, you need to paste the original URL of the page you want to share into the Target URL text field. A short Pretty Link is automatically created, but you can customize it if you’d like to make it more readable.
Once you’ve created a few short links, you may not remember what they are all for. So it’s a good idea to type in the title of the web page and consider writing some notes of anything you need to remember.
Once you have filled in the Pretty Links form, click the Update button to activate the short link.
You will now see a list of all of your Pretty Links. To copy one to the clipboard, just click on the Copy icon at the right of the screen.
After that, you can paste it into any of your social media channels. Pretty Links will even keep track of how many clicks each link gets.
Upon activation, this plugin will automatically add the Get Shortlink button to the classic editor. To check that it worked, just edit any of your posts.
When you click the Get Shortlink button, it will show you the WordPress Shortlink for your post or page. You can copy the link to the clipboard so you can share it with your audience in your emails and messages.
Method 3: Creating a Short Link Button in the Classic Editor with Code
This method is for more advanced users and uses code rather than a plugin. It adds the Shortlink button to the classic editor by adding a custom code snippet to your theme’s functions.php file.
We don’t recommend this method to inexperienced users because if you make a mistake, then it could break your website. Method 2 above is a simpler way to achieve the same result without needing to use code.
Upon activation, the plugin will add a new menu item labeled Snippets to your WordPress admin bar. Clicking on it will show you a list of all the custom code snippets you have saved on your site.
Go ahead and click on the Add New button to add your first custom code snippet in WordPress.
This will bring you to the ‘Add New Snippet’ page.
You need to start by entering a title for your custom code snippet. Let’s call it ‘Short Link Button’. After you enter a title, simply copy and paste the code snippet below into the code box.
When you come across this snippet in the future, you may not remember what it’s for. So it’s a good idea to type something helpful in the description as a reminder.
You can also assign tags to your code snippet. This will help you sort your code snippets by topic and functionality.
Finally, you need to click on the ‘Save Changes and Activate’ button. Once the snippet is activated, the Shortlink button will be added to the classic editor.
Earlier today, theme.es released its Emoji Toolbar project to the plugin directory. It is a simple picker that integrates with the WordPress Rich Text toolbar, allowing users to insert emoji directly from the editor interface.
After Nick Hamze pulled his Emoji Conbini plugin from WordPress.org last year, there has been an emoji-sized hole in my editor toolbox. The plugin was the perfect implementation for quickly plopping a quick smiley face or any of the other thousands of characters available. Unfortunately, his departure from the WordPress space meant losing one of my favorite block-related plugins — and several others that I enjoyed.
It was also on par with 10up’s Insert Special Characters plugin, a solution for users missing a similar picker from the classic editor era.
Emoji Toolbar is filling that void and is a solid alternative for those who need a solution. The difference between the two implementations is the location. Emoji Conbini added the picker button directly to the toolbar, and Emoji Toolbar adds it to the “more” dropdown.
Clicking the Emoji button in the Rich Text toolbar.
Placing the picker button inside of the dropdown makes it a little harder to find. It also requires an additional mouse click to insert emoji. What matters is that the implementation works, but I would love to see it as a top-level toolbar item.
Using the plugin is a simple matter. When in a Rich Text field, which includes blocks like Paragraph, Heading, List, and more, the Emoji Toolbar appears in the block toolbar. After clicking it, the plugin creates a popup of the emoji picker.
Emoji Toolbar popup picker.
From that point, users merely need to click the emoji they want to insert into the post.
The plugin bundles the Emoji Mart library, which has quickly become almost a standard for emoji pickers. The component is a Slack-like box that categorizes each of the characters, and it provides a field for searching for that perfect emoji.
There is still at least one emoji inserter alternative. Instead of adding a picker to the block toolbar, Emoji Autocomplete Gutenberg allows users to type : and use keywords for inserting characters. For those who prefer to work from the keyboard, it is a quicker method.
Emoji Toolbar shines over Emoji Autocomplete Gutenberg and the now-retired Emoji Conbini based on how it formats its output. It inserts the actual characters into the content, but the other plugins insert an <img> tag instead. That method results in output that is not forward-compatible with any changes in the future or alternative libraries. Users who also prefer to disable image output on the front end cannot do so. This is a non-issue with Emoji Toolbar — it plays well with other solutions.
On the whole, the plugin is solid. It has well-written code and provides an easy-to-use picker for inserting emoji.
