WordPress

Multiple h1 tags on a page are bad, I thought. And I would have left it at that except for something I didn’t want to do. I didn’t want to mess about isolating the h1 font that displays over a hero image just to get it to render at the size I wanted. And I didn’t want to change the h1 font size globally because it fits in neatly in the hierarchy of sizes h2, h3, etc. that I have on the site.

So I decided to look up something I took at immutable fact. That is, namely, that multiple h1 tags on a page are bad.

You can have as many h2, h3, etc tags on a page as you like as long as they are nested in order, but you should only have one big h1 to control the page. That is what I thought.

John Mueller from Google

I googled and I found a video on YouTube that John Mueller from Google did in December 2017. He was answering a question raised by someone who had more that one set of h1 tags or his page and wondered how Google viewed that.

Mueller said that provided the h1 tags made sense to highlights different parts of a page, then having them on a page are just fine.

All of which goes to show that it is worthwhile going back and revisiting facts one thinks one knows, to check whether they are still facts.

I have a website at WordPress dot com, and I am signed up to receive email updates on the latest developments.

I just received an email headed ‘Import Your WordPress Site to WordPress.com — Including Themes and Plugins’ that says

“WordPress.com customers can now copy over everything from a self-hosted WordPress site — including themes and plugins — and create a carbon copy on WordPress.com. You’ll be able to enjoy all the features of your existing site, plus the benefits of our fast, secure hosting with tons of features, and our world-class customer service.”

The advantage of hosting a site on WordPress dot come is that Automattic (the company that owns WordPress dot com) looks after security.

Non clickable menu items are useful when you don’t want people clicking them. So, you may ask, in what circumstances might you not want people clicking on them?

Well it can be where you have products in categories and you want people to look at the products within the categories. What you don’t want them to do is click on the superior menu item and see all the products in all the categories, like some giant never-ending display.

On one of my other sites I have a main menu and sub-menus for some of the main menu items. And those sub-menu items have sub-sub-menu items.

I want visitors to click on the sub-sub-menu items. I don’t want visitors clicking on the main menu item, and I don’t want them clicking on the sub-menu items.

The way to make menu items non clickable is to use a custom link. When you use a custom link you see a link field and a name. What you do is, instead of putting a URL in the link field, you put a symbol such as a hash sign #.

You have to put something: WordPress won’t let you leave the URL field empty.

So far so good and I have done that several times before. The thing is that if you leave the # in place, WordPress will read that as a link back to the home page, followed by /#.

And that is not what you want. You want the link to be a non-link. That is, you want it to do nothing at all. You don’t want the cursor to change to a little hand. You want nothing, nada.

The extra step that I learned today is that once the custom link is made, take out the # sign. Now the link is dead and the menu item is no longer clickable.

I wondered today whether I had a Jetpack and Yoast plugin conflict.

The site I am talking about is running WP 5.3.2 and I noticed today when writing a post that Gutenberg was not creating a text block automatically when I did a carriage return. I had to put the cursor on a new line to trigger Gutenberg.

Then I noticed that the Yoast SEO (Version 12.8.1) fields were not opening. I thought there may be a plugin conflict, and my first thought was in might be Jetpack. Sure enough, when I disabled Jetpack (Version 8.1) that solved the Yoast issue. I have been running Jetpack (and Yoast) for a long time, and this issue was new to me.

That said, I had to reinstall Yoast SEO because I was getting a warning that Yoast would not work with earlier WP versions – as though it did not recognise that I was on the most up-to-date version of WP.

I reinstalled WP just in case.

After reinstalling Yoast it now recognised that it was working with the most up-to-date version of WP, so that was one problem solved.

CSS and Javascript minify settings

I cleared caches (Litespeed cache) and reset the CSS and Javascript minify settings and cleared caches and optimised again.

Despite doing that I still got the problem that Yoast fields wouldn’t show unless the Jetpack plugin was disabled.

I looked in the Jetpack plugin Support forum to see whether there were reports of a Jetpack and Yoast plugin conflict. There was nothing there so I searched some other forum posts that I googled.

Reinstalling Jetpack and Yoast Plugins

There was a discussion about an issue that related to Jetpack (nothing to do with the Yoast plugin), and someone mentioned reinstalling Jetpack.

I had already reinstalled the Yoast plugin and I thought that reinstalling the Jetpack plugin shouldn’t affect anything. But I did it anyway and bingo!, I could see the Yoast fields were displaying properly.

So what is the moral of this tale? Was it the minify options I had set in Litespeed? Was it a corrupted or partial plugin update at some point?

I guess I will never know, but I saved myself chasing the problem endlessly by reinstalling the plugins.

The WordPress back end now has a setting in Tools that shows ‘Site Health’. It tells you about any issues. 

It may say you have a critical issue and should increase your PHP version to the latest version. And you thought you had because PHP version says you have 7.3 (the latest at the time of writing).

Do you have MultiPHP Manager?

Multiphp Manager was introduced by the Cpanel team with Easy Apache 4. Multiphp manager allows you to select the server default and the PHP version on a per-domain basis.

So in fact, you could have PHP 7.3 set as the server’s default PHP version but that may not be the version set for your individual domains.

To change the PHP version for the individual domains, go into cPanel and then Multiphp Manager.

Once you are in there, search for the domains and Choose the PHP version to 7.3 from the drop-down menu, and click on Apply.

You may see advanced-cache.php as a drop-in in your plugins folder.

The advanced-cache.php file is used by many caching plugins to signal that a cache is active. When this option is checked and this file is detected as belonging to another plugin, LiteSpeed Cache will not cache.

The easiest way to find out what other plugins may be using advanced-cache.php is to FTP into the server and open the file and check its contents. If it is Litespeed, it would say ‘LiteSpeed Cache’ within the file.

Which begs the question of why it is there because the way it handles caching because the LiteSpeed Cache plugin for WordPress does not need an advanced-cache.php file.

For this reason, there is no real logic in this file. So why include it at all? You will find the answer by opening the file, and if Litespeed is the active caching system you will read that:

• Setting the WP_CACHE global variable requires that an advanced-cache.php file exists.
• This variable can help to increase compatibility as other plugins can check it to determine whether or not a cache is currently being used.
• It can also help to avoid conflicts with other full page caches such as W3 Total Cache, etc.