I’ve been playing with various settings for awhile, and finally arrive to the right (and stable) one after my site broke a few times. I am pretty sure I am not the only one who wants to run his/her site on Cloudflare purely while still taking advantage of the Free SSL offered by the CDN. This post will guide you on how to setup your wordpress blog or website under Cloudflare Flexible SSL and Cache Everything page rule.
Preliminary Requirements
1. Your site or blog should be already using Cloudflare DNS.
Follow this tutorial (placeholder, to be updated) on how to transfer or resolve your DNS through Cloudflare.
2. Cloudflare official plugin installed in your site.
Cloudflare Flexible SSL
By default, Flexible or Universal SSL is already activated when a website is added to Cloudflare, even with only a free plan. However, utilizing it is optional since not all WordPress users is ready for SSL utilization or HTTPS.
Step-by-Step Procedure on How to Activate Flexible SSL on WordPress
Be careful to follow this steps by order. Read each step carefully and understand it before making changes in your site. Skipping any part of these may put you and probably all your visitors on trouble accessing your wordpress site.
1. Login to your hosting account and access your home directory where your blog resides. Look for wp-config.php in the root directory. Edit it using code editor (if you are using CPanel) and add the following lines:
/**
*Fix possible redirect loop when HTTPS is forced
*/
if ( isset( $_SERVER['HTTP_CF_VISITOR'] ) && strpos( $_SERVER['HTTP_CF_VISITOR'], 'https' ) !== false ) {
$_SERVER['HTTPS'] = 'on';
}
If you do not have access (which is pretty unlikely) or just do not know how to do this, install the Cloudflare Flexible SSL plugin. This plugin does the same thing. Basically, this avoids the redirect loop when you forced HTTPS in Step 3.
2. Browse your website through HTTPS instead of HTTP. This is best done through a Incognito Tab or a separate browser. Do not do this on the browser you are using to manage your site. Or else, you need to Clear all browser cache and history since you will be always redirected to HTTPS. If pages and articles load fine, then you are good to go to step 3. If it isn’t then probably some of the resources of your website such as javascript and css is still loading under HTTP.
If you encounter non-loading elements, install the SSL Insecure Content Fixer plugin. Usually setting the plugin to work in Simple mode is enough to fix the insecure content. If not try to use the content or widgets option. Do not select more than this especially if you are on a shared hosting. Select recommended HTTPS detection. Check if elements loads fine now by repeating Step 2. If it doesn’t then something should be done manually. Right click in any part of the page then Inspect Element. Then switch to Console tab. Look for elemets that are blocked or still loaded under HTTP and manually edit it. It may be in your theme or posts. Check this guide (placeholder, to be updated).
3. Once your website loads fine under HTTPS, add a page rule in Cloudflare to forced all traffic to HTTPS protocol:
The rule should follow the pattern *your-domain.com* and Always use https to on. Although there are other ways to forced HTTPS (like through .htaccess) , it is still best done by Cloudflare since it can adjust itself when problems arise. More over this later.
It will take some time before the rule is implemented in your site. To check it, open an Incognito Tab and type your site address in HTTP. It should be redirected to HTTPS if the rule is already active.
4. This is an optional step. Change your WordPress URL and Site URL to HTTPS instead of HTTP (under Settings > General). This way, all other resources like images and internal links will be using HTTPS instead of HTTP. This will lower the load (on the server and as well as the response time) since you will be skipping the step of rewriting URLs to HTTPS. You can try disabling the SSL Insecure Content Fixer plugin after doing this. Some of webmasters do not recommend changing this option but it works in my case.
Cache Everything Rule
If you have notice, all other options were deactivated when HTTPS is forced. At first, I thought it was impossible to cache pages in HTTPS since they are served in SSL. However, I look for evidence and tested them if my assumption is correct. It was wrong. Pages even served through HTTPS can still be cached by Cloudflare. Here is a part of the Page Rule guide from Cloudflare Support:
Advanced Examples 4) Where a request matches multiple rules. Let's say there are three page rules for example.com: A. That matches requests with the URL pattern "*example.com*" and forwards requests to "https://www.example.com$2". B. That matches requests with the URL pattern "*example.com*" and is set to cache everything. C. That matches requests with the URL pattern "*example.com/dynamic/content/index.html" and is set to bypass the cache. A request to http://test.example.com/dynamic/content/index.html would match all three rules and the rules would be applied from top to bottom. As a result, a request for this resource would first be forwarded to https://www.example.com/dynamic/content/index.html and then added to our cache. The last rule here is effectively ignored, as the page rules tell CloudFlare to serve the content from our cache before telling CloudFlare to serve the content from the origin server. CloudFlare will only serve the content once, either from cache or the origin, so we'll do whichever is dictated to come first in the case of a conflict.
Source: Is there a Tutorial for Page Rules
As you can see on Rule A, all requests on the example.com domain will be forwarded to HTTPS. Once forwarded, the page requested will be cached by Cloudflare under Rule B. So, it is possible to implement Cache Everything even you are using Flexible SSL.
Setting Up Cache Everything Rule
1. First, look for the Rename wp-login.php plugin and install it. Rename your login url to something like “wp-admin-wp-login” or anything that has the wp-admin in front. This will be your new login url. The need for this is seen on Step 3.
2. In Cloudflare dashboard, go to Speed tab. Make sure all auto minify option is unchecked and Rocket Loader is off. This is because this settings interfere on some plugin you already have with your WordPress installation.
I am using the Autoptimize plugin to handle my css and js files and it will be redundant they will pass through Cloudflare minification. If you use any other caching solution like W3 Total Cache and WP Super Cache, it is best to leave this options unchecked. Rocket Loader is known to break sliders and other resources that rely on Javascript. Basically, this is a trial and error step to see if your site performs as it should be when these options are activated.
3. Add a page rule to exclude the wp-admin folder from caching:
This way, you will not encounter problems due to Cloudflare caching all all of your website including the backend management. Is it required to change the login url to the wp-admin prefix for it to be covered by this rule and to prevent issues on cookies and caching. You will encounter problems logging into your dashboard if you skip this step and Step 1. Another issue about backend management can be found on the last part of this article.
3. Next, add a new one to set the Cache Everything rule:
Set the Edge Cache Expire TTL to Respect All Existing Headers and Browser Cache Expire TTL to 8 days. This setting is a safe start when implementing Cache Everything rule.
If your site is mostly static and does not update fast (you are posting only few times a week), you may want to change the Edge Cache Expire to another value. This option sets when will Cloudflare attempt to access all the resources in the origin again and replace its cache for a new one. This setting will increase the bandwidth usage on your hosting when set to a shorter span of time. The Browser Cache Expiry sets how long the whole page, images, javascript, css etc to be cached in the user’s browser before it will considered expired. You can set it to a longer time or shorter time instead of 8 days. The main difference between the two is that edge cache is a transaction between Cloudflare and your hosting server while browser cache is between Cloudflare and the user’s browser.
Note: If you are using a caching solution like WP Super Cache, also set the Cache Timeout to the same value as Browser Cache Expiry. In this example, 8 days is equal to 691200 seconds.
4. Install the Sunny plugin.(Connecting CloudFlare and WordPress).
Let’s say, your website is already being cached by Cloudflare and suddenly, you need to update a post for some changes. You updated it on your backend and expected to see the updated post when you visited the article. Then, you see the old copy of the article even you reloaded the page many times! Freak out? Well, it is because the page is being served from Cloudflare’s cache. You can fix such in manually purging the cache through Caching > Purge Individual Files and input the article address. This is a great hassle for most of us. To make things easy, the Sunny plugin will automatically do this for you. The plugin will automatically purge the post, category, tag and homepage when you updated or posted an article. And, make sure to tick the Hide Admin Bar checkbox. Other options are personal preferences.
You should have the following values under Page Rules by now*:
*your own domain instead of spideylab.com.
Verifying if Cloudflare Works
How do you know if Cloudflare cache works accordingly? You can test your site on sites such as Webpagetest.org or Pingdom.com or through a Live HTTP Header Addon in your browser. When you use Webpagetest.org, make sure the site is running on CDN (100%). It can be seen on peformance tab that the domain url should be marked as checked in CDN column. Under content tab, With the same url, click it and look for “Expires” in reponse header. The Expires time should reflect the Browser cache value you set on Step 3 above. Or better look for cache-control value of “public, max=age=691200”. 691200 seconds is equivalent to 8 days.
For static content like images, the marker is the value of CF-Cache-Status as “HIT” or “REVALIDATED”. The blog homepage will return “MISS” as CF-Cache-Status when some of the called php functions is loaded inside the wp-admin folder. One example is the admin-ajax.php. Some plugins (javascript) rely on this.
Drawbacks of the Setup
SSL is Slower. Since the page content will travel via SSL, there is a measurable impact on response time/speed especially if it is the user’s first time visiting the site. However, this is not a major concern for some including you that you want to setup your blog/site to use HTTPS.
Preview Tab. If you are previewing a post before publishing, you may run into a problem that the preview tab does not update too. It is because it is being cached by Cloudflare. Currently, other than upgrading to a paid plan to have more page rules available, there are no possible way to fix this using this setup, atleast automatically.
If you are having issues with the preview tab and decided to exclude it from being cache, set a page rule with this pattern:
*yourdomain.com/*preview=true*
This will instruct Cloudflare not to cache the preview pane/tab when you are previewing a post. For me, it will be a good thing to replace the force HTTPS page rule with this one if you are always previewing your post. However, If you did such, when someone visited your blog/website for the first time, he/she may not be served a HTTPS page. Nonetheless, once he/she started navigating on your site, the HTTPS protocol will kick in because you set your Site/Wordpress URL to the HTTPS format.
SEO Considerations
Even though Google announced that HTTPS will be a ranking factor on search results, its impact is very minimal. Personally, I set my blog to use HTTPS because I am more comfortable seeing the padlock icon while administering or simply browsing my articles. 😀
Google Search Console/Webmasters
You do not need to add the HTTPS version of your site to Google Search Console as the HTTP pages will be automatically redirected to HTTPS. But, make sure the sitemap you submitted to Google is working properly.
Note: This sounds okay at first as my articles are still being indexed by Google. However, I ran into issues that statistics shown in the Search Console is inaccurate. Maybe because I added my site with the http:// in front. Finally, adding the HTTPs version will make no harm.