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

Shared Resources at a common branch

iw_store

Hi ALL,

In our present implementation using TeamSite (Form Publisher based) we keep all our JavaScript, CSS and images in a centralized branch.

And all other branches where content will be created use the js, css and images from above centralized branch using custom callout. We have branch to branch proxy remap for TeamSite preview.

All resources (js, css and images) from centralized branch and content from other authoring branches will be deployed to web-server.

Now we are migrating form publisher based TeamSite implementation to SitePublisher and LiveSite.

My question is, how can we store all our resources (js, css and images) in a centralized location wherein the sites which we create in different branches under default stores can access those resources and when implementing components against a site will those shared resources will be available for component preview ?

I know if we keep all resources under same branch/workarea of site, we can easily associate css and js files to site by editing the site settings.

But how we can we associate css and js files which are in different sites or branches virtually into another branch or site with SitePublisher implementation ?

Any idea will be helpful.

Find more posts tagged with

Comments

iw_store

Any thoughts on this?

And also any ideas/document on custom page tokens will be helpful.

nipper

Your ability to do this is quite limited, and a very big hole in the product. I have been complaining to LS dev team and product management about it. Talk to you sales rep and make certain your feedback gets to product management.

You can XSL include, but no real way to keep images elsewhere or many other assets.

Stokes

Well, one way I can think of is to maintain your 'source' assets in the dedicated branch, and use a CSSDK-powered script to 'push' the content out to your other branches. I'm guessing there's a way with file attributes or permissions to insure that the assets cannot be changed by developers in the site editing branches.

With this approach, each site would still have the CMS history, so that you could recreate what the site would have looked like at any point in the past, including the exact versions of shared/common resources.

I'm not saying that Nipper's feature request wouldn't be useful, but maintaining the version history across branches could be prohibitively complex, negating a main reason to have WCM in the first place.

Stokes.

iw_store

Stokes,

Thanks for the reply, we don't want to push any of the asset from the common branch. We just want to keep a single copy of assets in the common branch and get refered from there.

Nipper, Even I am getting strong feeling of what you have suggested.

Any other ideas or input's will help from other experts.

nipper

I'm not saying that Nipper's feature request wouldn't be useful, but maintaining the version history across branches could be prohibitively complex, negating a main reason to have WCM in the first place.

You and I are talking different things. I am talking about things that are basically read-only for the branches (updated on a different branch only) and consumed (even deployed if needed) by the child branches. These would not be assets that are modified by all branches.

Stokes

I'm not trying to drag this out, but just to clarify...

Let's say you had a common branch with resources in it that are shared by several other branches, I'll call each of the latter a 'site branch', since it might contain the site and pages of one of your websites. So I can publish multiple websites and they each share common resources, right?

Now suppose after using this system for a while I'm asked, for legal or business reasons, to reproduce exactly what one of my sites looked like on a particular date in the distant past. If there's no snapshot/tagging of the common branch every time I publish a site branch, this can't be done.

So if you satisfy this feature request but lose the ability to recreate a historical revision accurately, you'll lose one of the basic features of WCM.

Stokes.

nipper

OK, I get your point. It is valid. File versions are all set, but yes a whole site version would be a little more difficult. I think you can get around that as well with some creative edition labels.

The problem I am trying to solve is that we need to be able to share LS objects across branches as we do in TeamSite.

Andy

GRD

The problem I am trying to solve is that we need to be able to share LS objects across branches as we do in TeamSite.

Apache and/or application server redirects/rewrites should allow you to do this, Andy. This should work fine for object references you embed manually. The challenge would be allowing the user to pick from a common object branch--many of the pickers do not allow browsing across branches.

-Greg

vpatel

Let's say you get cross-branch browsing to work, what's your take on following:

1. Preview?
2. Synchronized deployment?
3. Content delivery on the runtime side?
4. Resource collision on target side?

As you look at this topic closely, you'll realize that this requires some careful planning, processes, and some automation to implement a good solution. Also it is important to realize that this is very implementation-specific and the optimal solution is going to be based on the requirements and constraints that you have to work with.

HTH!

nipper

1. Preview?

Why iwproxy should handle that.

2. Synchronized deployment?

That is my problem. The workflow will need to deploy the deliver from common branch as well as the child branch.

3. Content delivery on the runtime side?

See number 2.

4. Resource collision on target side?

That should not be an issue because we will only have 1 copy of the resources.

Never claimed it was easy, but people have solved these issues in TS/TST, they can be solved in TS/SP

vpatel

Never claimed it was easy, but people have solved these issues in TS/TST, they can be solved in TS/SP

Absolutely...they can be solved. My whole point is that they are going to be implementation-specific.

For example: simple implementation: custom code for cross-branch browsing, proxy for preview, and avoid resource collision -- DONE.

Some of the more complex implementations that I have dealt with:

1. Leveraging a DB (of course without replicating any content as actual DB records) to allow re-using/sharing of DCRs across branches. This is strictly for cross-branch browsing purposes. On the display side: SP component had an external that was smart enough to retrieve the DCR file from the correct FS location (NOT from the DB). Again -- this design / architecture was driven primarily by business requirements and lesser extent IT constraints. Of course, I also set some guidelines and boundaries around how the content was organized/deployed on the target side.

This was a pretty interesting and robust way of doing things. They had 100+ sites with lot of content re-use all over the place. Any article written by any brand/site could be re-used by any brand/site that has been nominated (i.e. permission) to do so. The so-called "cross-branch" browsing filtered it and only provided a list of articles that you can actually browse.

2. Using a custom token in SP - $COMMON[common/images/logo.gif]. LS will resolve the token to appropriate path at runtime. In preview, point to the common branch. In production, point it to whatever your real location is. Of course, there isn't an easy way to customize the "component properties" screen to allow you to browse outside of your current branch -- so had to fall back to DCR route. Perhaps you could customize the TinyMCE plug-in to allow that -- not sure.

You can see that there are quite a few different possbilities based on how and what you are trying to do things. The point is that IMO this is pretty implementation-specific :-)! Maybe if you buy me a beer next time we are in the same city, we'll discuss item 1 above :-)!

iw_store

What’s the exact difference or benefits, using custom page tokens Vs proxy remap to work preview in TeamSite, if I keep resources (js, css and images) in a common branch?

Is there any way, apart from custom page tokens, LS to resolve dependencies to render pages in runtime?

From my reading, I see there is no way to fetch resources from common branch and associate to a site in a different branch, so that component previewed against that site and pages developed under it, can use resources of a site. Is my understanding correct?

I see same case with components also, there is no way to access assets which are in different branch, it has to go through dcr/dct.

GRD

Absolutely...they can be solved. My whole point is that they are going to be implementation-specific.

It may be best to think of the common resources more in terms of an "API" that requires backward compatibility. Change a jQuery library, fine... make sure it does not break pages that are already using it. Anything that can't work this way should probably not be a common resource.

Think of the ramifications of each object you place there. A logo image. What if the logo changes? That can be a scheduled release, however, what if the logo is now more vertical than horizontal and the size changes? Lots of details like this should be taken into account before objects become a common resource. Dependency releases are fine if two sites are referencing the object, but what about ten or a hundred sites? Could lead to big problems.

-Greg