The new WordPress editor, Gutenberg, comes installed by default from WordPress 5.0 version. It is an editor that radically changes the making of posts and pages of a website, being much closer to other visual editors. Now, a post or page is made up of content blocks. You have blocks for paragraphs, for images, for headers, for appointments, and much more.
This course is not intended to be a Gutenberg user manual. Its aim is to teach how to create new posts and web pages in a practical and efficient way. And that’s why over 2 hours of videos, divided into 20 lessons, you’ll learn to master WordPress editor environment. But you’ll also learn many details of the process we follow in Nelio when we write a new post or create a new page.
You will see how, thanks to the possibilities offered by this editor, you can design a large number of elements or sections that you can find in our web pages or any other professional website. You no longer need to be a designer to layout your content with skill and style. You can do it yourself with the catalogue of content blocks that WordPress includes by default.
The course is divided into 3 parts:
In the first part we will see the novelties that this editor brings us and the differences between the classic editor and the block editor. Get used to its new environment, its interface, and where to find the different toolbars, and learn the basic about the information and properties of the different blocks you can use.
Next we will see the process of writing a post, to which we will add the most common elements of blog posts: headings, images, paragraphs, lists, quotes, verses or videos. You’ll also learn tricks to master the editor and gain efficiency.
Also, as you know, before publishing any post you must make sure that you don’t forget the information needed to improve search engine rankings and its promotion on social networks. For that reason, we also explain how the new editor integrates with Yoast and Nelio plugins. And so you become familiar with the integration of any plugin with the editor too.
In page design lessons, you’ll learn the basic process to follow before you start creating any page of your website. And we’ll continue to see another new set of blocks that are particularly useful in page design: cover, media and text block, columns, design elements, image gallery, and widgets. For each of them, you will see practical and real examples that will serve as an idea on how to create new sections in your web pages. And you’ll even learn how to combine blocks in a way that nobody has ever explained before, opening a new range of design possibilities.
And of course, we will finish the design of the pages learning how to create and use reusable blocks, a feature that comes very handy to gain efficiency in the design of new pages.
Here is the list of lessons that make up the course:
All the lessons show practical and real examples for immediate application on your website.
I hate it when I waste my time doing the same tasks over and over again. That’s why we created Nelio Content, so neither you or I get stuck with boring stuff! Check it out!
Welcome to the third and last post on how to create a maps plugin for Gutenberg. Our last post was quite dense and we saw a lot of different things: the attributes our block has, how to insert a map using a React component, how to use WordPress components or even create our own components to define the user interface, etc. Today we’ll be discussing something simpler.
In this post we’ll see how to render the Google Maps map in the front-end. To do this, we will take a closer look at save.js and we will make a few changes to the plugin so that everything works as expected. I will also use this last post to comment on any point that may have been unclear until now.
How to Save Our Map Block to Display It in the Front-End
To display the map in the front-end we first have to define the HTML we want to be rendered in the front-end. In a Gutenberg block, this is achieved by defining the save method of the registerBlockType function. As I already mentioned in the previous post, this method is defined in the file save.js in packages/blocks/nelio-maps/.
Again, this is an extremely simple function to understand:
From line 7 to 25 we extract all the attributes that are relevant to our block. That is, all the attributes that we defined in attributes.js and that tweak the appearance of our map.
In line 41 we open the div that will serve as a container for the block.
In line 47 we find a div that will wrap the map itself. Look at something very interesting: this div includes all the attributes object in its definition. This means that all the properties in attributes (for example, 'data-lat': lat of line 34) will be rendered as HTML attributes (for instance, assuming that the variable lat is 2.48171, lat will appear in the final HTML as data-lat="2.48171").
On line 49, a small div is added containing the coordinates of the marker.
On line 59, the contents of the RichText that we had defined in edit.js.
So, in essence, the method save generates an HTML that contains all the attributes that are relevant to render a map in the front-end. So, what could go wrong? Well, if you were to open the front-end now, all you’d see would be this:
An empty block that only has some RichText content. What happened?
How to Modify the Plugin to Render a Google Map Created with our Gutenberg Block
To display a Google Map in the front-end it is necessary that we load the Google Maps library and a script that uses it to build the map itself. This is extremely simple and if you have ever developed for WordPress, you should know how to do it.
In line 9 we search all the nodes that contain a map (filtering by one of the classes that we have included in the save method) and, for each of them, we call the initGoogleMap method.
This method relies on two functions to do its job. On the one hand, it extracts the coordinates of a possible marker with the function extractMarkerPositionIfAny of line 55 and, on the other, it extracts all the properties of the map (center coordinates, zoom level, list of visible buttons, etc) with the function extractMapOptions from line 26. Note that both functions are simply dedicated to reading the values of the attributes data-something we had put into the save method.
Finally, we created a map (line 18) and added a marker (line 21) using the Map and Marker classes, respectively, provided by the Google Maps library.
Now that we have this script, we only need two additional tweaks in our project:
Once all these changes have been made, this is the final result:
I know what you’re thinking: why, instead of doing all this by hand, didn’t we use the React component we had used in edit.js? Wouldn’t this save some time?
Indeed, using the React component we saw in the previous post would have saved us some trouble… but there’s a catch: it relies on React, which means we would have had to load React in the front-end to use too. And that seems like too much, don’t you think?
Finally, let me briefly discuss one aspect that’s very important, or else your plugin won’t work: the Google Maps API Key.
One option would be to hardcode our API key in the plugin. If you’re the only one who’ll be using the plugin, that would do the trick. But if you plan on distributing your plugin to real users, it’s a very bad idea, because not all Google services are free—some are paid, and the costs can be quite expensive if everybody uses your key.
What to do in these cases? The idea is very simple: just add a configuration option in the plugin for people to enter their own API key.
In our case, if you add a map without API key, you will see the following warning message:
urging you to add the API key.
Usually, you’d create a special page to manage your plugin’s settings. But for a plugin as easy and simple as the one we’re creating, I thought it be easier if we opted for a different solution.
In WordPress there is an options screen in /wp-admin/options.php that looks like this:
It is a kind of “nice interface” to edit (almost) all the options that have been registered in WordPress and are in the table wp_options. So, all our plugin has to do is make sure that this option always exists in the database (even when there’s no API key set yet) and we will have a “nice interface” for the user to paste their API key without our doing anything!
To achieve this, use the init hook (see line 73 of this commit) with a function (line 134) that always sets a value to your key option. If the option does not exist yet, this function will set its value to the default value (an empty string) and save the option. If it already existed, the new value will be the same we already had, and so the update function won’t do anything. A clever and efective hack!
In this post we have overcome the last barrier in our project: how to save the map and how to display it in the front-end. Basically, all we needed was a div with all the relevant information about the map (its center, options for displaying the buttons, the marker, etc.) and a small scriptto rebuild it in the front-end.
I hope that this tutorial has pleased you and serves as an example to undertake your own projects. As you can see, if you start a new project with a good foundation like the one we have created in Nelio with the boilerplate for Gutenberg development, materializing your ideas into real projects will be way easier.
If you have any questions, let us know in the comments section below. Good luck!
The next step is to work out the best way to keep customers on your website to eventually make that all important conversion. By using Nelio A/B Testing you can quickly identify the best strategy for your different customers in each country. You can use Nelio A/B Testing to test your content, themes, widgets and pretty much anything else to see what works best for who.
Why You Need to Translate Your Website for International Clients
When your clients are browsing your website you want to give them as many reasons as possible for them to make a purchase. Equally, you want to avoid giving them an excuse to not buy your product. A low hanging fruit which achieves both of these aims is translating your website to their native language.
Translating your website will build customers’ trust in your company as well as ensuring they feel comfortable using your pages. 72% of customers prefer to use their native language when shopping online. And while you might think the price is an important factor in making a purchase, 56% of consumers say that obtaining information in their own language is actually more important to them.
Clearly, one of the quickest and easiest ways to get customers on your side is by speaking their language.
Why Use WPML to Translate Your Website
WPML takes care of everything a business website needs to translate its website and welcome new clients:
Localize your website – You can use WPML to not only translate your content but to change your currency, translate all strings (site’s taglines, admin texts etc) and many other features. For example, Zespoke uses WPML to translate from English to German and change the currency from pounds to euros.
Quicker and higher quality translations – With WPML’s Advanced Translation Editor, you can translate content in less time than ever and more accurately.
Multilingual SEO – WPML will ensure you rank highly on Google searches in other languages by updating Hreflang links, organizing your languages on different pages and facilitating high-quality translations.
Partnership with major translation services – WPML is fully integrated with major translation services around the world. This means they are able to provide your high-quality translations quickly and pain-free.
Compatible with plugins – From Yoast to Elementor, WooCommerce and many others, WPML works seamlessly with the plugins which you need to run your business.
Why A/B Testing Is Important For Your Business
Once you have translated your website you are still left with an important question. How do I know what content will actually increase my sales in a particular country? The best way to find out is through A/B testing.
Despite the A/B testing myths you might have heard, A/B testing is a risk-free way to try out different marketing and advertising methods to see which one is the most effective with your particular audience. Perhaps you need to change your headings? Or you need a different theme? Or simply a different image? With A/B testing you can test all of these out and more.
By split testing, you can use your data to your advantage. You can add changes, measure the results and better understand what works and doesn’t work with your customers. The end result is increased conversions.
Why Use Nelio For Your A/B Testing
If you are using WordPress for your business then Nelio A/B Testing is the best way to increase your conversions through split testing.
Test everything: Whether it’s pages, posts, custom types, widgets, themes, heatmaps or anything else you can test it with Nelio A/B Testing.
Do everything on WordPress: By using Nelio you can carry out all of your testings without having to leave the WordPress admin.
Compatible with WordPress hosting providers: Nelio’s flexibility means you can use it with the most popular hosting providers including WPEngine, Kinsta and Pagely.
Instant updates: As soon as you find your winning formula you can automatically update your pages.
How WPML and Nelio A/B Testing Work Together
You can combine WPML and Nelio A/B Testing to split test your translated pages. The best part is it’s as easy as split testing a non-translated page.
Let’s imagine that you have a real estate website in English which you have translated into French. You now want to see which headline works best on your French translation.
Here is one of our real estate posts in French:
On your WordPress dashboard, all you need to do is:
1. Head to the French language section of your website by clicking the French flag.
3. In the Nelio A/B Testing -> Experiments click Add New and then Add custom post type experiment.
4. Fill out the basic information for your Experiment including the Name, Custom post type and Original custom post.
5. We now want to create an alternative page for our French real estate page. We will add a Name for the alternate page, add the Source (the link to the original page) and then click Create to create our new page
6. Once we name our page, we can click Save Experiment and edit content to start editing it.
7. We can now change the title of our testing page. Let’s try Maison contemporaine avec piscine.
8. Now that you have defined your experiment and created your page, you can head to Experiments find it and click Start.
Now that our test is up and running we can keep track of our results in the Dashboard.
Try WPML and Nelio A/B Testing Together
You can now try WPML with Nelio A/B Testing out for yourself. Download WPML today to start the process of welcoming new customers from around the world.
Have you already used both plugins to A/B test your translated pages? Let us know how it went in the comments below!
Did you know that we’re only three people here at Nelio? And, yet, our posts are pretty cool, huh? That’s because of our new plugin, Nelio Content! Do you want to use it too?
Hi there! We’re back with our tutorial to develop in Gutenberg. Last week we started a project that added a map block in WordPress. In that first post we defined what the requirements that our plugin has to meet were and we prepared the skeleton of what will end up being the final product, starting with the fantastic plugin boilerplate that we have created at Nelio.
Today comes the second part of the tutorial on how to create the map block. In this post we will see how to add a Google Maps map inside the WordPress editor and how to implement a user interface that allows us to manipulate its behavior.
A Quick Look at the Current Status of the Project…
In the current state of the project we have a simple Demoblock defined in packages/blocks/demo/. This small block is the one that comes as an example in Nelio’s plugin boilerplate and looks like this:
Obviously, this isn’t what we want. We’re not interested in a heart icon followed by some text, but in something like this:
That is, we want a Google Map block with an optional marker in it. How can we move from the original example block that our boilerplate had to this other, more powerful block? Well that’s what we’re going to answer today!
But before that, let me invest a couple of minutes explaining what we have right now and how we’re going to move forward. I think that, if you understand the current state of the project, you’ll have an easier time following what will come next.
Understanding the Demo block…
As I’ve already said, the demo block is defined in packages/blocks/demo/. In this folder you’ll find the styles of the block, its icon, and several files with the code that implements its operation. Let’s see the most important files.
On the one hand, there’s the main file: index.js. This file exports three variables: the name of the block (name), the definition of the block (settings), and the styles that the block supports (styles). These three variables are those used in packages/blocks/index.js to register the block in Gutenberg (with registerBlockType) and thus make it available to final users.
The attributes.js file defines all those properties of our block that are dynamic and, therefore, should be tweakable by our users. In the case of our Demo block, the only attribute that exists is the text the user has written, but the map block will have many more options: the coordinates of the center of the map, the default zoom level the map should use, what buttons (if any) should be visible to interact with the map, etc.
The file edit.js is the one that defines how the block is displayed in the WordPress editor and what settings are offered to the user (both in the toolbar and in the sidebar of the block’s settings). In Demo, the edit simply includes the RichText component of WordPress to write the content. As we will see, the map block will be more complex and will also include additional settings.
Finally, save.js defines the method that will convert the block we were editing in Gutenberg into the HTML that must be rendered in the front-end. Again, in Demo we see that this function simply saves the contents of a RichText using RichText.Content, but it could be anything else (as we will see next week in the third and last part of this tutorial).
Creation of the Map Block Based on the Demo Block Included in the Plugin Boilerplate
Once we understand exactly how the Demo block works, it’s time to ask ourselves: how do we create ours? Well, very easy: as Toni told us a few days ago, we simply have to duplicate the directory packages/blocks/demo/ into packages/blocks/nelio-maps/ and start to modify everything necessary. I know, it’s easier said than done.
Let’s start with something easy: attributes.js. This file contains all the properties that should be modifiable by our final users. In the previous post we specified what requirements our plugin should meet and, therefore, we outlined what things should be tweakable. Well, taking a look at the resulting attributes.js you’ll clearly see what can be tweaked from our map block: zoom level, map center, visibility of different buttons… Super simple stuff!
The next point to modify is all that concerns the edition of the block in Gutenberg. To do this, we must dive into edit.js. If you look closely, you will see that it is not much more complicated than what we had in our original Demo block.
The most important thing is in the block’s render method (line 33), where we retrieve the attributes we just defined from an object named this.props. We’ll use this properties to render the block and its setings, of course. This is what we have:
A toolbar ToolbarControls (line 66), which we defined in an external file named toolbar.js (don’t worry, we’ll see its content in a minute).
The block settings that appear in the editor’s sidebar (line 68), which we find in a component called Inspector that we defined in inspector.js.
The content of the block itself, which has two states:
If I do not have a Google Maps API key available, we show a user notice (line 122).
If we have this key, we show the map using MapBlock (line 83). The map might include a Marker (line 97), which is only visible when the option is activated, and might also be accompanied of a div (line 104) with additional information about it.
Google Maps as a React Component
If we want to put a Google map in our editor, we must use a component that allows us to use the Maps API of Google Maps. Considering that Gutenberg is built on top of React, the logical thing to do is to find out if there’s a React component of Google Maps. And, sure thing, there’s one!
As you can read in the project’s documentation, first we have to add the component into our project. Just install and add the dependency running the following command:
How to Create a WordPress Component that Encapsulates a React Component
If we continue looking at the documentation of this React project for Google Maps, we will see that they recommend us to wrap their GoogleMap component with our own component. Once it’s encapsulated, we will have to use our component in our plugin.
How to Add Block Settings in WordPress Editor’s Inspector
The next step is to configure how this map should look in the editor and add a few settings to tweak its appearance. To do this, we must add several settings sections in the Gutenberg sidebar. As I have already advanced, we achieve this with a component that we have called Inspector and that we have defined in the file inspector.js.
If you take a look at this file, you will see that it follows the same pattern as always: we are defining a Component with a render method. This method pulls the relevant attributes in this.props and returns the JSX with all the controls. In this particular case, it returns an instance of InspectorControls (this tells WordPress that this content goes to the sidebar) with several PanelBody sections. Let’s see each section in detail.
Basic Map Settings
The first PanelBody we found (line 47) has no title and, therefore, always appears as a section that can not be closed:
The section defines a pair of RangeControls, whose result you can see in the previous screenshot. These two controls allow us to modify the height of the map and its zoom level.
Another interesting and simple section is the one found on line 121. Here we add a few options to activate or deactivate the buttons that should be shown on the map when displayed in the front-end :
To do this, we simply have to use the default WordPress component CheckboxControl.
How to Add a Custom Style Section for Our Map Block
Another interesting section of our block is the style section (line 68). You can see the final result in the following screenshot:
When the user selects any of the styles included in ImagePicker, the MapStyles component invokes the onChange function it’s been given (see line 76 of inspector.js) passing two values: the name of the selected style and the associated JSON.
Finally, notice that one of the options that MapStyles includes is a Custom style:
The next section we have is the one that controls our marker (line 81). This section allows us to show or hide the marker (line 86) and, when active, gives us some additional settings:
As you see, a search box appears to search for locations in Google Maps (which we have implemented, again, with a custom component called AddressSearch) and the ability to show or hide the text block in which to put additional information about the marker .
By the way, notice that the AddressSearch component is based on a component called StandaloneSearchBox, which is also part of the React project . What a pleasure it is to reuse the work of others!
How to Configure the Toolbar of a Block
The last thing we have to discuss is the toolbar. If you have understood how the sidebar works, the toolbar is a piece of cake.
The toolbar of our plugin is represented by the ToolbarControls component defined in toolbar.js. Here we simply add a component to define the alignment of the block (BlockAlignmentToolbar, on line 42), a pair of dropdowns to center the map (line 50) and to modify the location of the marker (line 79), and a couple of extra buttons to change the location of the text box in which we can put additional information about the marker (lines 107 and 120).
Today we have seen how to create the entire editing interface of our map block. As you can see, it’s a process that might seem complicated at first glance, but becomes pretty natural quickly. In the end, the secret is to start from an example that is well organized (as our plugin boilerplate is) and build the interface step by step, reusing the components that WordPress offers or that already exist, or even creating your own.
See you next week with the last part of this tutorial, where we’ll see how to save our map and how to view it in the front-end.
I hate it when I waste my time doing the same tasks over and over again. That’s why we created Nelio Content, so neither you or I get stuck with boring stuff! Check it out!
A few days ago we published a new plugin in the WordPress.org plugins directory: Nelio Maps. As the name reveals, it’s a maps plugin that adds a new type of block in the WordPress editor. With it, we can easily add a Google map on our pages or posts. Here’s how it looks:
Nelio Maps is one of our first plugins entirely designed for Gutenberg. Despite being a relatively simple plugin, it is a very useful product. On the one hand, because any user who wants to add maps to their website can now do so by installing a simple and lightweight plugin. On the other hand, because any developer that wants to develop in Gutenberg now has a real example of how to create a plugin “from scratch”, simply by reading this post.
As I am aware that the development of a plugin like this is not the easiest thing in the world, I have organized this tutorial in three different parts. Today I will explain how to create the plugin “from scratch” so that we end up with the skeleton we’ll use to build the final product. In the second post I will explain how to get an interactive map in the WordPress block editor and we will see all the components that I have created to make the plugin. Finally, in the third and last post we’ll see how to save the map in the database and how we can show it in the frontend.
Defining our Project and the Plugin We Want
It may seem like a truism, but before embarking with any new project, the first thing we must do is define what we want to achieve with said project. Depending on the functionalities we want to include, we will have a different set of requirements. So let’s define what kind of map plugin we want to implement in this tutorial.
These are the requirements of the project:
One should be able to add a map (or more than one) to their pages or posts.
It should be possible to center the map anywhere by
either dragging the map with the mouse
or looking for the location in a search box.
The size of the map should be adjustable, both in width and height
The map should include different styles (black and white, custom color palettes, etc.)
The user should be able to add a marker in the map.
If there is a marker, the map must be accompanied by a text box with additional information about the marker.
To start our project, the first thing we will do is mirror Nelio’s boilerplate plugin. First, create a new repository in your GitHub account. Then, follow the steps described in Github’s help pages to mirror our boilerplate:
git clone --bare https://github.com/avillegasn/wp-beb.git
git push --mirror https://github.com/your-username/your-repo.git
Once your project is ready, follow the instructions found in README.md to compile the project and thus be able to see it in your WordPress site.
How to Transform the Plugin Boilerplate into Your Plugin
As it appears in the plugin boilerplate documentation, the first thing we have to do is change the project’s name in the source code. That is, you have to change all occurrences of wp-beb (both uppercase and lowercase, with hyphens or underscores) by the name of our plugin (in my case, nelio-maps).
For this, we can use the following script:
Just keep in mind you’ll have to replace the string nelio maps int lines 5, 8, 9, and 10 to whatever your plugin’s name will be.
On the other hand, now is also a good time to change the plugin documentation. On the one hand you have to edit the files README.md and readme.txt to reflect the purpose of your new plugin (without forgetting to mention the fact that you are using our boilerplate as a base, of course). On the other, you should change the first comment in the main PHP file, as it’s the data WordPress uses to display the plugin in the Plugins screen.
How to Clean the Plugin Boilerplate of Unnecessary Stuff
Nelio’s boilerplate plugin includes, by default, a couple of components: (a) a demo block and (b) a Gutenberg plugin. Since we are only interested in creating a block (the map), we are going to eliminate everything that is left over (the Gutenberg plugin).
This step is quite simple, since basically it is based on “deleting” unnecessary things from the plugin. Specifically, we should:
Get rid of all the content that appears in the assets folder (which is where the Gutenberg plugin was added, its style, and its icon).
You can see all the changes in this commit. If you compile the code again, you will see that the Demo block still exists, but the Gutenberg plugin that appeared in the upper right corner of the screen doesn’t.
In today’s post we have seen how to create a plugin for Gutenberg. First, we have defined the type of project we want to create and we have identified its requirements. Next, we have seen the steps needed to adapt the boilerplate plugin from Nelio to a new project. That is, we have seen how to clone Nelio’s boilerplate project and clean it to meet our particular needs.
See you next week with the second part of this tutorial, where we will modify the Demo block so that it performs all the functions we have described at the beginning of this post.
One of the things I like the most about WordPress is its plugin system–there’s a lot you can do! For instance, you can download and install our new plugin, Nelio Content.
The WordPress block editor is very intuitive. But even if you’ve been using it since its first release, it’s possible that there are still tricks and little things that you haven’t noticed and that can make part of your work as a writer easier. And that’s why I think it’s worth spending a few minutes of your time to reading this post that will help you master the block editor.
If you’re still with the classic WordPress editor and don’t know how to get started with the block editor, I recommend that you read this introductory article to Gutenberg by David.
Assuming you’re already familiar with the new editor, here’s a list of new features or tricks that you may not be familiar with. I’ll start by commenting on some new blocks that make it much easier to create content and, then, some tricks you can use in the editor that can be practical for you.
#1 Add A Button
With the classic WordPress editor, if you wanted to add a button in the middle of a post or a page you basically had two options: either switch to HTML mode and write the code, or use some plugin that created a shortcode for the button in question.
The block editor already incorporates the button block that allows you to quickly create a button in the middle of a post:
The Button block allows you to create a button in which you define its appearance, the background and font colors, and you can even add a CSS class.
It’s that easy! And the result is a button like this one, which you should click you want to subscribe to Nelio Content 😉
As with the button, adding a simple table with the classic editor also meant doing it with HTML and CSS or with some plugin. In fact, it was often easier to create the table with any other editor and then insert it into a post as an image.
Now you have the Table block that you’ll find in the set of Formatting blocks.
After selecting the Table block, you must indicate the number of rows and columns that you want to create by default. But don’t worry, then you have the option to add or delete rows and columns. You can also indicate the style of the table.
In this way, you can create the following table with some features of Nelio A /B Testing very easily.
5,000 tested page views
35,000 tested page views
200,000 tested page views
For Small Business
For Large Businesses
#3 Embed An External Element Just By Copying And Pasting
Other blocks that can be very useful are embedded types, which allow you to embed external elements such as videos, Facebook posts, tweets, etc.
But you can also, instead of creating a block of this type, directly copy and paste the URL you want to embed and automatically insert the item in question. Just paste a link such as https://youtu.be/7SzwJQ55jus and let WordPress do the magic:
#4 Use The Spacer Block To Increase The Space Between Blocks
This is one of the blocks that perhaps you didn’t know existed either: the Spacer block. Its function, as its name suggests, is to increase the spacing between blocks.
The Spacer block has by default exactly 100 pixels but you can customize the height of it as you want. Just position the cursor over the blue dot below the block and increase the size by dragging the blue dot as far as you want.
In addition, you can also use an additional CSS class to define how you want the spacer block to be. This can be very useful in the creation of pages.
#5 Information On The Number of Words and Structure
In the classic editor, you would select a post and, automatically, get number of words in that post. Now, where is this information in the block editor?
Don’t worry, in the toolbar you have this information at all times very handy by clicking on the icon of a circle with an i. And it doesn’t just count the words, it also tells you the structure of the whole post or page you’re editing.
#6 Move The Block Toolbar To The Top
By default, when you are editing a block you have the block toolbar floating on top of the block itself. The big advantage of this is that you have it more at hand but the problem with floating toolbars is that they can cover part of the previous block.
As you can see in the image, the toolbar is covering part of the previous headline. If this is impractical or annoying, you can easily change it. Click on the three dots of Showmore tools & options and check the Top Toolbar option.
Once checked, you have the toolbar fixed at the top of your editor.
#7 Use The Slash (/) As A Shortcut
The block editor gives you some shortcuts so you can be more efficient editing your posts. The first one you should use is the slash, /. As easy as starting to type the name of a block with the slash and it will show you the types of blocks you can add:
#8 Learn About Other Keyboard Shortcuts
One of the features that the new editor has incorporated is that you have many other keyboard shortcuts that can help you be much faster typing. To know them all, click on the three dots of Show more tools & options:
Alternatively, you can also access this help with the shortcut or Ctrl⌥H (for Mac) or ⇧AltH (for Windows). And below I show you the shortcuts that I think you may find most useful.
Shortcut in Mac
Shortcut in Windows
Display this help
Save your changes
Undo your last changes
Redo your last undo
Show or hide the settings sidebar
Open the block navigation menu
Switch between Visual Editor and Code editor
Shortcut in Mac
Shortcut in Windows
Duplicate the selected block(s)
Remove the selected block(s)
Insert a new block before the selected block(s)
Insert a new block after the selected block(s)
Change the block type after adding a new paragraph
Shortcut in Mac
Shortcut in Windows
Make the selected text bold
Make the selected text italic
Underline the selected text
Convert the selected text into a link
Remove a link
Add a strikethrough to the selected text
Display the selected text in a monoespaced font
#9 Convert A Block Into Header With Hashtag (#)
You might consider this as a keyboard shortcut. Gutenberg’s block editor supports three types of headers: H2, H3 and H4. When you are typing the block by default is paragraph type. But you can turn it into a header very easily: start typing the new paragraph with ## for H2, ### for H3 y #### for H4. Try it and you’ll see how easy it is.
The first experience you have with the new block editor after years of using the classic WordPress editor may not be what you were expecting. But it’s normal, changes are difficult.
In the beginning, you might not be able to find certain things or think the editor is slower to use… And it’s true: the block editor still needs improvement in quite a few aspects. But if you learn to master it, little by little you will see its advantages and you will see that there are things that you couldn’t easily do before that you can now do.
Our recommendation? Go ahead and give the new editor a shot—you’ll soon forget how the classic editor worked!
If you’re like me, I’m sure you don’t want to waste any more time on Twitter, Facebook, LinkedIn… promoting your content. Use Nelio Content instead and let it do the hard work for you! Take a look at it!
Do you know how often you should update WordPress, the themes and the plugins? Don’t doubt the answer: ALWAYS (or as soon as you can).
The more time you let go without having everything updated, not only maybe you will miss interesting new features, but also run the risk of seeing how things stop working properly, finding incompatibilities between plugins or your theme, or having a security breach in your web.
That said, the update process is not trivial. First, you have to know in what order to upgrade. For example, it would not make sense to update a plugin that serves to adapt to a new version of WordPress without having previously installed that version. But what if you update WordPress first and then you find that the plugins you have installed on your website are not prepared for this change? Precisely this has been one of the most important problems we have suffered with the new version 5.0 of WordPress.
Further, note that not all updates are always secure. More than once an update of a plugin makes it suddenly incompatible with another plugin, breaking something that was previously working well.
Seeing clearly the need to keep our website updated, let’s see how to make sure that we do it safely.
Automatic Update of the Core, Plugins, and Themes
I start from the premise that your website uses a good hosting service that guarantees you a minimum at the start. That is, you have:
And if that is not the case, it’s 2019! Time to find a better hosting provider, maybe? 😉
That said, let’s go to the subject of automatic updates: as you should know, after WordPress version 3.7 (October 2013), by default, WordPress automatically performs minor Core updates. This ensures that certain vulnerabilities are fixed.
If you have a corporate website or a blog, you want to automate the updates, and you are a risk lover, then you can add the following line in the wp-config.php file:
define( 'WP_AUTO_UPDATE_CORE', true );
In this way, your WordPress will always be updated automatically. Remember that although you should always have your WordPress updated, the automatic update of this is not without risks, as it can cause incompatibilities with your plugins.
Activaction In The Hosting Service
Many hosting services have their own tools that allow you to activate automatic updates and indicate which plugins you want to be updated automatically. If you enable automatic updates for certain plugins, the recommendation is that you do so only with those plugins that don’t have any impact on the front-end. For example, these can be automatically updated:
Admin tools such as duplicating posts or columns
Broken links testers
Optimization of the database
This way, if something fails, at least it won’t have a negative impact on what your visitors see.
The competent hosting companies backup your website before doing the automatic update in case the update is not done correctly. Their tools automatically check if your website is working correctly and if they detect any errors, they will revert the changes and notify you.
Another alternative to manage plugins and themes effectively is to use the administration panel ManageWP. With this tool you can manage all the WordPress sites you want under the same administration interface, similar to a native WordPress. To do this, register to ManageWP and then add and activate the ManageWP Worker plugin in all the websites you want to manage.
You can manage the backup copies and customize the core, plugins, and themes updates as you want for each site.
The most outstanding features of the free version of ManageWP are:
Create backup copies automatically and restore them with just 1 click,
Update plugins to new versions, with just 1 click, on all WordPress sites at once,
Update the themes of each installation,
Manual review of security and optimization,
Review and manage the latest comments,
Optimize the database of the WordPress installation (delete transitions, revisions, temporary …),
View the Google Analytics statistics for each site, and
Consult performance and positioning reports.
In addition, from ManageWP, you can access the Dashboard of each WordPress with a single click, saving you having to access the URL of each of them. And with the premium plans you can also make backup copies on a regular basis as often as you indicate or automate the security check and optimization among other features.
Finally, if you want to stay calm and make sure that an update doesn’t break anything in your WordPress, you always have the option of doing it manually with your supervision.
As you know, in the WordPress Dashboard , you are informed at all times of the updates that you have pending to install on your site.
Remember that we have already said that it is not advisable to go just update everything. The safest way to make any change to your website is to have a hosting servicethat offers you a staging environment and a production one; so you can make changes in staging quietly while the production environment is responsible for serving your users. When everything works correctly in staging, you can copy it to production.
In the case that you are going to update the Core, WordPress recommends that you first deactivate all the plugins that you have installed. You can do this easily by selecting them in the list of plugins, marking them all and applying the option of Deactivate .
Then access your files via FTP. Delete wp-admin and wp-includesdirectories.
Via FTP, upload the new directories that you have extracted and have in the local wp-admin and wp-includes.
In the case of the files in the wp-contentdirectory, do not delete or overwrite this folder.
Next, copy the rest of the files overwriting the ones you had.
And finally, check wp-config-sample.php in case you have to make any changes to your wp-config.
#2 Update the Installation
Once the files are updated, go to the WordPress Dashboard. If there is a need to update the database, WordPress detects it and will show you the link that takes you to/wp-admin/upgrade.php. Follow the link and complete the steps indicated to update the database.
You only have to go back to the list of plugins and reactivate them all. You can do it all at once or, alternatively, one by one while checking that everything is still working as expected.
#3 Clear the Cache
Don’t forget to clear the cache to finish the process of updating the WordPress Core and make sure that all your visitors are accessing the latest version of your WordPress.
And If A Problem Arises…
If there is a problem in the WordPress Core update, in the WordPress Codex they explain in more detail the whole process in more complex cases and the most common problems you can find and how to solve them.
Updating plugins, in principle, is much simpler. Just remember to make a backup first!
As you know the update of plugins and themes that are in the WordPress Directory you can do it directly from the Dashboard of your WordPress. But before updating any plugin, I recommend you read its Changelog where you can see if it is a major update or a patch with small changes.
Remember that the version number is a good indicator of the type of change that this update supposes. If it is a major change, look carefully for any new errors or incompatibilities this new version might have introduced.
In most cases the only way you’ll discover whether things work as expected or not is by giving the new version a try. So the best recommendation for major changes is to first test it in a staging installation and after seeing that everything works, make the change in production.
The update of the theme of your website can be a bit more tricky since any type of customization that you’ve made to the theme or modification in the settings can be lost. So before encouraging you to update a theme, keep in mind the following:
Understand what kind of change it is.
Keep in mind any changes you applied to the theme will be lost after updating it, unless you applied them in a child theme.
If the new theme has new identifiers and classes in the HTML, your stylesheet may stop working.
Keeping a WordPress site up to date can sometimes seem like a cumbersome job. Do not procrastinate. It’s necessary for the safety and proper functioning of it. So don’t skim on time and resources to make sure your website is updated correctly and sleep more peacefullly. 😊
One of the things I like the most about WordPress is its plugin system–there’s a lot you can do! For instance, you can download and install our new plugin, Nelio Content.
The best thing about WordPress, what makes it special, what has made it stand out is its open source nature. WordPress is distributed under a GPL license, which gives users four freedoms:
Freedom to run the program for any purpose
Freedom to study how the program works and change it to make it do what you wish
Freedom to redistribute
Freedom to distribute copies of your modified versions to others
The beauty of free software lies in the communities it enables. Since developers have access to the source code, anyone can propose corrections to bugs, improvements, etc. But what if you’re not a developer? Can’t you contribute to the project?
If you’re a happy WordPress user and want to contribute to the project, but you don’t have any programming skills, don’t worry—you too can help! Why not join the translation team? It’s relatively simple and I’m sure your local translator team will welcome you and offer you a good time.
Some time ago I wrote a post for developers explaining what they had to do if they wanted their plugins or themes to be translatable. Making our source code translatable is the first step towards a localized WordPress version. But once this is done, we need someone to actually translate it…
If you want to translate WordPress (its code, the documentation, its plugins and themes, mobile apps, etc) into your language, you will first need an account on WordPress.org. If you don’t have one yet, you can create one from this page. If you already have an account, log in.
Bear in mind that translating is not easy. You have to know the source language well (usually English) and you have to know the target language even better (Spanish, Catalan, German, French…) The first thing I recommend is that you read the Polyglots handbook carefully, as you will find very good advice there, including:
Don’t translate literally, translate organically. As a translator, you undoubtedly know that each language is unique. Given that, try to avoid composing your translation in the same structure as the original English string, while sounding natural and still conveys the same message.
Try to keep the same level of formality (or informality). WordPress messages (informational messages in particular) tend to have a politely informal tone in English. Try to accomplish the equivalent in the target language, within your cultural context.
Keep it consistent. Translations are collaborative work involving a lot of people. Use a glossary and a style guide to make sure that everybody is on the same page and your work is consistent.
As you can imagine, WordPress is available in a lot of languages besides English: Spanish, German, French, Italian… Translations into each language are managed by their own team. The members of these teams have different roles:
General Translation Editor (GTE) is the person in charge of validating strings on all projects of a given locale. The only way to become a GTE of a language is for another GTE of that same team to do it (probably after having actively contributed in that language for a long time and with high quality translations).
Project Translation Editor (or PTE) is similar to a GTE, but they can only validate strings on a given project of a given locale. For example, I (as a native Catalan and Spanish speaker) am a PTE of Nelio’s plugins in Spanish and Catalan. Project translation editors are appointed by a GTE after a request by the project author or by the contributors themselves.
Translation Contributors are volunteers who translate the different projects into their language. In these cases, their translations are considered “suggestions” and must be approved by a GTE or a PTE. You’ll start as a contributor 😉
Translation Guidelines and Glossaries
As I was saying, one of the most important things when translating into your language is consistency—translators shouldn’t do as they please, but follow some rules and principles. This guarantees that, no matter who translated what, the final result will look coherent and professional.
For instance, in Spanish (Spain) we have a style guide and a glossary that define how a Spanish translation should look like. As a Spanish translator, it’s extremely important that you read those carefully before translating anything and adhere to the rules. Some of these rules are:
Plugin and theme names should not be translated.
Don’t use Google Translate or other tools to suggest translations.
Use the informal form of you (tú) and not the formal version (usted).
The glossary is also extremely interesting. Translators will often face certain words that might have multiple valid translations in the target language. Which one should they use? Well, in these cases, a glossary can come very handy, as it’ll tell us what’s the preferred alternative:
Once you’re familiar with the style guide and the glossary, it’s time to get started. Choose the plugin or theme you want to translate (I recommend you start with one you use, as you’ll be familiar with it and it’ll therefore be easier to translate), find what strings aren’t translated, and suggest your translation.
For example, let’s assume you want to contribute to Yoast SEO translations. Go to the plugin page on WordPress.org, click on the Development tab, and click on the Translate “Yoast SEO” into your language link:
This takes you to the translations page of the plugin. This screen is very interesting because you can see the status of each locale. In Catalan, for example, we see that this plugin has several strings that need translating:
Strings are organized as follows:
Development (trunk) are UI strings. They belong to the development version of the plugin, so they might change in the near future.
Development Readme (trunk) contains all the strings that will appear in the WordPress plugin directory. Again, since this is the development version, the strings are subject to change.
Stable (latest release). are the strings that appear in the stable version of the plugin itself and, therefore, what current users see.
Stable Readme (latest release) are the text strings that describe the plugin right now in the WordPress plugin directory.
When translating one of the previous sections, this is what you’ll see:
Filter the list of strings so that only untranslated strings are shown and get the job done.
Finally, it is worth mentioning that translation teams usually have a Slack channel or similar so that members can talk to each other and coordinate their work. In the case of the Spanish community (from Spain), for example, we have a Slack channel:
One of the funniest things about being part of a free software community is, precisely, interacting with other users. So don’t stay home alone translating; get Slack and join your team!
It’s Your Turn
Now it’s your turn. If you’re a happy WordPress user and want to help more people adopt it, this is how you can contribute. Translate WordPress into your language and make WordPress better!
Today we are taking a step further and we’ll see how to define the goals of your website in Google Analytics to know how good (or bad) it is performing.
The first thing you’ll need is a Google Analytics account, something very easy to get if you already have a Google account. I’m going to assume you have one and that you also have installed the Google Analytics tracking code on your website. You can always review this article in case you have problems on the matter.
To define the goals of your website in Google Analytics, you have to access to the admin panel of your account and there you will find the Goals menu in the View section.
Within this menu you’ll find all the goals previously defined. If you didn’t create one yet, the list will be empty. Luckily for you, if you don’t want to mess with your account you can see the goals defined in the aforementioned Google Analytics demo account. You won’t be able to set new goals in that account, but at least you’ll be able to see how they’re set.
To create your goals in your web analytics tool you must first know what you want to count as a goal in your website. In Google Analytics there are three types of basic goals that you can define: destination, duration, and pages/screens per session. In addition, you have an extra type of goal that takes into account events, but I’ll leave it for another day so we can focus on the other, simpler ones.
Let’s look at each of these three types of simple goals, what they are, and how we can define them to measure what we want.
If you want to measure how many times your visitors spend more than a certain number of seconds on your website, you can do it with Google Analytics Duration goals. This is especially useful in websites full of content to know if visitors really spend the time required to read everything or if they leave before doing so.
Or also on websites that sell products. Research has shown that if your visitors spend more time on your website, it is easier for them to end up completing a purchase on it. If they leave quickly, you have a problem that you must solve. With this type of goal you will be able to know this information.
When you create a new goal in Google Analytics you will have to choose its type. Choose Duration and name the goal so you can quickly identify it.
In the above image, what we want to do is to count those visitors who spend more than 1 minute on our website. That is why we have chosen “1 minute or more” as the name of the target. When you click Continue, you will see the next part of the goal creation form:
At this point you have to indicate the amount of time you want to mark as a minimum for your goal to be counted as fulfilled. In our example, if a visitor spends a minute visiting our website, Google Analytics will count that as a goal completion.
Later on we will be able to see the conversion rate for that goal, which will indicate the percentage of visitors over the total who have met the duration goal (in our case, spending more than a minute visiting the website).
Pages/Screens Per Session
Another kind of goal is to measure the number of pages or screens that a visitor has accessed during a session. If we are interested in counting this, with Google Analytics we only have to choose this type of goal, as you can see in the image below:
In our case we want at least 4 pages to be visited on our website, so we set the target so that the number of pages visited is greater than 3 (that is, 4 or more).
As soon as your visitor meets this goal, Google Analytics will note it and then you will be able to see the conversion rate on this specific metric you just defined.
So far, you can see that both the Duration and Pages per session goals are quite simple to understand and define. Let’s try to do something a little more difficult…
If you want to measure how many of your visitors access a certain page of your website, Google Analytics already gives you that information without any additional configuration. You only need to check the amount of visits to that page.
However, the Destination goal is extremely useful because it not only lets you know how many visitors are coming to a particular page, but you can also define the previous pages that they have to go through to get to that page. This way you can check the entire funnel through which your users pass and track where you lose them. Is it in the first step? Just before reaching the final destination page?
Create the goal, name it, and choose the type Destination. In the example above you can see that we have chosen “Purchase Completed” to name the goal. This is because we want to know how the sales funnel of our website is working, from the moment the user goes to the shopping cart until the order is completed.
When you go to the next step of the goal creation form, you must choose which destination page the visitor ends up on (ordercompleted.html in the example):
Then, we activate the funnel option (as you see in the image above, it is optional and disabled by default). This is where we are creating the necessary steps to define the sales funnel of our website.
In our running example there are 4 steps before getting to the destination page. We define these steps in order and, in addition to giving them a name, we indicate the partial URL of each of the pages that belong to the sales funnel:
The visitor goes to the shopping cart (which is the page /basket.html).
Confirms that he wants to start the checkout process and, when redirected to the page /yourinfo.html, introduces his billing and shipping info.
The process continues and he enters the payment details (in the page /payment.html).
After that, the visitor reviews the order (page /revieworder.html).
When the order is completed (redirection to /ordercompleted.html) the purchase process ends.
This is the same scenario Google defined in its Google Analytics demo account for the funnel of the Google Merchandise Store. If you go check that demo account you’ll find there the Purchase Completed goal.
The benefit of defining the goal including its funnel is that you can go to the menu Funnel Visualisation inside Goals submenu as shown in the next image. There you can see at a glance the visitors flow and check where you lose them during the steps of the sales funnel:
Google Analytics is not only used to see the number of monthly visits your website receives. By defining and using goals in Google Analytics, you can control your conversion rates and even know where in your sales funnel you have the most problems.
If you’ve never defined a goal on your website with Google Analytics, I encourage you not to waste more time and give it a try. I am sure that the data you get out of it will help you to continue improving and optimizing the performance of your website.
If only I had a calendar where I could schedule all my upcoming posts… Hold on a sec, I do have one! And it even helps me to promote it on social networks! Discover our new plugin!
Earlier this month I shared a post on how to install, configure, and use Docker in local WordPress development. The main advantage of Docker was its containers: each WordPress installation was encapsulated and isolated from the others. These containers were started by using a configuration file and a simple command: docker-compose up -d.
The first time you started a Docker container with WordPress, you had to go through the WordPress installation process:
After writing that post, I thought it’d be great to complement it with another tool that helps us to manage WordPress installations from the command line itself. Well, wait no more! Today I’m going to teach you how to use WP-CLI to manage WordPress installations from the console.
What is WP-CLI?
The command line is every developer’s best friend. WP-CLI (WordPress Command Line Interface) brings the management and maintenance of WordPress to our command line and it’s an indispensable component for any developer who wants to seriously optimize their time. With WP-CLI you will be able to update plugins, configure multi-site installations, and many other things without having to use a web browser.
The project documentation explains how to install WP-CLI. There are many options to do it, but the easiest one is to download the executable file directly:
and launch it using PHP:
If we want to use the command in a more “friendly” way, we can give it execution permissions and move it to some directory that is in our $PATH:
and from then on we can run the command as follows:
By the way, remember to run wp from the WordPress root directory:
WP-CLI and Docker
Suppose you are interested in using WP-CLI to manage the different projects you work with. If you followed my guide a few weeks ago, you’re probably using Docker now. So the question is: how can you use WP-CLI and Docker together? Is it possible to run WP-CLI in your WordPress Docker containers?
Ideally, the WordPress image we use in Docker should include WP-CLI. Unfortunately, at the time of writing this post the official image doesn’t include WP-CLI (and adding it can be tricky). But don’t worry! There are other images we can use that do include WP-CLI out of the box. Instead of using this:
use the following image:
And that’s it! Running docker-compose up -d will download a new WordPress image that includes the WP-CLI binary.
The only problem we have now is that WP-CLI is inside the container (i.e. the “guest machine”), and we are using our terminal on the “host machine”. How do we access it?
To execute a guest command from our host we must use docker-compose as follows:
For example, suppose I’m working on our Nelio Content plugin, which I have in a directory called nelio-content. In the docker-compose.yml file I created for this project I defined two services: one for WordPress (which I called wordpress) and the other for the MySQL database (mysql). Well, since WP-CLI is in the WordPress container, this is how we run it:
Finally, if you want to use a friendlier version, create the following alias:
and you’ll be able to run the command using just two simple letters:
Now that we have WP-CLI installed and know how to invoke it, it’s time to see some examples of what it allows us to do.
What WP-CLI Commands Look Like
In general, WP-CLI commands follow the following pattern:
In the documentation you have information about all available commands, their parameters, and how to use them. Don’t forget to have it at hand to consult it when you need it.
As I advanced in the introduction, the first thing you have to do when you start a new Docker container with WordPress is to complete the WordPress installation process. With WP-CLI, this is as easy as executing the following command:
If you want to upgrade to the latest version of WordPress, just run this:
And if we want to go back to an older version, we can do so with the following command:
Another common task we face when working with WordPress is plugin management. For example, right after we started a new Docker image with WordPress, we’ll see that said image includes multiple plugins we might not be interested in. How do we know which plugins are installed? How the we get rid of them? How do we activate the one(s) we want?
Listing Installed Plugins…
If you want to see the plugins installed in your site, run the list subcommand of the plugin command:
In my case, this returns:
To delete plugins you no longer want, just call wp plugin delete and specify the plugins you want to delete:
And to activate a plugin, repeat the process, but use the activate subcommand instead:
To install a new plugin, run the following:
and WordPress will download the plugin from the plugin directory on WordPress.org and will activate it automatically. Easy, isn’t it?
Theme management is very similar to plugin management: we can list installed themes, switch the active them, delete them, etc. For example, to list the available themes we have the following command:
which gives us the following result:
In this example, the currently active theme is twentyseventeen. How would you switch it to twentynineteen? It’s super easy:
What if we want to update all the themes that have available updates? It’s super easy too:
How cool is that? 😎
And Now, What?
This has been a brief introduction to the use of WP-CLI. If you want to delve deeper into the possibilities it offers, in WordPress.org you will find all the documentation about this tool: how to install it, how to configure it, and how to use it. I recommend you read the documentation thoroughly and continue to discover the potential of WP-CLI on your own.
This site uses proprietary operational cookies that have a purely functional purpose and third-party cookies that help us understand how visitors interact with the site by collecting and presenting information anonymously. If you continue browsing, you accept their use but you can disable them if you wish. Read more…