I've been thinking about migrating TheGuitarLesson.com (which runs on WordPress) to HTTPS for quite a while now. There are many advantages of moving a site to HTTPS, there are a lot of articles online that deal with the subject, so I won't go into detail on them. Being secure is important, but for me, the most important factors were:

  1. HTTP/2 performance improvement - Sites optimized for and delivered over HTTP/2 perform 50-70 % better than sites over HTTP/1.1. HTTP/2 can only be used through HTTPS.
  2. SEO - Google is using HTTPS as a ranking signal.
  3. SSL = trust - When people see the green padlock, they feel all tingly inside πŸ™‚
  4. Referral data - Referral sources from HTTPS referrers are blocked, unless your site is HTTPS as well.
  5. More secure - Usernames and passwords are secured over unsecured connections as well.

The final push came in the form of an email from Google about a month ago:


To summarize the letter:

Go HTTPS in 3 weeks, or have a big'ol NOT SECURE notification in the Chrome browser address bar!

Reading that, and following a brief panicky moment, I realized that I can't put this off any longer. In Google's efforts to secure the Internet, it was going to slap a NOT SECURE warning on my site for all visitors to see. My site has memberships that cost money, imagine the trust my customers would feel when they encounter the warning.


This post will describe in detail everything I did during the HTTPS migration process of TheGuitarLesson.com, the problems I encountered, present a guide and hopefully offer tips to other webmasters in my situation. I wanted to have notes on everything I did, and also, this might help others in my shoes.

The Learning Phase

I am my own webmaster, and I don't have a team I can hand this sort of thing off to. Of course, I am on a managed hosting plan with Wiredtree, so they do all the server side things, but the HTTPS migration was all on me.

I started learning all about moving a site to HTTPS, what to expect, what could go wrong, what to look out for, etc. My goal was to make everything seamless, and problem free. I did 3 full days of research on the topic. By the end of my research (before actually starting the migration), I felt like a pro. When I read that some companies need months to go HTTPS (like wired.com), I smiled. Hah, it can't be that hard...

Here are the most useful articles I found on moving WordPress websites to a HTTPS connection:

In the following, I will describe all of the things that happened during the migration in detail.

So let's begin.

1. Choosing an SSL certificate provider

The first step is deciding where you're going to get your SSL certificate from. There are huge differences in price, and there are differences in the type of SSL certificates as well.

Technically speaking, the best SSL certificate is the EV certificate (extended validation), but they cost a lot of money, and are complicated since the extended validation means they not only secure your site, they also check your company's registration, paperwork, etc.

A normal SSL certificate costs $10 at namecheap, I was going to go with that.

But than I read about Let's Encrypt.

Let’s Encrypt is a free, automated, and open Certificate Authority that launched on April 12, 2016. "How can it be free", I asked myself? It's because of their sponsors, listing companies like Facebook, Google, Mozilla, Cisco, etc.

When I went to their Get started page, I was lost. This is when I wrote my hosting provider, and it turned out that they have already incorporated Let's Encrypt's free service, so they just needed to turn it on on my server.

They flipped the switch, and all of the domains on my server had an SSL certificate after about 15 minutes. All too easy.

Once you turn it on (or install another SSL certificate), you should check whether it's working here:


One more thing, the installation of the Let's Encrypt certificate created an acme-challenge directory in all of my domains' main folders, and added acme-challenge bits of code into each domains' .htaccess file, like this:

RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/[0-9a-zA-Z_-]+$

Don't be surprised by it.

2. Search and Replace database (HTTP to HTTPS)

Once the SSL certificate is in place and working, you can get on with the migration.

First and foremost, make a backup of your database. I had a backup, and ended up reverting to it 2x. Creating backups and restoring is easiest through cpanel, it takes about 2 minutes. Do not skip this step!


Once you have a backup, the first step in the actual migration process is to change all of the absolute URLs in your WordPress website's database to point to the HTTPS version of the URL, from the old HTTP.

To do this, I used the Better Search and Replace plugin. No need for MySQL commands or anything overly complicated. Just install and activate the plugin, than enter your non-HTTP URL in the Search field, and your HTTPS url in the Replace with field.

So in my case:

  • Search field: http://www.theguitarlesson.com
  • Replace field: https://www.theguitarlesson.com

Notice that it's just the main URL, with no trailing slash.

Possible errors

