<p>We've successfully implemented a setup that will solve your issue with several sites. Unfortunately we haven't been able to open source things yet, but this is our general process:</p>

<p>We set up a Craft install on a separate domain (or subdomain, in our case). Then we serve the content as JSON instead of html in our layout template. </p>

<p>Our entry templates are totally normal, outputting html like any other template does. This layout just wraps the whole thing in a json object (and does not include the header/footer etc).</p>

<p>Then on the ZF side, we wrote a module to pull in the data from the separate domain and output it in our app, using the normal layouts that already existed. It is also obviously heavily caching the content it receives from Craft.</p>

<p>So, ZF is actually handling all of the requests by end users, and the only things going to Craft are actually curl requests from ZF.</p>

<p>We have ZF send along a Header telling Craft that the request is coming from ZF, and then we have Craft check for that header. If it exists, it uses layout.json, and if not, it uses layout.html.</p>

<p>layout.html has a dummy version of the header and footer, and is only used for Live Preview basically. The layout.json file serves our content as json to the ZF app.</p>

<p>Here is our <code>layout.json</code>:</p>

<pre><code>{% header 'Content-type: application/json'
%}{% set response = {
    success:true,
    metadata: {
        {# some custom data #}
    },
    data: {
        meta: (head is defined ? head : {}),
        body: block('content')
    }
} %}{{ response|json_encode()|raw }}
</code></pre>

<p>So, while this doesn't mess with custom routing, it will allow you to keep your ZF app going and have Craft handle marketing/static pages.</p>

CC BY-SA 3.0
2016-06-15T18:42:00.840Z
2016-06-15T18:42:00.840Z
Dan Ott
<p>I manage our corporate marketing website, which is written in PHP and the Zend Framework and is hosted on LAMP servers.  I've been tasked with moving the website to a CMS so other folks on the marketing team can update content without having my dev team be the bottleneck for content publishing and changes.</p>

<p>However, our existing site is more of a web application, in that we use the Zend Framework and PHP code for back-end integrations with HubSpot, WebEx, etc. and various CRON jobs that hit endpoints on our site to do various jobs.</p>

<p>My concern is - how do I maintain the site as a web application without having to rewrite all that functionality in the language of the CMS.  I'm trying to see if I can split the site into two pieces 1) the majority of the static pages powered by the CMS, and 2) the web application stuff that can remain powered by Zend Framework.  Does anyone have experience doing this?</p>

<p>My concern is if I send some traffic to www.site.com/A and other traffic to www.site.com/B (A being the CMS and B being the web app) how do I handle common layout code like navigation and footer?  Meaning if you update the nav in the CMS, this won't magically appear on the web app side.</p>

CC BY-SA 3.0
2016-04-29T17:41:41.450Z
This is definitely possible. It's hard to say what the granular routing would look like, but it can definitely be done. You may want to check out the [Craft Slack channel](https://craftcms.com/community#slack) to get some feedback from folks who have done something similar.
Lindsey D
CC BY-SA 3.0
2016-05-05T12:18:09.890Z
Great, thank you! I'm sure it's all possible and I'll figure it out as I go.  I'll check out the Slack channel too, thanks!
scottystang
<php><craft-features>
Existing website written in PHP Zend Framework
# Existing website written in PHP Zend Framework

(Asked by: username_0 on 2016-04-29)

I manage our corporate marketing website, which is written in PHP and the Zend Framework and is hosted on LAMP servers. I've been tasked with moving the website to a CMS so other folks on the marketing team can update content without having my dev team be the bottleneck for content publishing and changes.

However, our existing site is more of a web application, in that we use the Zend Framework and PHP code for back-end integrations with HubSpot, WebEx, etc. and various CRON jobs that hit endpoints on our site to do various jobs.

My concern is - how do I maintain the site as a web application without having to rewrite all that functionality in the language of the CMS. I'm trying to see if I can split the site into two pieces 1) the majority of the static pages powered by the CMS, and 2) the web application stuff that can remain powered by Zend Framework. Does anyone have experience doing this?

My concern is if I send some traffic to www.site.com/A and other traffic to www.site.com/B (A being the CMS and B being the web app) how do I handle common layout code like navigation and footer? Meaning if you update the nav in the CMS, this won't magically appear on the web app side.

**Tags:** php, craft-features

> **Comments:**
> **username_1**: This is definitely possible. It's hard to say what the granular routing would look like, but it can definitely be done. You may want to check out the [Craft Slack channel](https://craftcms.com/community#slack) to get some feedback from folks who have done something similar.  
> **username_0**: Great, thank you! I'm sure it's all possible and I'll figure it out as I go.  I'll check out the Slack channel too, thanks!  

---

## 1 answers

### Answer by username_2 on 2016-06-15. Score: 1

We've successfully implemented a setup that will solve your issue with several sites. Unfortunately we haven't been able to open source things yet, but this is our general process:
We set up a Craft install on a separate domain (or subdomain, in our case). Then we serve the content as JSON instead of html in our layout template. 
Our entry templates are totally normal, outputting html like any other template does. This layout just wraps the whole thing in a json object (and does not include the header/footer etc).
Then on the ZF side, we wrote a module to pull in the data from the separate domain and output it in our app, using the normal layouts that already existed. It is also obviously heavily caching the content it receives from Craft.
So, ZF is actually handling all of the requests by end users, and the only things going to Craft are actually curl requests from ZF.
We have ZF send along a Header telling Craft that the request is coming from ZF, and then we have Craft check for that header. If it exists, it uses layout.json, and if not, it uses layout.html.
layout.html has a dummy version of the header and footer, and is only used for Live Preview basically. The layout.json file serves our content as json to the ZF app.
Here is our layout.json:
{% header 'Content-type: application/json'
%}{% set response = {
    success:true,
    metadata: {
        {# some custom data #}
    },
    data: {
        meta: (head is defined ? head : {}),
        body: block('content')
    }
} %}{{ response|json_encode()|raw }}

So, while this doesn't mess with custom routing, it will allow you to keep your ZF app going and have Craft handle marketing/static pages.


---

