Category Archives: HOWTO’s

any post that is a HOWTO will be posted here

WordPress, HTTPS, CDN and W3 Total Cache – Take 2

I’ve previously mentioned some of the workarounds of using the excellent W3 Total Cache plugin with a CDN and utilising HTTPS on some pages. The heart of the matter is that some CDN providers do not provide Custom HTTPS support out of the box or do but with a normally large monthly fee attached, some like the excellent MaxCDN will provide free shared SSL support but that is on there own domain, for example for this website, using MaxCDN my HTTPS domain for CDN is stswebsite-somersettechnica.netdna-ssl.com.

The Problem

By default when you configure W3 Total Cache with a CDN it assumes that your CDN hostname is the same for HTTP or HTTPS. However for providers like MaxCDN and people that don’t want to pay or simply merit the costs of Custom HTTPS support, this means, that as before without disabling CDN on HTTPS pages you would get a mixed content error or worse the CDN elements may fail to load at all, something especially true with Google Chrome.

The Solution

We stumbled upon a solution while chatting with the W3 EDGE team about the issue that there currently exists a way to specify the HTTPS CDN hostname separately from the HTTP hostname. It appears that this feature request was completed some time ago but never made its way into documentation, and the solution is remarkably simple and requires no code changes or additions to get working.

w3tc-cdn-settingsYes it is that simple! in case the image is unclear, in the replace site’s hostname with field, simply supply a comma separated list of hostnames in the format

cdn.httpdomain.com, cdn.httpsdomain.com

and W3 Total Cache will do the rest for you. If you take a look of our Contact page source then you will see that things like CSS files are now loaded from the different HTTPS endpoint compared to the other pages on the site.

If you are a MaxCDN or NetDNA customer you can find your HTTPS domain very easily, login to your MaxCDN/NetDNA portal, go and manage your Pull Zone, there should be a tab called SSL, simply make sure the enable shared SSL option is ticked and save your settings, then the SSL URL should be shown on that same tab if it wasn’t already like in this screenshot:

maxcdn-ssl

Now you can enjoy faster more consistent page load times even on HTTPS without causing an extra drain on your server or your wallet.

Use WordPress and Gravity Forms to submit a ticket to Sirportly

We recently moved our support system from Zendesk to Sirportly as its a cheaper and much cleaner and simpler solution. what i’ve been trying to do for sometime now is to be able to have a form on our site for general contact queries (as well as an old fashioned email address) that would log a ticket in a seperate channel on the support system, the zendesk implementations didnt seem to allow this, with Sirportly however they had basic remote forms which generate a html form that you can embed on a site which is great, just what we wanted.

If you read around you will know that embedding a simple html form on a wordpress site can be challenging in the least at times, so i wanted to avoid that, i already had gravity forms installed from some old historic (no longer used) forms so thought i might be able to hook into that and i found out we could. using the gform_post_submission hook we are able to do just that! so i set about creating a function that hooked in and took the gravity forms data and submitted it to sirportly and came up with a basic “dirty” function, i’m calling it dirty because i’m sure theres a better way to do things most likely via there API and with a gravity forms addon and it also creates an entry on your site too (free backup?), it also doesnt detect errors on the sirportly side (eg with the post), before i get to the code, a little bit of setup is required:

On the Sirportly side, you need to create a remote form as per the docs here: http://www.sirportly.com/docs/admin/ticket-submission/remote-forms you have to fill in the success and failure redirection but we wont use this: i just put in the website home page to allow it to go through, i also deselected include custom fields (but with some manual work this could be made to work also as its only extra fields) then click on test/view form markup to see the html, the most important piece of info you need from here is the form post url, it will be in  a format similar to: https://yoursite.sirportly.com/remote_form/formnumber where formnumber is the actual remote form id, keep this for later!

Next import the following form to gravity forms, its just a basic contact form: but helps speed up matters – remember to disable all notifications on the form (you dont want 2 lots of emails now do you!), save the form and take note of its form_id , you’ll need this now.

all thats left to do is link together with some custom code that does the magic, add the following to your functions.php file in your theme (or custom_functions.php within the custom folder if you use thesis) – you may not need the php opening and closing tags – this is just for the benefit of the syntax highlighter

<?php

//edit this to match the form id matching the form you want to post to sirportly for me it was form_id 3
add_action("gform_post_submission_3", "post_to_sirportly", 10, 2);

function post_to_sirportly($entry, $form){

//numbers in here should match the field ID's in your gravity form
$post_data['name'] = $entry["1"];
$post_data['email'] = $entry["2"];
$post_data['subject'] = $entry["3"];
$post_data['message']= $entry["4"];

foreach ( $post_data as $key => $value) {
$post_items[] = 'ticket[' . $key . ']' . '=' . $value;
}

$post_string = implode ('&', $post_items);

//edit this to the post url in the generated HTML for your sirportly remote form
//create cURL connection
$curl_connection = curl_init('https://yoursite.sirportly.com/remote_form/formnumber');

//set options
curl_setopt($curl_connection, CURLOPT_CONNECTTIMEOUT, 30);
curl_setopt($curl_connection, CURLOPT_USERAGENT, "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)");
curl_setopt($curl_connection, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl_connection, CURLOPT_SSL_VERIFYPEER, false);

//we dont want sirportly to redirect us as we are allowing gravity forms to handle things
curl_setopt($curl_connection, CURLOPT_FOLLOWLOCATION, 0);

//set data to be posted
curl_setopt($curl_connection, CURLOPT_POSTFIELDS, $post_string);

//perform our request
$result = curl_exec($curl_connection);

//close the connection
curl_close($curl_connection);

}

?>

now on line 4 above, edit the action so that it only targets the form you created earlier, in my case it was form_id 3 hence the value, then take the POST url you grabbed from the Sirportly remote form html earlier and replace the url in the curl_init statement with it, save the file and upload it and test your form, if all worked you should be able to successfully submit the form and it will post it off to sirportly and you will get a nice email in your inbox saying a ticket has arrived!

now our contact page has a great form and we get it all logged through sirportly so that we don’t lost track of queries that come in via the website.

Nginx and SSL – PHP Redirect Loops

Small post, I’ve been struggling a little with getting ssl to work reliably with https. specifically relating to the following piece of code:

fastcgi_param   HTTPS   on;

Lets wind back, I can get HTTPS working with nginx no problem and the above provided I do the following, maintain 2 vhosts for the same domain, one for http and one for https. The only difference is that the above line is present in the HTTPS vhost’s PHP block.

However thats messy, I either have to maintain 2 vhosts or then deal with extra includes, which just asks for trouble to maintain. Nginx has supported combined HTTP and HTTPS vhosts for some time, so I looked at how I could make this work within a combined vhost. with a little bit of IF magic (yes I know ifisevil) I can add the following to my fastcgi_params file and just forget about it 🙂

set $ssl off;

if ($ssl_protocol != "" ) {
set $ssl on;
}

fastcgi_param   HTTPS                   $ssl;

Now PHP scripts will correctly detect SSL status and work correctly, no nasty redirect loops (particularly with WordPress) and nice clean vhosts and easy management. Hopefully the great team at Nginx can convert this bit of code into an actual variable in the SSL module which would probably be faster at higher traffic levels