tag:help-archives.hannonhill.com,2010-02-09:/discussions/installation/8215-cms-publishing-to-staging-and-productionCascade CMS: Discussion 2016-06-17T17:41:34Ztag:help-archives.hannonhill.com,2010-02-09:Comment/400334752016-06-07T21:08:07Z2016-06-07T21:08:07ZCMS publishing to staging and production<div><p>Bumping, but adding more information.</p>
<p>We have two site instances: <code>_common</code> and the main
site itself. The pages are under the main site, but are using
templates from the <code>_common</code> instance.</p>
<p>The templates in the <code>_common</code> instance have code
like this:</p>
<pre>
<code><link href="/_files/css/main.css" media="screen" rel="stylesheet" type="text/css"/></code>
</pre>
<p>Upon publish of this page, regardless of which destination is
used, it gets translated to the "www" URL:</p>
<pre>
<code><link href="http://www.thesite.com/_files/css/main.css" media="screen" rel="stylesheet" type="text/css"/></code>
</pre></div>jpetrytag:help-archives.hannonhill.com,2010-02-09:Comment/400334752016-06-16T18:53:01Z2016-06-16T18:53:01ZCMS publishing to staging and production<div><p>Hi,</p>
<p>Thanks for providing that additional information. In your
initial description of the behavior you're seeing, it sounds to me
like you're running into the scenario described on <a href="http://ideas.hannonhill.com/forums/52559-cascade-cms-ideas/suggestions/7524124-add-destination-sets-to-allow-planned-publishing">
this feature request</a>. Can you look over that and add your
votes/comments if that does indeed sound like what you're looking
to do? I just sent you an invite, so let me know if you have any
trouble accessing that forum.</p>
<p>As for your comment <a href="http://help.hannonhill.com/discussions/installation/8215-cms-publishing-to-staging-and-production#comment_40059515">
here</a> - when you're linking to something in another Site, the
link will automatically be rewritten to use the Site's <em>URL</em>
property. So, if I'm understanding this correctly, it sounds like
your <code>_common</code> Site has the URL
<code>http://www.thesite.com</code> set for it at the Site object
level. Can you confirm whether or not that is the case?</p>
<p>Thanks</p></div>Timtag:help-archives.hannonhill.com,2010-02-09:Comment/400334752016-06-16T19:44:37Z2016-06-16T19:44:37ZCMS publishing to staging and production<div><p>That feature request you referenced, although similar, doesn't
seem to be exactly what I'm experiencing.</p>
<p>So, to be clear, the page is under the site instance -
<code>Site P</code> we'll call it. The page uses a template under
the <code>_common</code> instance.</p>
<p>I just confirmed, with your suggestion, that modifying the URL
for the <code>_common</code> instance will cause publishes of the
page to use that URL.</p>
<p>However, the <code>Site P</code> page gets published to multiple
destinations. We don't want the URLs to be replaced - but rather
remain relative. If it stayed at <code>/_files/css/main.css</code>
things would be fine, as that path resolves for both load-balanced
instances of www and staging. However, since everything using that
template gets the <code>_common</code> URL, which we set to "www",
staging publishes for that page point to "www" instead. We don't
want this.</p>
<p>What can we do to have this URL replacement work in a
multi-environment instance like ours, to where it keeps it to the
relative path (<code>/_files/css/main.css</code>) or considers what
destination it's being shipped out to?</p></div>jpetrytag:help-archives.hannonhill.com,2010-02-09:Comment/400334752016-06-17T14:17:21Z2016-06-17T14:17:21ZCMS publishing to staging and production<div><p>Gotcha. Yea, unfortunately there isn't any great way to do this
that I can think of at the moment.</p>
<blockquote>
<p>What can we do to have this URL replacement work in a
multi-environment instance like ours, to where it keeps it to the
relative path (/_files/css/main.css) or considers what destination
it's being shipped out to?</p>
</blockquote>
<p>As far as keeping that path relative (or I assume root relative
in this case?), you might be able to try something like this in
your Template in place of the current <code><link></code> tag
you have:<br></p>
<pre>
<code>[system-view:internal]<link href="/_files/css/main.css" media="screen" rel="stylesheet" type="text/css"/>[/system-view:internal]
<!--#passthrough<link href="/_files/css/main.css" rel="stylesheet" type="text/css"/>#passthrough--></code>
</pre>
I haven't been able to test if something like this would work, but
it might based on how I'm thinking this should be processed. Give
it a shot and let me know if you have any luck.
<p>Thanks</p></div>Timtag:help-archives.hannonhill.com,2010-02-09:Comment/400334752016-06-17T15:01:29Z2016-06-17T15:01:29ZCMS publishing to staging and production<div><p>This seems to be doing what we would expect. I'll pass this
approach onto the other developer here who was affected by this -
and let him work with this too.</p>
<p>Thank you so much!</p></div>jpetrytag:help-archives.hannonhill.com,2010-02-09:Comment/400334752016-06-17T15:08:30Z2016-06-17T15:08:30ZCMS publishing to staging and production<div><p>Ah, nice! OK, one thing you'll need to be careful about here is
to make sure that the files in the shared directory never move. The
reason for this is that the root relative link we just created in
your Template (using the <code>#passthrough</code> notation) is
<em>not</em> managed within the system (meaning that if the files
referenced ever move, that path isn't going to be automatically
updated...thus breaking all of your CSS once you publish to your
web server(s)).</p>
<p>The internally managed link (the one you see within the
<code>[system-view:internal]</code> tags) <em>will</em> be updated
automatically by the system if that CSS file is ever moved. This
means that Pages should always look correct in the system because
the path should always be right.</p>
<p>I'm bringing this up because it could be potentially misleading
to end users in the system since their assets should always look
correct in the application, but could potentially be broken upon
publish. Let me know if that makes sense.</p>
<p>Thanks!</p></div>Tim