Yoast SEO and Facebook Open Graph Page Title

It’s a recent news: Facebook does not allo anymore to change the title and description of a shared link. This is a bad news for who is used to change the title directly while sharing.

Probably Facebook is focusing in having only one source of information for a shared page, the page itself, to avoid misleading shares where the title of the page is changed to something totally different. Or just to make it easy for Facebook to rescrap and update the shared information.

With Yoast SEO plugin you can change the meta title for Facebook directly in the post but the only thing I’m interested on is to remove the postfix in the title with the site name. Doing this for each post would be impossible, too much work.

And Yoast SEO has not an option where to set the template for the Facebook meta title as for the general meta title.

Anyway there is a simple solution: filtering automatically the generated og:title metatag and remove the postfix, if present.

Few lines of code are required:

The code add a filter to the WordPress SEO generated meta title for Facebook, search the configured separator from the end of the string and remove the postfix. The coude should be enough safe and can be easily added to the functions.php file of your child theme.

If you need a plugin to incorporate this code in your blog, let me know.

Include Me Version 1.1.5 Released

Long time since the last release, but there were not issues to correct… 🙂

Anyway, this new release of Include Me adds a nice feature: the ability to include another post content.

It may sound odd, but recently I faced a problem on a blog: an important piece of content needs to be added at the end of a number of selected pages. Since the blog was already using Include Me, we had the idea to put the common content in a page (unpublished) and then include that content in other pages.

There are many the ways to do that, but it was a very simply change on Include Me and that change saved us to install other plugins.

You can read more in the plugin documentation page.

The Question To Ask To WordPress Plugin Developers

If you’re in the way to hire a freelance, ask him that question before to decide to work with him:

We need to add few features to a public plugin ([here the plugin name]). Is it possible and safe to customize a public plugin?

He should respond:

  1. if the plugin provides point of extensions (WordPress actions and filters) I can write a plugin which enhance the public one
  2. if the plugin DOES not provide point of extension I need to change the code of the plugin, playing directly on the plugin files inside the plugin folder BUT you MUST NEVER update the plugin since WordPress delete everything before installing a new version (and my customization will be lost)

Why a post for a so obvious thing?

Because there are people which come to me desperate because they lost a custom theme, paid to someone, after a Newsletter plugin update. The developer created the theme adding or changing files of Newsletter. Of course on update everything is reset.

A developer who works with WordPress MUST know that behavior and work in a different way. WordPress has the concept of action and filter, widely used by plugins to let other to extend thair functionalities. Newsletter, for example, is able to search themes in a different folder which is not touched on updated (and documented in the documentation pages).

Please, ask the above question to a developer before starting to work with him or only a backup can save you.

Stop To Choose Your WordPress Theme in That Way!

When you setup a new blog, the first thing you do is to choose a theme. And you surf between all those wonderful screenshots to find the one which best match your needs.

This is the wrong way.

The screenshots are almost all taken from a desktop version of that theme. And yes, they are fantastic.

But your audience is using a phone to surf your site anf the first thing you should test with a theme is: “how does it performs on mobile?”. If it is less than perfect on mobile, discard it (or take in account to do some work).

Example

This screenshot is from a site where the author asked to put up a new free theme. It is a very nice and free theme that worked ut of the box (as you can see there is still no header logo and the screenshot is missing the nice article grid after the main post).

But we need to test it on mobile. We use the Chrome developer console and we get this, for an iPhone 6 viewport:

Actually it could be ok, but we’re wasting a lot of space saying “hey, we are Insegnare e Imparare”. Is it worth to consume all that area for our name? Probably not. Probably we can remove it at all.

Playing with CSS (so without creating a child theme, but only adding few rules in the custom CSS configuration provided by the theme), I removed the top title. Now we have a really different user experience: a beautiful image, the article title and the top part of the article body.

Even Google, which asks to have the relevant content “above the fold” will be more happy!

Ok, it’s better, but we still want our name there. We can reintroduce it but with a smaller font, always plaing with CSS:

Now there is room for our narcissism and content for the reader. Even the main article title could be reduced, and always just playing with CSS.

Conclusions

Always test your theme for mobile. Don’t worry about the desktop version, you’ll find a combination of layout and options to make it good. But the mobile version is harder to adjust.

There is still the habit to build theme starting from the desktop version, because this is the first version people see. But the real value of a theme is the mobile version, if it is quick to load and render, optimized to deliver the content to the reader.

Thumbnails 1.0.7 With a Couple of New Options

