Category Archives: WordPress

Tips and Tricks on WordPress usage and development. I am very passionate about WordPress, but it doesn’t work just by itself – it needs a rich environment to live and breathe in.

If you’re after theme and plugin alterations, we have a category for that.

How to add code to the header in WordPress

WordPress has a hook that lets us add arbitrary HTML code to the <header> tag of a website. Several plugins can be found that accomplish this, but it’s so easy to do that a plugin is often overkill.

Here’s how you can execute an arbitrary PHP function using the wp_head hook:

This example inserts some text into the <header> portion of the website. HTML tags can simply be written using echo, including double quotes.

  • https://codex.wordpress.org/Plugin_API/Action_Reference/wp_head

How to show a list of all articles in WordPress

There’s a handy function in WordPress called wp_get_archives(). With it we can create a lot of useful output with just a few lines of code.

To list all articles ever published on a site, we can do this:

Here we setup a list of arguments and then give it to the function, which in turn gives us a nicely formatted list of every published article.

If we set the show_post_count argument to true, and replace the type argument to something like “yearly” or “monthly”, we’ll get clickable a list similar to this:

 

  • April 2015 (20)
  • March 2015 (11)
  • February 2015 (2)
  • January 2015 (7)
  • December 2014 (4)
  • November 2014 (12)

The number in brackets shows up when the show_post_count argument is set to true instead of false.

 

 

 

We can even find out how many articles have been published on the entire site by using the wp_count_posts() function. Here’s how to use it:

$totalPosts now holds the amount published posts. We can also query drafts or posts of any particular post type too if we wanted to (such as all status updates or video posts).

  • https://codex.wordpress.org/Function_Reference/wp_count_posts
  • https://codex.wordpress.org/Template_Tags/wp_get_archives

How to fix the “Occasional White Screen of Death” Error in WordPress

In this video I’ll show you how to fix an odd phenomenon I’d like to call “The Occasional White Screen of Death”. Here’s what happened: Continue reading How to fix the “Occasional White Screen of Death” Error in WordPress

Catch this episode on my WP Guru Podcast:

How to disable JetPack nag messages in the WordPress Admin interface

I really like WordPress, and I really like JetPack. I use the plugin on many client websites, who usually have their own WordPress.com  account, which is necessary to enable the plugin successfully.

Most of them however choose not to sign up for a payment plan, which as of 2017 leads to (now rather annoyingly frequent) JetPack upsell messages at the top of the admin screen. So I as the administrator, am constantly exposed to such messages, and I was wondering how to suppress them – not being the target audience here.

Thanks to a super helpful article by Matt Medeiros I found a great solution with this one-liner of code he as kindly supplied on his website, together with his opinion on such messages:

Add this to your child theme’s functions.php file and those admin nags are history!

Thanks Matt!

How to fix the Visual Editor or Text Editor in WordPress when it’s not working

I had a weird phenomenon on a Multisite installation the other day. I can’t tell you with which update exactly it happened, as I only write a post on that site once every couple of months, but it must have been around the 4.7 or 4.8 upgrade. Here’s what was happening:

I could log into the site fine, I could display all posts in the backend fine, but editing them, or creating a new post (or page) resulted in an unresponsive editor window. Neither the Visual Editor nor the standard Text Editor wanted to accept any keyboard input. Moreover, none of the buttons could be pressed, including the Publish button.

The rest of the admin interface looked and behaved completely normal. I could even write posts from the iOS app, so fundamentally the installation wasn’t broken, just the editor part of it. Made no sense to me at all.

Things I’ve tried

I tried the usual tricks for getting rid of such a spurious affair:

  • re-install WordPress manually
  • disable all plugins
  • use a different default theme (in fact, I’ve tried several)
  • try logging in as a different user
  • since this was multisite, try writing a post on another site (same issues there)
  • since this was an installation managed from Plesk via the WP Toolkit, try more lax security settings

I probably tried other things, but none of it was making that editor working again. I didn’t understand what was going on.

The Solution

The solution came after extensive research, one part of which lead me to this thread in which Peter Luit explained a related problem that he could fix by defining a constant in the wp-confg.php file. I had never heard of it either:

Turns out that this constant is enabled by default and means that all JavaScript files are loaded with a single call, rather than multiple calls to multiple files. The idea is that, if your site is healthy, and every single JavaScript file is working fine, all of them together will execute and work fine too. However, should one in the middle not work so well, then the rest of them won’t be executing, and I guess that’s what happened on my installation.

By setting this constant to false, each JavaScript file is loaded individually, resulting in more http requests to the server (potentially making the overall load time slower), but every JavaScript file can be executed individually. If one isn’t working, none of the others are impacted. Hence, now my editor is working again, however I still have at least one JavaScript file that has an issue executing. Finding which one would be the next step.

So this constant isn’t a “fix” as such, it’s part of a debug strategy. But it’s great to have my site back up and running so I can continue to write posts.

Thanks for sharing, Peter!

How to install a free SSL Certificate in Plesk Onyx

In this episode I’ll explain how to add a free SSL Certificate for web traffic in Plesk Onyx.

First we’ll enable the Let’s Encrypt extension in Plesk, then we’ll create the certificate and prepare our subscription for SSL traffic. And finally, we’ll tweak two values in the WordPress database so that all requests will be directed to https rather than http.

Note that Let’s Encrypt SSL Certificates can only be used to encrypt web traffic between your server and a client’s browser. They cannot currently be used to secure email or Plesk itself (but who knows what the future holds).

