How to add an index in the WordPress options table and why you should do it • WordPress Help

Table options ( wp_options by default, or ideally with your custom prefix) of WordPress is the one that goes accumulating information about each of the plugins, settings and configurations and more, that you are installing throughout the life of your website.

If we add that the Most plugins do not delete lines from this table, you'll see that is gradually becoming a monster with thousands of lines, which WordPress checks and launches on each page load .

As you can imagine, a table options large can greatly slow down your website since your WordPress must make many requests and launch requests before loading each page for each visitor.

Ergo, if we could limit this amount ad requests your web would load faster, having to make fewer queries, right?

The culprit: Autoload

The culprit of all this is the field Autoload of each line of the table options, usually with the value in Yes that is, yes, it is automatically loaded by the function wp_load_alloptions () .

What's the problem with Autoload?

Well, very simple, it automatically loads all options from table options though:

  • The plugin option does not need to load on each page (Example: contact form that loads its settings across the web when it is only on one page.)
  • The plugin is no longer installed and active.
  • The theme is no longer active.
  • The plugin should have created their own tables and do not put their options in the table options

And, the green The problem is when it self-loads too much but what is too much?

Important note : In this article, we will work directly with the database. Before executing any query or touching something in it, make a backup copy.

Execute this SQL command, you can do it in PHPMyAdmin of your hosting panel:

Note: Change the example prefix to yours, do not forget

Click on the button Continue or execute the SQL query and you will get the size of the query of all the values ​​with autoload e bytes. And the rule should be:

  • If the result of autoload_size is greater than 1 Mb (approximately 1,000,000 bytes) you should do something to optimize this.

the example of the capture size is ridiculous, so if your results are like that you have just read the article, dedicate your time to blog something.

If you obtained a result above 1Mb, or just want to dedicate a Having said that,

Having said that, would it not be better to define what is loaded and when in our WordPress installation?

Create an index in the options table

There are several ways to thin the table options but we will see mainly one that has proven to be tremendously effective and easy to apply.

Why is the best solution?

The best solution to tables options huge that slow down your w eb is to create an index of the table options . In tests on sites with many lines with Autoload the difference between loading the table with and without index return some results beyond doubt.

In case you do not know English: in red loading time Autoload without index, in blue with index.

You can also see how the loading time in a site was reduced after adding an index:

The improvements performance and speed are brutal, especially with large databases, and the best thing is that creating an index is very simple.

Check the index

A good test to do before creating the index is to see how many columns (options) have Autoload in Yes that is, they are loaded. This would be done as follows:

For those that do not load, those that have Autoload in No .

Results will look like this:

The rule to apply would be the following:

  • If the values ​​in No exceed 60% of the total then you do not need an index.

Create an index with SQL commands

If you feel comfortable, you can create the index by executing a command like this:

Again, you can change the name of the index, autoloadindex in the example, and you must change the prefix of the table options by which you use.

Create an index with WP-CLI

If you prefer to use the WordPress command interface WP- CLI you would do it this way:

Create an index with plugins

In case you do not you want or do not you dare with SQL, there is also a plugin that will help you in this task of creating the index.

It is called Index Autoload and it does not even have adjustments, you activate it and it's done. [19659003] Of course, even if it is a plugin, the rule of backing up the database is still valid, do not forget it.

This plugin creates the Autoload index equally.

I do not want the index anymore

As there is nothing like freedom of choice, if at any time you no longer want the index you can execute this command to erase it:

Again, remember to change the index name and prefix of the table to yours.

If you used the option to do so with the plugin to deactivate it and delete it is also deleted the index.

Is it really worth it?

Although there is nothing better than doing a test, I will give you some advice:

  • If the options in Autoload of your table options weigh more than 1Mb worth it
  • If the Autoload Yes exceeds 60% it is worth it
  • If you have a table options great is worth it

The result is to reduce the WordPress queries to the table options in more than 90% in many cases, which results in better load times on your website. [19659138] To learn more

Here you have some resources to continue learning about this subject:

Car gando …

That may also help you:

Tips that you should keep in mind if you are going to develop blocks for Gutenberg