The first error I eventually caught was that I had a few non-www links in my database, which were not changed. I had to do a search-replace run like this as well:

  • Search field: http://theguitarlesson.com
  • Replace field: https://www.theguitarlesson.com

The second error stemmed from the fact that I had a few links where the HTTP was written using uppercase letters, so the Better search and replace plugin didn't change those. You need to check the Case-sensitive? checkbox to make the replacement run case insensitive.

3. Redirect all HTTP URLs via .htaccess

At this point, you still have 2 versions of all of the pages of your site. Not good.

You need to tell your server that all incoming traffic needs to go to the HTTPS version, instead of HTTP. This is done through a redirect command.

The official position of Apache is to do this via virtual hosts, their less preferred method is through the .htaccess file. After about 5 hours of searching, I didn't find anything wrong with doing it the simpler .htaccess way, so I went with that.

After lot's of experimenting with the different code snippets I found all over, this worked for me:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_USER_AGENT} !(Facebot|facebookexternalhit/1.1) [NC]
RewriteRule ^(.*)$ https://www.theguitarlesson.com/$1 [R=301,L]

The above code tells the server that all of the HTTP URLs have been permanently moved to HTTPS. Of course, you would change your URL in the code πŸ™‚

There is 1 line you might not need in there, the Facebook bot line. I'll get into why that's there in Step 8 of this article.

4. Testing your new HTTPS URLs

After steps 2 and 3, all the links in your site's database will have been changed to HTTPS, and any incoming traffic should be rerouted to the HTTPS version of whatever they are trying to access.

Go ahead and test a few pages of your site. Enter the old http version of any page on your site, it should automatically load the HTTPS version.

This is where you'll need to check your .htaccess redirect code as well. You see, all of the links in your WordPress database have been changed, and Wordpress takes care about redirecting traffic to your pages and posts.

The real test of your .htaccess redirect command is trying to access an HTTP version of an image on your site.

So for example, the HTTP image of my logo automatically redirects to the HTTPS version now. If the 301 redirect snippet from the .htaccess code wasn't working correctly, the old HTTP version of the image would appear in the browser:


A nice tool for this is http://www.redirect-checker.org/. It will show you whether the redirect is working, and also where it's pointing to.

It's also a good idea to run your new URL through https://www.ssllabs.com/ssltest/, to make sure SSL is running properly, like on TheGuitarLesson.com πŸ™‚


5. Testing mixed content warnings

If not all elements on an individual web page are served over SSL, you will get mixed content warnings. The green padlock won't appear in the browser:

I used the following tools to crawl my site for mixed content warnings:

The chrome browser also has a great page diagnosis tool. Hit up the Console via the F12 key, press the Security tab, and reload the page:


You'll need to fix these mixed content warnings by hand, there is no automated way that I'm aware of. Sometimes it's actually tricky catching the cause of the warning.

6. Change hard coded scripts

My site had a few code files that needed to be modified, to reflect the migration to HTTPS. The database search-replace, as outlined in Step 2. doesn't modify the files of your site.

What types of scripts am I talking about? Any file developed specifically for your website might have absolute URLs.

It's best to run a search for your old HTTP URL on your server, to find any files on your domain that have your HTTP URL hard coded.

These are the hard coded URLs I found on my site:

  • The files for the metronome
  • The Guitar Chords plugin I created, which is available on WordPress.org
  • PayPal button scripts on the site
  • Robots.txt file
  • Old redirects from the .htaccess file

If you're using a commercially available WordPress theme, from the likes of Themeforest for example, there won't be any absolute URLs in the theme files. However, if you go ahead and change any of the files (which is a bad idea), you may have some to change.

External scripts from the likes of CrazyEgg, AdRoll, Facebook, etc. may also have your old URL. Those are generally placed in the header or footer files.

7. Change the URLs in external services

Most sites will have a number of external services running in the background, where the URL needs to be modified. The most important ones are:

7.1 Google Webmaster Tools

You need to create a new property in GWT with the HTTPS version of your URL.

DO NOT delete the old HTTP one. You will be using both to test the migration in the following weeks.

Once you create the new property, there are a few more things you need to do in GWT:

  • Set everything from scratch (target country, preferred domain, etc.)
  • Submit sitemaps
  • Request indexing
  • If you have a disawow file, update it

Some people also have Bing Webmaster Tools accounts. I don't, so I can't comment on that.

7.2 Google Analytics

There are 2 things that need to be changed in the Admin section of Google analytics.

The Property Settings:

The view settings:

7.3 YouTube channel associated website

Log into your YouTube account and go to Creator studio > Channel > Advanced to change your YouTube Channel's associated website info.


7.4 PayPal IPN

If you use PayPal, you need to change your PayPal IPN URL in your account.

7.5 Think through what other external services you have running in the background

Sometimes we set something up once, and just forget about it. This is usually great, but with HTTPS migrations, you'll need to modify your URL everywhere.

Other common service providers where you'll need to go ahead and change things are:

  • CDN provider
  • Disquss comments
  • Facebook
  • Twitter
  • Ad programs
  • Payment processors
  • Email marketing service providers
  • Security service providers (malware scanners, security badge, etc.)

8. Migrating social sharing button counts to HTTPS

I saved the best for last. All of the previous steps took me about 2-3 hours, since I was prepared. No big deal really.

What I was not prepared for was the chaos the SSL migration would cause with my social media buttons.

This single step cost me 3 full days of research and experimentation, than 3 days of calmness, followed by another 2 days of research and experimentation. I'm going to spare you those 5 days now.

So here is the situation.

Facebook and Google+ do not combine the Like counts of HTTP and HTTPS pages. So if you simply migrate to HTTPS and don't bother with the FB Like and Google +1 boxes, your Like/+1 counts will be:

0 FB likes

Yes, this happened to me. I've amassed tens of thousands of Facebook likes and Google +1 votes during the years, and it all came crumbling down as soon as my URL was changed to HTTPS. Twitter doesn't show the count any more, so don't worry about Twitter.

Why doesn't Facebook take the obvious step and combine the counts of both versions of the URL? I have no clue. I found countless forums discussing the topic, WordPress has officially reached out to Facebook to try and get this resolved, but no reply.

The same goes for Google+.

So what to do?

8.1 The manual way

Personally, I prefer using the least amount of plugins on TheGuitarlesson.com, because of their overhead. Whatever I can code myself, I do. I ain't no master coder FYI. Inserting the social sharing boxes was easy enough, so I did it by hand when I created the site. Both Google and Facebook have good button generators, they're easy to use, you just have to place them into your template.

Now let's fast forward to the HTTPS migration of the social sharing buttons.

The official Facebook documentation has 2 hacks for solving this problem. It seems simple, but it's actually pretty frustrating.

To get your old FB likes back, you need to do a few things. This takes a bit of PHP knowledge, but I'll have the code included with each step.

8.1.1 Replace the sharing button code with the old HTTP version

First, start by replacing the URL in the sharing button code (which defaults to the browser URL, so the HTTPS version), with the old HTTP version. So what actually happens here, is that even though the Like button is shown on your new HTTPS URL, the button itself is loading the like count of the old HTTP URL. The disadvantage of this is that any new Likes will go towards your old HTTP URL as well, but I figure that at sometime in the future, Facebook is going to fix this whole problem, and until than, this hack will do.

Here is the PHP code I used for dynamically generating the HTTP version of the URL:

//Create non SSL version of URL

$current_uri_non_https = esc_url($_SERVER["SERVER_NAME"] . $_SERVER["REQUEST_URI"]);
$current_uri_non_https = preg_replace( '/https:/i', 'http:',  $current_uri_non_https);

So the Facebook like code became:

<div class="fb-like" data-href="<?php echo $current_uri_non_https; ?>" data-layout="box_count" data-action="like" data-size="small" data-show-faces="false" data-share="true"></div>

And the Google+ code is:

<div class="g-plusone" data-size="tall" data-href="<?php echo $current_uri_non_https; ?>"></div>

8.1.2 Add the og:url Open Graph meta tag pointing to the old HTTP page

Second, you want to use the og:url meta tag to tell Facebook to use the likes from the non-HTTPS version of the page. We will use a Wordpress action to get the code into the header. Note that I'm using the $current_uri_non_https variable that's been defined already.