Enjoy!

Catch this episode on my WP Guru Podcast:

Upgrade Trouble: when WordPress is asking for FTP details, but there’s no FTP server on your system

wordpress-iconI was working on a CentOS 7 server the other day that had a LAMP stack installed. It was used to host only a single instance of WordPress.

Upgrading themes and plugins from the admin interface worked fine, but curiously, WordPress core upgrades did not. Instead, WordPress was asking for FTP details every time, which also prevented auto upgrades from being installed.

This didn’t make any sense because there was no FTP server installed on the box, nor had there ever been one. But it did indicate that WordPress had an issue with overwriting core files.

The first thing I checked was that the /var/www/html directory had the correct file and ownership permissions. It all looked correct, even though I did manually set them again just to make sure. Without success. WordPress was still asking for FTP credentials.

After some research, I found that there is a setting for how WordPress accesses the filesystem when it’s upgrade time. We can define it with a constant called FS_METHOD in wp-config.php. The ins and outs are explained in the codex, under Upgrade Constants:

FS_METHOD forces the filesystem method. It should only be “direct”, “ssh2”, “ftpext”, or “ftpsockets”. Generally, you should only change this if you are experiencing update problems. If you change it and it doesn’t help, change it back/remove it. Under most circumstances, setting it to ‘ftpsockets’ will work if the automatically chosen method does not. Note that your selection here has serious security implications. If you are not familiar with them, you should seek help before making a change.

  • (Primary Preference) “direct” forces it to use Direct File I/O requests from within PHP. It is the option chosen by default.
  • (Secondary Preference) “ssh2” is to force the usage of the SSH PHP Extension if installed
  • (3rd Preference) “ftpext” is to force the usage of the FTP PHP Extension for FTP Access, and finally
  • (4th Preference) “ftpsockets” utilises the PHP Sockets Class for FTP Access.

So on this particular server, for whatever reason, WordPress did not choose the first method (direct), even though it should have. Defining this constant manually did the trick, all I had to do was add this line to my wp-config.php file:

Now updates are working as expected. I’ve never seen this problem on LAMP stacks before. Guess you learn something new every day.

  • https://codex.wordpress.org/Editing_wp-config.php#WordPress_Upgrade_Constants
  • http://wordpress.stackexchange.com/questions/189554/what-security-concerns-should-i-have-when-setting-fs-method-to-direct-in-wp-co

How to set WordPress Categories depending on the Post Title

I was working on a project the other day that required to determine which category a new post would go into, depending on the post title. This was important because posts were automatically acquired without the web interface, and in this workflow there was no way to pick a category other than the default.

In our case we wanted to use a post fix in the title to determine which category was to be picked: for example, if a post title would end with “_ONE”, it should end up in Category 1, and if it ends up with “_TWO” it would end up in Category 2.

Thankfully there’s a hook called save_post that is called every time a post is updated. At this point we can check what the post title is, determine the post fix, and set the correct category. Here’s a function that does just that:

If a post fix is not present, the categories will not be changed.

For this example I’m assuming that my categories are actually 1 and 2 on the system, something that’s not really the case. To determine the correct value set under wp_set_post_categories, I usually head over to Posts – Categories, select the category I want to use and check the URL of what WordPress gives me. Say the URL looks like this:

http://domain.com/wp-admin/term.php?taxonomy=category&tag_ID=366&post_type=post

then the tag_ID parameter hints that my category has an ID of 366, and that’s the value we need to use.

And if a post needs to go into two categories, separate the category IDs with a comma like so:

Removing the post fix before the title is displayed

Since our post fix is for internal purposes only, we may not want it to appear as part of the actual post title on the front page. But we also don’t want to remove it from every post once the category has been set and still have a reference in the admin interface. So the way to do it is to simply suppress it before out theme prints it out.

The following code will do just that: if a post fix is present, curb the title. If not, leave the title unchanged.

And there we have it. The same principle can be used if your title contains a certain keyword and you want to use it to add the post to a particular category automatically.

P2 Header Ad – Version 1.6 released

P2 Header Ad IconI’ve just released a new version of my P2 Header Ad plugin! It fixes a few issues I’ve come across in debug mode:

  • styles are now loaded via wp_enqueue_scripts hook
  • fixed a debug warning that assumed a constant rather than a value
  • verified compatibility with WordPress 4.5

There’s still a lone warning that appears in WordPress 4.5 Debug Mode. It reads something like “get_currentuserinfo is deprecated since version 4.5! Use wp_get_current_user() instead”.

This isn’t actually triggered by my plugin, but rather by the current version of P2 (1.5.8 and earlier). I’m sure the team will fix it very soon.

As always, you can download the plugin from

How to turn plain URLs into clickable links in WordPress

The marvellous P2 Theme has an interesting feature: write out a plain link, and it magically becomes clickable without explicitly adding the a href tag.

This may not be a big deal if you’re writing posts in the visual WordPress editor rather than HTML, but for those of us who like to write in HTML, it’s just one less thing to worry about.

I was investigating this feature recently, and it turns out WordPress has a built-in function that can do this: they call it make_clickable(), and it works with URIs, FTP, Email addresses and anything starting with www. The function is really easy to use too: it only takes one parameter (a string), and returns the clickable HTML code.

Let’s see how to use it in context, using the TwentyThirteen theme.

Continue reading How to turn plain URLs into clickable links in WordPress