<p>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.</p>

<p>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.</p>

<p>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. </p>

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

<p>Here's the code.</p>

<pre><code>return array(
    '*' =&gt; array(
        'cpTrigger' =&gt; 'yourtrigger',
        'devMode' =&gt; false,
        // etc. of yours

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

    'secure.domain.com' =&gt; array(
        'siteUrl' =&gt; array(
            'en' =&gt; 'http://secure.domain.com/en/',
            'ru' =&gt; 'http://secure.domain.com/ru/',
            'sv' =&gt; 'http://secure.domain.com/sv/',
        )
     )
 }
</code></pre>

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

CC BY-SA 3.0
2014-07-24T03:33:19.590Z
2014-07-24T03:33:19.590Z
narration_sd
<p>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:</p>

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

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

<p>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...</p>

CC BY-SA 3.0
2014-07-23T20:03:39.713Z
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!
narration_sd
CC BY-SA 3.0
2014-07-23T20:17:36.077Z
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!
Josh Angell
CC BY-SA 3.0
2014-07-23T20:18:21.430Z
Also completely hilarious you called me a "real PHP guy"!
Josh Angell
CC BY-SA 3.0
2014-07-24T03:09:30.790Z
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 ;)
narration_sd
CC BY-SA 3.0
2014-07-24T05:35:54.280Z
Awesome! Can't believe I didn't think of your other answer, it seems so obvious I!
Josh Angell
CC BY-SA 3.0
2014-07-24T06:12:00.310Z
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...
narration_sd
CC BY-SA 3.0
2014-07-23T10:26:15.967Z
2014-07-23T10:26:15.967Z
Josh Angell
<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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 <a href="https://secure.domain.com" rel="nofollow">https://secure.domain.com</a>, while the Live View iframe is called at <a href="https://www.domain.com" rel="nofollow">https://www.domain.com</a>, 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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

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

<p>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. </p>

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

<config><cache><cloudflare><live-preview>
What configuration does Craft need to enable Live View on hoster CloudFlare with SSL/https CP?
# What configuration does Craft need to enable Live View on hoster CloudFlare with SSL/https CP?

(Asked by: username_0 on 2014-07-23)

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 ;)

**Tags:** config, cache, cloudflare, live-preview

---

## 2 answers

### Answer by username_1 on 2014-07-23. Score: 4 | Accepted answer

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...

> **Comments:**
> **username_0**: 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!  
> **username_1**: 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!  
> **username_1**: Also completely hilarious you called me a "real PHP guy"!  
> **username_0**: 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 ;)  
> **username_1**: Awesome! Can't believe I didn't think of your other answer, it seems so obvious I!  
> **username_0**: 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...  

---

### Answer by username_0 on 2014-07-24. Score: 1

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


---

