With just over 2 billion websites on the world wide web, forever increasing second by second and minute by minute, a high percentage of websites don a .com domain. In fact, almost 75% of all globally registered TLDs are .com — that’s just over 150 million.

While most tend to choose and use .com as their preferred extension, there’s a growing number of personal and corporate brands selecting non .com domains to represent their digital presence.

There are more than 500 million blogs out of 1.7 billion websites in the world. Now try to imagine how many links are in the world? Exactly, there are likely just as many web links as there are stars in the universe.

With over 200+ factors to rank websites in search engines, primarily Google, a healthy backlink profile carries substantial weight in whether or not a site ranks well or ever finds the light of day on Google’s page one search results.

Many bloggers, myself included, are so focused on producing content in hopes of increasing visibility and search ranking, that we often forget about the simple things in operating a blog.

Simple things like ensuring there are no to only a handful of all sorts of links that are not broken. The longer one blogs or the older the website, the greater the percentage for there to exist broken text and image links.

How many times have you wished to expire a WordPress Post or Page only to discover it must take action manually?

Whether to end a contest, game, sale, or product/service in the wee hours of the morning and right in the middle of a busy day of meetings, I have just the answer you’re looking for.

Today’s tutorial explores the various options available for those with a desire to expire WordPress Posts and Pages automagically.

Let’s dive in and review plugin expiratory options!

One of the most elusive topics surrounding domain investing is type-in traffic. There are many schools of thought on this topic.

In short, I define and qualify domain type-in traffic as visitors typing a domain name into a web browser and landing a single web page (not fully developed website) — completely bypassing search engines altogether.

Now many are quick to blur the lines between domain parking and domain type-in traffic. They are two different things, yet one relies on the other.

In this case, domain parking can rely on domain type-in traffic, but not exclusively. A domain can be parked and display ad links that visitors click on to generate domain parking revenue.

On the other hand, domain type-in traffic is simply the number of times visitors type in the domain into a web browser with no search engine help included.

Domain type-in traffic doesn’t automatically result in revenue although it can if the destination offers products, services, or a call to action that is in alignment with the visitor’s expectation.

It doesn’t take long after entering into domain investing to hear about the heyday of early investors buying keyword domains for the avalanche of type-in traffic.

Most domain investors, especially those early in their journey, are fast on the hunt to discover undeveloped domain gems with thousands of visits daily.

Do domains with exponential type-in traffic like the days of old actually exist today?

And if they do exist, how and where does one go about discovering, measuring, and procuring such domains?

I recently migrated a customer’s WordPress website from Bluehost to RoseHosting.

It was a good 6 year run with Bluehost, but this specific customer finally outgrew Bluehost web hosting services.

In actuality, Bluehost kept their website running on PHP 5.6 instead of upgrading to 7.x. But that’s a different story for another day.

The party was good until cart-fragments.min.js shut it down

My WordPress struggles with this given client’s website occurred after updating WooCommerce and updating to WordPress. After the latter update, the pages loaded but key elements driven by JavaScript were nowhere to be found.  But where, oh where could they be?

Oh, the sheer panic of loading your WordPress website to discover that your website has encountered a fatal error.

Sometimes it’s the white screen of death without errors. Other times it’s the white screen of death with a message about a fatal error email sent to your site administrator.

In my most recent case, it was the latter. While it’s good on one hand to know a fatal error has occurred, such messaging is utterly useless if you’re not the administrator of the website. And this is the case of today’s tutorial.

Welcome to today’s tutorial where I reveal how to retrieve engagement activity using cURL, PHP, and Facebook’s Graph API version 8.

You may or may not recall the version JS, version 2, and version 3 tutorials I produced a few years ago. Since this time, I’ve been quite busy with a myriad of other projects, and completely missed 4, 5, 6, and 7 version updates to the Facebook Graph API.

Nonetheless, I aim to help you obtain your access token and facebook engagement activity using the latest Graph API v8. Let’s get started!