Although I am not a big fan of how the implementation of Gutenberg has been decided, actually I am very interested in the development of the new WordPress editor itself.

That is why, since I am in flour for to prepare myself for what is to come I am going to share with you some of the things that I have been learning at the time from develop blocks for the new Gutenberg editor of WordPress as well as the adaptation of the themes to Gutenberg .

Just to remind you that I am neither a career programmer nor an expert in Gutenberg ( still), I'm just learning to create blocks for the editor.

The following tricks are things that I have been learning about entangling and investigating resources like the same plugin Gutenberg ] the basic theme for Gutenberg [1945900] 4] Gutenberg Best Practices and this gem called Create Guten Block .

Do we wear it?

Where do I include the blocks, in the theme or in plugins? [19659008] We've already mentioned it before, when we were talking about if it's better to edit the functions.php or use a plugin and the base rule is that if something affects the visualization thinks about the subject, and if you add features, use a plugin .

So when we think about blocks we apply the same principle, and since most of the blocks add functionalities to WordPress as a whole, in a key and base utility as is the editor, I think makes more sense as plugins .

What's more, think for a moment … If I change the subject, will I lose the functionality that the block does in my content? The answer will almost always be yes. WordPress will no longer know what to do with the block information, stored in the database, but associated with an active topic that is no longer.

On the contrary, if your block is in a plugin, or you deactivate it, or it will be agnostic of the active theme, it will work with all.

File structure of a block

Although it will always vary from developer to developer, and there is no standard file structure, there are patterns when it comes to develop blocks for Gutenberg .

A typical block plugin consists of a file my-plugin-of-blocks.php used to enqueue the blocks, and a directory / blocks in which to host all your blocks.

Within the directory / blocks you can make sub-folders for specific blocks, such as / custom-block . And inside the directory / block-custom would be your files index.js editor-styles.css and styles.css of your block.

Seen the above, to see it more clearly, we talk about a structure of this style:

Naming the blocks / namespace

When you register a block, the name you have to structure it as namespace / block-name and in block-name you can only use lowercase, numbers, and simple hyphens, plus you should always start with a letter .

On the other hand, namespace is the name of your plugin. Then in the previous example namespace / block-name it should actually be something like my-plugin-blocks / custom-block .

Translations

Yes you have already published a plugin or theme in WordPress.org you should already know how to prepare them for translation .

When working with blocks it is practically the same even though the blocks are create mainly with JavaScript. Basically keep in mind that you should always make your blocks translatable, just like your plugins and themes, and it's also easy to do.

Beware of the issues

The main thing to remember is that blocks can include their own styles necessary for them to work properly. But the themes can overwrite the styles of the blocks as in the example we saw a few days ago .

There are few things in Gutenberg that require compatibility with the themes, mainly because to the nature of how Gutenberg is programmed, and to the difficulty of the blocks to facilitate the proper styles.

The new wide and complete alignments

In this respect the most important thing to keep in mind is the new options of alignment of images alignfull and alignwide . They can be used for images, and also for blocks.

The problem when adding them to blocks is that they may not work on some topics, especially those with sidebars.

Add to the active topic the Compatibility with the new alignments is as easy as calling the function add_theme_support ('align-wide'); in the functions.php file of your theme, like this:

Then do not forget to add styles to the new alignments on the sheet of styles of your theme.

Color palettes of the blocks

One of the coolest things about Gutenberg is the color selector, which offers the developer of themes total control over what colors the color can change user so offer a consistent color palette when creating the content .

To incorporate compatibility of your theme with this functionality, you can add it, with your personalized color palette to the active theme by adding something like this to the functions.php file:

And you can even go further and disable the custom color picker from Gutenb erg to only show the default options. To do this, add this to your functions.php file:

Warning: If you add all these options you can do so in the same function. Do not define 3 times helpwp_setup_theme_supported_features or you'll have an ugly PHP error.

Summarizing

I know it's not much I've told you, but I hope you learned something new about Gutenberg and how to create your We will be seeing more guides and tricks for Gutenberg, and of course you can always leave your own tips and tricks for Gutenberg in the comments.

Loading …

Maybe you too help: