James Parsons

Update Old WordPress Post Dates Automatically on a Schedule

James Parsons — Wed, 15 Mar 2023 07:04:51 +0000

It’s pretty trendy now to show the “Last updated:” date on your blog posts instead of the “Published:” time. It’s arguably better for SEO, as both users and search engines like to see you do some housekeeping from time to time.

The only downside is, if you aren’t doing that housekeeping, some of your posts may be displaying a super old “Updated” date.

So, I developed a simple PHP script to grab a random post and update it, therefore resetting the “Last modified” time:

require('/home/full/path/to/public_html/wordpress/wp-blog-header.php'); // replace this with full path to your WordPress directory
$the_query = new WP_Query( array ( 'orderby' => 'rand', 'posts_per_page' => '1' ) );
while ( $the_query->have_posts() ) : $the_query->the_post();
	wp_update_post();
	the_title();
endwhile;
wp_reset_postdata();

Copy this code and put it in a new file called something like “update-random-post.php”, then upload it to your server.

Finally, set up a cron job and run it as often as you’d like, either with an external cron like EasyCron.com or on cPanel.

For example, if you run this every 6 hours, it will randomly update about 28 posts per week. If you have 1,000 posts, every post on your site will be updated about every 8 months on average.

You can adjust the frequency or the selection arguments to whatever you’d like.

Update: If you want some variation in the time that this runs, I recommend adding this to the top of this PHP script:


sleep(rand(1,10800)); // sleep for a random amount of time between 1 and 10800 seconds (3 hours)

Cron timing is pretty rigid, so if you choose every 6 hours, you will see 1:48 AM, 7:48 AM, 1:48 PM, 7:48 PM, and so on. Adding a random sleep timer beforehand helps randomize this a bit.

Once your script is modified and uploaded, here is the cron command you can use to run it on a schedule:


wget -O - -q -t 1 --timeout=0 https://www.yourdomain.com/yourscript.php

The post Update Old WordPress Post Dates Automatically on a Schedule appeared first on James Parsons.

Fix cPanel “SSL Cannot Currently Accept Incoming Requests”

James Parsons — Mon, 22 Aug 2022 22:13:10 +0000

While adding a new domain to my WHM/cPanel installation, I received the following error:

The “cPanel (powered by Sectigo)” provider cannot currently accept incoming requests. The system will try again later.

After digging into this issue a bit, it looks like this had to do with a permissions issue.

To fix this, open Terminal and paste in the following:

find /var/cpanel/ssl/domain_tls/ -mindepth 1 -maxdepth 1 -name .pending_delete -prune -o -type d -not -perm 755 -exec chmod -v 755 {} \;

Then, run AutoSSL again and your certificate will finish installing.

Credit to Rex (cPanel user “cPRex“), a cPanel Staff Member.

The post Fix cPanel “SSL Cannot Currently Accept Incoming Requests” appeared first on James Parsons.

Cloudflare May Hurt Your SEO and Lose Backlinks – How to Fix This

James Parsons — Tue, 18 May 2021 23:39:18 +0000

Cloudflare, in many ways, has a positive impact on the load times and performance of a website, and therefore it has demonstrable SEO benefits. It’s often found on articles and in lists of services that can help improve your SEO.

There’s one little thing that I discovered that is a problem with Cloudflare. That problem is called “Broken Link Checkers”.

What are broken link checkers? They are usually a plugin or an app that checks all of the links on your site to see if any of them are broken. For WordPress, the most popular example is appropriately named “Broken Link Checker“. It masquerades as a version of Chrome with a specific user agent, checks each of the websites that you’ve linked to in your blog posts, one by one, and notifies you if any of them are unreachable.

Ok – what is the problem here?

Cloudflare is very efficient at detecting bad visitors and bot traffic, but since these link checkers are essentially bots, Cloudflare blocks those important checks. This tells other webmasters that your link is broken, and there’s a good chance they’ll remove it. This is not good.

Checking links to see if they are alive and removing the “dead” ones is good housekeeping, and we can’t blame the webmaster for this. At the time of writing, this plugin has over 700,000+ active installs and counting.

I’ve personally removed links to articles that showed up as “Forbidden” or “Server Not Found” in the past, but this is something I have to be aware of now that Cloudflare is becoming increasingly popular. At least now, you can make sure that you’re not one of these webmasters who is losing valuable links to Cloudflare.

Here’s how to fix this:

When you pick through the files of the Broken Link Checker plugin, you can find their checker under the following directory:

/modules/checkers/http.php

At the time of writing, around line 178, you’ll see the following user agent is used by this plugin to check for broken links:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36

Great, now we have something to work with.

Log in to Cloudflare. Click Firewall, Firewall Rules, then “Create a Firewall Rule”. You want your new rule to look something like this:

What we just did here is tell Cloudflare to allow all users with user agents that match the one used in the Broken Link Checker plugin. This way, your links will never show the response code “Forbidden” when this plugin is checking to see if your link is still alive.

Screaming Frog is a popular SEO spider tool, and they too have a broken link checker. If you wanted, you could whitelist their user agent as well, which is:

Screaming Frog SEO Spider

There are likely other user agents used in various plugins for other content management systems – if you have any, feel free to let me know in the comments down below and I will expand this list.

The post Cloudflare May Hurt Your SEO and Lose Backlinks – How to Fix This appeared first on James Parsons.

Remove Lazy Loading on First Image in WP Rocket for PageSpeed Optimization

James Parsons — Sun, 09 Aug 2020 04:16:12 +0000

With Google’s new PageSpeed update called “Core Web Vitals”, having a fast-loading website, or at least, a website that appears to be fast-loading, is very important. Lazy loading is great for images that are off of the screen, but blog posts typically have an image at the very top of the post, so lazy loading these images can cause problems.

Enter WP Rocket. WP Rocket lazy loads images, and has several ways to disable lazy loading on specific images. The problem is, all of your images likely share a similar CSS class, so the methods in the current version of WP Rocket will not let you disable a specific image in your post content programatically.

Since your first image in your post doesn’t load until the entire page is loaded, this hurts your “First Contentful Paint” score in Core Web Vitals. They want to see that image show up as quickly as possible to give it the appearance that it is loaded more quickly for user experience – even if your site is technically loading faster, it appears to be loading slower if your above-the-fold images are lazy-loaded.

What we need to do to improve your score is only disable lazy loading on the first blog image.

If this sounds like something you’re looking for, my code might be of some use to you. I’ve searched for a solution with no success, but I found a handful of other people looking to do the exact same thing.

So, I wrote some code to make this work (add to your functions.php file in your theme):

/**
* Disable lazyloading from first blog image
*/

function add_responsive_class($content){
	if ( is_single() ) {
        $content = mb_convert_encoding($content, 'HTML-ENTITIES', "UTF-8");
        $document = new DOMDocument();
        libxml_use_internal_errors(true);
        $document->loadHTML(utf8_decode($content));

        $imgs = $document->getElementsByTagName('img');
        $img = $imgs[0];

        if ($imgs[0] == 1) { // Check if the post has images first
	        $img->setAttribute('class','alignnone size-full remove-lazy');
	        $html = $document->saveHTML();
	        return $html;
	    }
	    
	    else {
		    return $content;
	    }
     }
     else {
	     return $content;
     }
}
add_filter ('the_content', 'add_responsive_class');
		function rocket_lazyload_exclude_class( $attributes ) {
			$attributes[] = 'class="alignnone size-full remove-lazy"';
			return $attributes;
		}
add_filter( 'rocket_lazyload_excluded_attributes', 'rocket_lazyload_exclude_class' );

Here’s what this does:

1. Only apply this to blog posts. If you have custom post types, you may want to replace this “is_single()” line of code to something that only focuses on posts in specific categories, with something like this:

