nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Apache SSI-like ability in SitePublisher/LiveSite?

System

Hi folks,

We are in the process of converting our static TeamSite-managed site to SitePublisher/LiveSite. Currently we rely upon Apache SSI’s to include common parts of a page (e.g., top banner, left navigation, footer, etc.). This way we only need to modify and publish the included files for changes to appear across the entire web site. Pretty simple.

Question: How do we retain this SSI-like ability in SitePublisher/LiveSite?

Let’s use a "top banner" as an example. We've converted the HTML fragment into a SitePublisher component. This component, in turn, is part of a SitePublisher template, which users select when creating new ".page" pages. Here's the rub: Unless we're missing something, ANY change to the "top banner" component requires EVERY ".page" in EVERY branch to be updated as well. Otherwise they won't reflect the change. As a result, we would have to somehow force the update across all branches and then republish all 40,000+ ".page" files. This is NOT a desirable process. How can we modify the "top banner" component and have the rest of SitePublisher and LiveSite (i.e., runtime) automatically reflect the change?

We definitely feel like we're missing a piece of the architecture puzzle somewhere. Thoughts? Advice? Comments?

Thanks in advance,

Find more posts tagged with

Comments

kmu

Perhaps this thread helps.

Migrateduser

Hmm...to be honest, I'm not sure if that post helps, mostly because we're still learning the fundamentals of XSL. I will explore that option further. It seems to make sense for style changes (such as within a css), but will it also cover HTML changes such as adding/removing HTML tags, modifying text, etc.?

Another option recently passed to me by an Interwoven engineer is as follows:

One option is to have the top banner component just read a DCR that has the HTML for that area. Then when you need a change just publish the updated DCR. Caching can control how often the component actually needs to update the DCR.