function add_http_to_fb_og_canonical() {
 // Get HTTP URL from above
 global $current_uri_non_https;
 echo '<meta property="og:url" content="'.$current_uri_non_https.'" />';
add_action('wp_head', 'add_http_to_fb_og_canonical');

8.1.3 (optional) Yoast SEO plugin og:url rewrite

If you are using the awesome Yoast SEO plugin like me, you'll have an extra step. You see, the plugin injects it's own og:url property into the header. It injects the HTTPS version, since it doesn't know any better, which just confuses the heck out of Facebook.

You need to add a filter to modify the plugin's output of the og:url property through the plugin's API, specifically, wpseo_opengraph_url. Here is the code:

function update_wpseo_og_url($url) {
 $url = preg_replace( '/https:/i', 'http:', $url );
 return $url;
add_filter('wpseo_opengraph_url', 'update_wpseo_og_url', 10, 1);

If you use the Yoast SEO plugin, you can actually skip 8.1.2, since Yoast will output the HTTP url into the og:url meta tag. If you are not using the Yoast SEO plugin, you can skip this step, but you should still make sure no other plugins are injecting their own og:url property.

The result of the above steps worked right away, and both the Facebook, and Google+ buttons showed the old Like/+1 counts. Yippie!

BUT after 3 days, FB started showing 0 likes again. Not on every page, just on some pages.

Hence the next step.

8.1.4 Exclude the Facebook crawler from following the global 301 redirect

There is a simple way to "hack" into the Facebook database, and check what the Like count is in their system for any URL on the web. Just enter this URL into your browser, and change the ending URL with whatever like count you are looking for:



Notice that the only difference with the above URLs is the HTTP vs HTTPS parts.

I figured out the problem after asking for help from Facebooks's developer forum. It was something I had missed on the FB developer page linked above:

"The crawler still needs to be able to access the old page, so exempt the crawler's user agent from the redirect and only send an HTTP redirect to non-Facebook crawler clients."

Facebook has a crawler, just like Googlebot. The reason my like count was lost was because in step 3, I redirected ALL traffic to the HTTPS version of any given URL. Even Facebook's crawler bot. In effect, Facebook could not find my HTTP URL anymore, saw the redirection to HTTPS, assumed the old URL doesn't exist anymore, and even modified the object ID of my old URL to the new HTTPS one, thereby effectively losing the entire HTTP like count. Ouch.

If you go back to Step 3, you'll see the modified redirection code. It doesn't redirect Facebook's crawler anymore, so I'm hoping this might fix it. If I would have done it this way the first time around, the Like number would not have been lost in the first place... Goes to show you that even after days of research, Murphy doesn't sleep. What can go wrong, eventually will.

8.1.5 Getting Facebook to recrawl your URLs

Thanks again to Andy for helping with this part.

If you messed up somewhere, and Facebook merged your HTTP URL into the new HTTPS, fret not. After you do all of the above, you can get Facebook to recrawl the affected  URLs here: https://developers.facebook.com/tools/debug/sharing/

Just pop in your URL, you'll see all sorts of data, and press recrawl. If you did everything correctly, it will show the old like count instantly, as Facebook is redirecting to the non-HTTPS version of the page.


8.2 The plugin way

There is a plugin that takes care of all of this for you, it's called Social Warfare, and costs $29 per year. It works for both Facebook and Google+.

The way it circumvents the problem is the following:

  • It pre-fetches the like counts of both the old and new URLs, and stores them in it's own database.
  • It adds up the counts.
  • It displays the aggregate number in the Like box it generates.

$29 per year isn't that much, so I was considering using them. The reason I decided otherwise was:

  • With the Facebook button, they don't have a Like box, just a Share box. Facebook shares are more difficult to use for visitors, since they have to do way more than just click the thumbs-up image that they're used to.
  • The fact that it uses their database to display something on my site makes me a bit eerie. What if their server goes down? What if they mess up? What if they get hacked?

And anyhow, I like doing things by myself πŸ™‚

9. Effect of the HTTPS migration on SEO and traffic

The actual migration took place on February 7th, 2017.

I will be updating this section of the post regularly, to show what effect, if any, the move to HTTPS will have on TheGuitarLesson.com's organic search traffic. Google said that they will pass all of the PageRank through the 301 permanent redirect, so in theory, not much should change. Will Google even give a bit of a boost as a result of going secure? We'll see.

1 week after the HTTPS migration

Google has started showing the HTTPS version of my pages in it's results, at the same location the old HTTP pages were:


I haven't seen any real changes in my traffic count yet.

The new Google Webmaster Tools (GWT) site property has been populating nicely with the indexed pages and crawl data, no errors there either.

1 month after the HTTPS migration

03/06/2017 update: It is now 1 month after the HTTPS migration took place. Everything seems to be going well so far.

There were a few traffic fluctuations after the migration as you can see on the chart below:


Don't mind the down trend, that is normal in the guitar lesson industry going from January to February. What is interesting, is the volatility of traffic ever since the migration. Traffic hit a low on February 14th, 1 week after the migration went live. But it recovered. You can see that the dips and peaks are a bit harsher ever since, that is probably the result of the migration. Those dips and peaks represent traffic differences of 20-30%. Hopefully it will normalize soon.

In Google Webmaster tools, everything looks OK. Here is the crawl rate from the new HTTPS property, you can see a spike in pages crawled on the 11th of February, so 4 days after the migration. I guess that's when Google realized that something is going on in my neighborhood πŸ™‚


Here is a comparison of the search analytics tab from GWT. The old property is on the top, and the new HTTPS one is below. You can definitely see that the old one is loosing search hits, moving over to the new property. I think this is also a sign that the migration didn't cause any issues with Google.

Old GWT property
New GWT property

One extra thing I noticed after the migration, that IΒ wasn't expecting at all, was a boost to conversion rates. Ever since the migration, conversions have gone up by about 40-50%, when compared to the previous period.Β I'm not sure if this will stick,Β or if it's just a coincidence. It would makeΒ sense because the green secure padlock and text in people's browsers might invoke more confidence in my site, which would increase conversion rates.Β I'll report on this with the next update as well.

2 months after the HTTPS migration

04/10/2017 update: I am glad to report that everything went down without anything out of the ordinary. Here is my analytics report since the migration to HTTPS, nothing special:


Traffic is pretty much flat. No decrease, nor increase. I was maybe hoping for a slight bump in traffic, since Google has said that they treat HTTPS sites a little more favorably, but I haven't noticed anything yet.

All pages of the main site that had sitemap submitted to Google Webmaster Tools have been indexed:


I will now go ahead and migrate the rest of the site as well, the Guitar Pro tabs archive. This will be interesting as well, since this part of the site has around 45,000 pages. I'll report on the findings of this next month.

I mentioned in my previous update, that I saw a strong increase in conversion rates right after the migration went live. Unfortunately, it didn't stick, so I guess it was just a coincidence.

Similar Posts


  1. Hi Tom,
    I’m so glad it works ! Actually I struggled with this for almost 3 days, thanks God I found your article, old likes are back!
    Thanks a lot !! BIG HUG πŸ™‚
    I can share a little about my situation. I use addthis for the share buttons , really simple SSL(it performs well).
    After I transformed http to https, addthis share button(design option: Modern Responsive) still shows the old likes, while design option-Original will automatically get the https in the “data-url” attribute, even after you set og:url and data-url to http.
    I thought I can use Responsive button, that would be fine, but soon I found the Responsive share button for facebook only can share, there’s no like box. So I decided to use Facebook codes, and combine your codes “it’s done!”
    I really agree with your point about Facebook still not fix this problem. Stange.

    1. Hi Jessie, glad you found the article helpful πŸ™‚ It’s been over a year since I wrote the post, and Facebook still hasn’t made things easier for migrating likes to the https version of a page.

      I’m starting to think they won’t even bother, since they would have done it already.

      It’s really frustrating, because the Facebook hack we use to display old likes also means the new likes are being collected on the old non-https version of the page. We’ll never use that version again, so it’s just bothersome to have to use a defunct version of the page.

    1. Hi, no you won’t. There is a redirection step in the process outlined above. The juice from your incoming links will be redirected as well. I lost no ranking after transitioning to HTTPS.

  2. Hi Tom,
    I recently migrated my sites from http to https too. A lot of work, but exciting.
    To restore the FB likes I used this solution: https://really-simple-ssl.com/knowledge-base/how-to-recover-facebook-likes-after-moving-to-httpsssl/
    I entered that code in my functions.php and that worked.
    But for some reason now on certain posts I get 0 likes.
    I read what you wrote about it, but I am not sure how to to this.
    I am using the FB likebox from the Add to Any plugin.
    Is there anyway I can get those likes back?
    Here is a page with 0 likes: https://www.tina-turner.nl/blog/page/7/
    I don’t know how to get that FB likebox with every post if I decide to not use it from the Add to Any plugin anymore. The plugin author of the Add to Any plugin says you can change the og: url to the http version, but I have no clue where to do that.
    I hope you can help me.

    1. Hi there, the first article you referenced is exactly the same thing I outlined in Step 8, but since you used the really-simple-ssl plugin, you also had to insert a hack into the plugin. There is really no reason to use a plugin for going HTTPS in my opinion, as the steps are pretty simple, I outlined everything in detail in the article. You get overhead and problems that need hacking with plugins.

      This plugin you are using most likely doesn’t have the exclusion for not redirecting the Facebook crawler, that’s why your likes dropped down to 0 after a few days. I talk about this in step 8 of the article as well. Unfortunately your original HTTP likes are gone, and won’t return. This happened to me on a few pages as well before I figured it out. If you check this link, and compare it to the normal HTTP version as well, you’ll see that Facebook has joined the object ID for both versions of the page, so it deleted the old HTTP object ID, thereby deleting the old like count.

      UPDATE: It isn’t deleted, check step 8.1.5 in the guide.

      And your last question, you’re using the add-to-any social sharing plugin for displaying social buttons. Sorry but I don’t use a plugin for this, so I don’t know how you would need to hack into it.

      Sorry I can’t be of much help. All I can say is that if I were you, I would stop using the simple ssl plugin, and go the manual route.

      1. Hey there,
        I would like to help and add that what you’re saying about the old likes being deleted permanently is not true, the old likes are fortunately NOT gone. They’re never gone. I tested everything multiple times with a lot of trial and error so I figured out how their system works. They old likes are still attached to the http page, but you just don’t see it in the graph if you have an http to https redirect in place.

        All you need to do to recover them is:
        – Disable the https redirect
        – Re-scrap the http page from the Facebook Sharing Debugger Tool.
        – The old likes are back.

        Now, of course,when you re-enable the https redirect, and the http URL is re-scraped again (it will only take one person liking the page for this to happen), facebook will re-redirect it to the HTTPS version and “lose” the old likes again.

        The only way to keep them is indeed exclude Facebook from the HTTPS redirect.
        After you excluded it, re-scrap the http page again from the Facebook Sharing Debugger Tool, and the old likes will be back.
        As you mentioned, the only disadvantage to this is that also all the new likes will go to the HTTP page too, which I guess is not ideal, but it’s the only way to do it. Unless Facebook gets their s…t together and merges the likes from both pages…
        – Andy

        1. Thanks Andy, I would buy you a beer, no, 5 beers right now! With you input, I managed to get the old likes back!

          I’ll update the article to reflect the change, there were quite a few. I am using the Yoast SEO plugin, and that added the og:url Facebook metatag pointing to the HTTPS version, so that messed things up a bit as well.

          So I had to write a few lines of code to turn off Yoast’s og:url property injection, add my own og:url to point to the old HTTP version for Facebook to crawl, and get the Facebook crawler to recrawl. And presto πŸ™‚

          Thanks again!!!

          1. No problem, glad I could be of help. Yeah, the og:url gets in the way too, luckly my platform keeps it the same as the actual url, so if facebook is seeing the http page, it sees a http og:url too. But this to me is still not a definitive solution, as this right now brings issues with the newest pages and it’s not “future-proof”, as all new future pages will still get http likes/comments even if they’re https. I’m not a fan of it.
            Right now my goal is trying to find a way to embed the http version of the button only in certain old selected pages (the meaningful ones with a considerable amount of likes), and keep the https version for all the others and the future ones.
            It’s a nightmare! Haha.
            Take care and good luck with your site.
            Andy from TheSDHotel

  3. Hey there,
    Stumbled across this article and identified myself perfectly with your experience, set up and procedure, as well as frustration with the facebook likes count, when I did the https migration of my site back in January (just around a month before yours). It looks like as if I wrote this article myself! Haha, good write-up πŸ™‚

  4. Hi. This is the best article I’ve read about this problem yet, so thank you!

    How did you actually get the Facebook “like” widget to use current_uri_non_https ?

    1. Thanks, I’m glad it helps. I replace the URL in the like box code, making it dynamically generated via PHP. I’ve updated the post above with the code, I can’t insert it here into the comment because it executes on the code and generates the like box πŸ˜€

    1. You’re welcome!
      Unfortunately no. On the pages that were crawled by the Facebook bot before I implemented the extra bit of code from step 3, the like counts did not return.
      None of the other pages lost the like count afterwards though, so the code and logic works. Unfortunately for me, I was my own test dummy πŸ™‚

      UPDATE: Yes, the old likes are back! Check out step 8 in the article above.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.