if(in_category(array('1', '2', '3', '4', '5')) ) {

2. The content is loaded, decoded, and the images are found.

3. If the post has images, it will take the first image (or image #0) and add the class “remove-lazy” to it, so we can disable lazy loading with this unique class name later.

4. If the post does not have any images, it just returns the content as it normally would.

5. The next filter is taken from the above link on WP Rocket’s website. It excludes lazy loading on any image with the class “remove-lazy”.

If you don’t use full-size images in your WordPress posts, or you align your images differently, you might have to tweak some of these lines that say “alignnone” and “size-full” to match the settings that you use for your first image in your blog post. In my case, I never add custom alignment and I always use full-size images.

You can see this in action on any post on my company blog, here.

If this helped you, if I missed anything, or if you have anything you’d like to add, please let me know in the comments below!

The post Remove Lazy Loading on First Image in WP Rocket for PageSpeed Optimization appeared first on James Parsons.

cURL and file_get_contents Functions Stop Working With SSL in cPanel

James Parsons — Tue, 02 Jun 2020 10:51:52 +0000

There’s an issue that suddenly started affecting websites on May 30, 2020 that breaks cURL and file_get_contents. This has to do with how cPanel handles external SSL requests, even if you have an installed (and properly working) SSL certificate.

Here are some of the errors you may see in your error_log file:

PHP Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

file_get_contents(): Failed to enable crypto

file_get_contents(https://example.com): failed to open stream

You can read more about cPanels official statement here: https://support.cpanel.net/hc/en-us/articles/360049424193-PHP-Functions-failing-due-to-invalid-SSL

Well, I applied their hotfix, and it didn’t do anything.

After messing with my sites for 6 hours, I found that the simple fix is adding a single line to your PHP.ini file.

If you’re using WHM with cPanel, open MultiPHP INI Editor.

Then, click editor mode.

In a new line under [PHP], paste this line: openssl.cafile=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

Click save

Reboot your server

This is the location of my TLS CA Bundle on CentOS 7, but depending on your operating system, it may be in another directory, in which case you’d have to modify this line a bit.

For example, on some servers, this file may be here:

/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
/usr/local/etc/openssl/cert.pem

I hope this helps somebody. I told my host about it and they said several other customers were having the same issue and they were grateful that I shared this information as they had no clue how to fix it.

The post cURL and file_get_contents Functions Stop Working With SSL in cPanel appeared first on James Parsons.

WordPress jQuery is Render-Blocking in PageSpeed Insights

James Parsons — Fri, 14 Feb 2020 11:50:10 +0000

After running my site through Google PageSpeed insights, I noticed that all of my JavaScript was being deferred except for the jQuery that comes with WordPress.

This was dinging by PageSpeed insights score, as it was telling me to eliminate the render-blocking resource (jQuery 1.12.4). My caching plugin wasn’t able to defer it along with the rest of my site’s JavaScript code, as it’s a core element in WordPress.

To resolve this, I had to deregister jQuery, and replace it with a new version from jQuery.com:


/**
* Remove built in jQuery and replace with hosted version to improve speed, prevent render blocking, and defer
*/

function my_enqueued_assets() {
wp_deregister_script( 'jquery' );
wp_enqueue_script( 'script-name', '//code.jquery.com/jquery-1.12.4.min.js', array(), '1.12.4' );
}
add_action( 'wp_enqueue_scripts', 'my_enqueued_assets' );

I’m pretty sure all of the latest versions of WordPress load 1.12.4, but check the source of your WordPress website to ensure that yours is the same.

This helped save nearly 1 full second from my page load time, and my score went up 6 points. Not a drastic difference, but still a welcomed improvement.

Oddly enough, when I tried using the Google Hosted Library with the above code, it wasn’t able to defer it either:

https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js

So, I stuck with the jQuery.com hosted version linked above instead.

I’m using WP Rocket for caching, but this should also use with other caching plugins, or plugins that help to defer javascript.

Please let me know if this helped you in the comments below!

UPDATE:

There’s a second method that does the job as well; installing the plugin “Async Javascript”.
After installing, in the settings, there’s an area under “Quick Settings” that says “Apply Async”.

It’s important to check your console for JavaScript errors and make sure that it doesn’t break jQuery. jQuery can sometimes break when loaded with async or defer, but on my particular instance, it worked perfectly.

UPDATE June 2020:

Most of these methods are outdated. Here is a much more current and efficient version:

add_filter( 'wp_enqueue_scripts', 'replace_default_jquery_with_fallback');
function replace_default_jquery_with_fallback() {
    $ver = '1.12.4';
    wp_dequeue_script( 'jquery' );
    wp_deregister_script( 'jquery' );
    // Set last parameter to 'true' if you want to load it in footer
    wp_register_script( 'jquery', "//ajax.googleapis.com/ajax/libs/jquery/$ver/jquery.min.js", '', $ver, false );
    wp_add_inline_script( 'jquery', 'window.jQuery||document.write(\'