In a previous question and answer, I've laid out recent experience in bringing up Craft on the combination of CloudFlare and Railgun offered as a free feature for VPS hosting at Arcustech.

The Pingdom-tools-verified performance results are very good, especially in the combination of North American and European customers that the present site is going to serve.

It was natural to test also Craft features, and only one was found to need some help to operate in this environment. This is to have the very client-useful Live View operate properly when using the Craft CP under SSL/https as the secure.domain.com DNS allows from the previous article.

What actually happens at present is that the Live View pane comes up unexpectedly blank. A look at HTTP headers on the iframe ajax loading that pane along with console messages shows why. The CP runs on https://secure.domain.com, while the Live View iframe is called at https://www.domain.com, which can never be possible on free CloudFlare, as it does not support https. It will simply be silent, and then in a long interval time out. As well, there is a CORS error in the console, which suggests that an Access-Control-Allow-Origin header needs to be present.

In fact, experiment shows that besides the unavailability of https on the www site, such an CORS header from a template (general _layout inclusion) isn't accepted, either from Craft header() or from embedded http-equiv. Perhaps this is because other CORS headers would have to be introduced within the Craft side to allow it. There may be other reasons, but clearly the situation isn't remediable from outside, at least as far as I can see. If CORS would work, still the https accesson the www CloudFlare-free coupling never will by design.

However, experimentation proves a solution. I temporarily modified the siteUrl array for some languages (in general.php) to point to the secure.domain.com site, instead of www.domain.com.

Now Live View worked perfectly for each of the languages so modified, because the iframe calls went to a url that could answer, and which was on the same path as the CP ajax caller. Success as tested, but the real site itself would no longer work through CloudFlare/Railgun, as it would no longer be sent as www.domain.com.

The evident solution is to have the CP iframe ajax load Live View pages by the exact same full URL base as it uses for its own pages. Now everybody would be happy, and there would be no need to entangle CORS as the Live View iframes would be on the same basis as their Ajax loader.

If there were any question whether this internal solution would work in all possible cases, it could be introduced by a general.php config element, so that it could also be turned off.

I would happily spend the hour to build a plugin to arrange this, but I think we are not allowed access by code framework or by license to modify Craft's internals in this area.

If anyone can see a solution from outside, to save effort at Craft, that would be a great answer.

In lieu, I'm hoping to have analyzed this problem in a way to make it very easy for our friends to provide what it needs - and if they don't with better insight than any of us intuit something the matter with such a solution, or realize that there's a better one.

Many very good surprises have indeed come that way, but not necessary here ;)

2 Answers 2


I'm not completely sure, but would setting site_url to always be whatever the server host is work in this case? In my general.php I use the following before the config array:

$protocol = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') ? 'https://' : 'http://';
$base_url = $protocol . $_SERVER['HTTP_HOST'] . '/';
define('CRAFT_SITE_URL', $base_url);

Then when you run the cp from secure.example.com the livepreview should load urls based on the same url.

I am running a couple of sites on cloudflare and it doesn't matter what domain I call them from they still all work with livepreview so I was wondering if this might be the difference...

  • Josh, that's a real PHP guy's solution, much appreciated, and since I didn't think from that environment's frame. I think it will work fine for a site without language Locales, but likely not when those are present. Let me try it when I can this afternoon, along with a solution that popped into my head last night which I also haven't had a chance to prove yet. But thanks! Jul 23, 2014 at 20:03
  • No worries - I hadn't thought of the locale issue, I guess you could append the locale segment somehow after this part, let me know how it goes! Jul 23, 2014 at 20:17
  • Also completely hilarious you called me a "real PHP guy"! Jul 23, 2014 at 20:18
  • Ok! I had another think about your method while travelling up the Strand, and decided it ought to work, even with Locale languages. And trying it, it did, just fine! Live Views come through as expected in each language. I'm still going to put up my solution, but you win the answer check on this one, Josh, deserved. Thanks again. If you're not always a PHP guy, this time, surprise surprise ;) Jul 24, 2014 at 3:09
  • 1
    Well, it was only obvious to me after I saw it ;) I also can't decide if Brandon in some conversation a) was teasing me towards this direction b) didn't realize it either c) was just bored and actually writing a parser for somesuch. So I'm still leaving that crack up about twisty little passages ;) He can deal with it for my hours... Jul 24, 2014 at 6:12

I've checked Josh's answer above, because it does the trick. I'm going to put here another approach, one that came literally in an epiphany late last night, just floated up. I enjoy it when that happens.

What we do here is just make use of multi-environmental config, in general,.php. Because the SSL admin is on a subdomain to fit with free CloudFlare, this is easy. Here's the pattern, where secure.domain.com is, wait for it, the SSL domain. Simply by naming it for a selected enviroment, we can put in a siteUrl array that has that subdomain named also, and then the twisty little caverns* within Craft path determination will use it accordingly. It works, and now you have two choices.

I'll still vote that Craft become as dynamite here as it is in almost any of it's abilities, and alter to do this internally. That's so designers and others don't have to dig around and find these technical answers. That we can make them is because each of Craft's areas of ability are so well thought out and computationally complete, of course.

That's the attraction ever, whichever kind of eyes you are using at a moment to see it.

Here's the code.

return array(
    '*' => array(
        'cpTrigger' => 'yourtrigger',
        'devMode' => false,
        // etc. of yours

        'siteUrl' => array(
            'en' => 'http://www.domain.com/en/',
            'ru' => 'http://www.domain.com/ru/',
            'sv' => 'http://www.domain.com/sv/',
        , i )

    'secure.domain.com' => array(
        'siteUrl' => array(
            'en' => 'http://secure.domain.com/en/',
            'ru' => 'http://secure.domain.com/ru/',
            'sv' => 'http://secure.domain.com/sv/',

*) a reference to a computer game which grew up alongside Unix, Adventure -- later called Zork

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.