Thumbnails is a light plugin which helps your theme to generate thumbnails. Most of the thumbnails can be generated on the fly and stored in a cache folder, instead to full fill your upload folder. More, you change theme and the thumbs sizes changes you can be in trouble with old images.

With Thumbnails there is no more problems.

The new feature are the persistent autowired featured image which really improve the performances of the older versions and the ability to process images for the core sizes (limited to the thumbnail size of WordPress).

Header and Footer With AMP Support

Was time for a review of Header and Footer, the plugin many of you use to inject codes in the head, footer and middle of the posts and pages. The most common injections are:

  • Google Analytics, specially with customizations
  • Facebook Pixel
  • AdSense
  • Verification metatags

The new version removes the Open Graph minimal support since that protocol is now complex and needs a dedicated plugin. The bbPress support will be removed in the near future, so the plugin is lighter for who does not use bbPress and for who uses bbPress I released a more interesting and complete Ads for bbPress plugin.

AdSense for bbPress

Injecting ads on bbPress pages is now really easy with Ads for bbPress.

This new free plugin can inject, like Header and Footer whatever code you need before and after the bbPress pages not not only. It can inject between topic and replies and before the new topic and new reply form.

A must have for everyone running bbPress.

And it’s ultra light: the best practices have been used to load the blog as less as possible.

Find it on WordPress here.

Use get_option() Only Once, As Late As Possible and Store It

I see many plugins to get their options (one or more) with the super useful get_option() of WordPress not only once but every time they needed it and sometime more than once inside the same function.

This is definitively not good for performances. Let me explain why.

Admitting your options are “autoloaded”, your get_option() does not trigger a query to the database but every time you call it:

  • the option name is trimmed
  • the filter “pre_option_nnn” is called
  • the list of missing option is taken from the cache and checked
  • the list of autoloaded options is checked (probably creating a big array copy)
  • the option name is checked against ‘siteurl’, ‘home’, ‘category_base’, ‘tag_base’ special names
  • the maybe_unserialized is called over your option value
  • the filter “option_nnn” is applied

Reference: the options.php file of WordPress.

Every step is taken every time you call get_option(). It’s time to optimize that!

How to optimize the get_option() call?

First, use it as late as possible. Why? Suppose you created a plugin which just runs a shortcode. If that shortcode depends on a set of options but it is rarely used, why to run code which is not required?

To optimize the options load you can code it in this why (my example uses functions to be easy, but you should always wrap the code in a class). I assume you save all the options in an array (WordPress takes care to serialize and unserialize it).

As you can not the options are not returned by “my_init_options()” to avoid an array copy and because they anyway are global. Using a class and an internal property for your options makes the code less “dirty” and less “old style”. Optimized code most of the times is not elegant.

Let start the discussion, now!

Clean Up WordPress User Meta Data Table

During a maintenance of a blog, I needed to clean up the user metadata table since many users was deleted from the main user table (wp_users) with a direct query.

The quick and dirty solution is to run a “left join delete”. Here the SQL statement:

Easy and really quick (please avoid to clean up with a delete plus a sub-query which is the slowest method in the world – other than do it by hand row by row).

Akismet Optimization

I started a war again the resource wasting on Periodo Fertile. That blog counts an important number of pageviews and even if the server has a lot of power it was suffering.

But that sound strange to me since with the same visitor load, months ago the server was not so overloaded. Why? WHY?

A number of plugins have been installed/update and the theme changed. Since I know how PHP coder work, I was suspecting under optimized code was raising the problem.

It is not Akismet, but while digging into the code, I found a little optimization for Akismet but the concept has general value.

Do not get_option() if the option it doesn’t exist

WordPress at startup loads all the options marked as “autoload”. It caches them and every call to get_option() is matched to the cached option names before try to read from the database.

But is an option is not present in the options table, it cannot be cache and the first get_option() call generates a query.

In Akismet you can find:

but the option “akismet_comment_nonce” is missing since there is not a place where to set it. Hence that generate a new query into the database on EVERY page load.

If an option cannot be set form the administration panel we can assume it is false, so I temporary change the code to look like:

and asked for support to know if my assumption is correct. Maybe it is not, always ask the authors!

Conclusion

Always set your options as “autoload” if you need them on every page load, you’re saving a database query for each option not already loaded. Be sure all you options are present in the options table, specially when you add new options and the user does not save them from the administration panel. Update the new options into the database with default values.

In my case, another updated plugin added 10 new options and no one saved them on its administration panel. So every page load in the blog was running 10 useless queries, over the 100 query needed to generate the whole page.