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

LiveSite component and template migration

Aryan

How does one migrate components and templates from a development system to a production system?

Merely copying the components and templates does not seem to work. Also we are not able to edit the copied components.

Find more posts tagged with

Comments

wscott

You shouldn't have components and templates on your production system, only sites and pages. There is a workflow supplied which uses OpenDeploy to transfer the sites and pages from the development system to production.

Aryan

Ok sorry for being ambiguous...

When I say "production" i dont mean production runtime but the production CMS system wheere the Livesite development is installed n the production Teamsite system.

I am having issues migrating components from the development livesite dev to the "production" livesite dev....

tec_iwov

you can use the import_component script but this is not a recomended configuration for Livesite. We store version and vpath information in Pages/templates in order for "Get Latest Components/Templates" to work.

Aryan

import_component script

Can I use the same for templatges too???

tec_iwov

no that script only works for components, As i mentioned earlier that if you move pages/templates the get latest functionality may/will not work as expected.

Example_Report2.rptdesign

wscott

I am having issues migrating components from the development livesite dev to the "production" livesite dev....

We recommend against trying to do this. You should do all your LiveSite development on a single server, precisely because of the migration problems you mention and the versioning issues that Tim mentions.

FixedLayout.bmp

Nicholas

I am not sure this is possible or not but I wanted to know that can we hide the LiveSite Menu Items from Editor/Administrator login or some specific users?

any suggestions?

flivauda

You should be able to use the UITK customization guide to enable/disable the menus based on role. You can also remove the menu items, but I don't think this can be done by role.

Nicholas

My question is not relevent to this thread as I just replied to this thread rather opening a new one.

Shazzer

Aryan,

Simply copying the livesite-generated content to another server will not work as your files will all lose their extended attributes (this is exactly the same as in migrating teamsite-generated files).

If it's just a straight migration you are after and you aren't concerned about the previous component versions staying intact on migration, just use standard perl scripts to capture the extended attributes of your normal workareas and your template and component workareas to text files. Once you have moved all the content onto the new server, copy the text files over and run a script to apply them to the new workareas. This will reapply the extended attributes and your components, templates and pages should be back in working order, albeit without the version histories from the old server.

I have attached some standard scripts to capture and reapply extended attributes in case you don't have any of your own.

Antharix

We recommend against trying to do this. You should do all your LiveSite development on a single server, precisely because of the migration problems you mention and the versioning issues that Tim mentions.

Hi Will,
Does this mean we cannot have a mirror server/HA env for the LiveSite Development environment?

wscott

I'm not sure what you mean by "HA env." But the short answer is, it's much, much easier to just have a single development server. You shouldn't need to stage your content between LiveSite servers, because LiveSite's test store allows you to preview component changes and TeamSite's versioning allows you to roll back any mistakes.

Some people like to set up a second TeamSite server for testing workflows and other configuration settings. That is fine, so long as you don't try to transfer any pages, components, templates, etc. between the servers: treat all the LiveSite files on the testing server as throwaway data.

Transferring components, pages, etc. between servers can be done -- but it is so problematic that it is more work than the original problem that people were trying to solve by having two servers in the first place.

Antharix

I'm not sure what you mean by "HA env." But the short answer is, it's much, much easier to just have a single development server.

Hi Will , by HA env, I meant High availibility, werein we have two servers one a mirror image of another. This enables switch over from one server to abother in case the primary server fails.

This means that pages and components developed on one server will also be available on the other server. Now What I am interusted to know is ,

Will migration issues come into picture?
Will it help to edit default.page's "Server" tag to hold a virtual address, that is mapped by DNS to either of the system?

Let me know if I am not clear.

wscott

Will migration issues come into picture?

Yes. When you transfer any LiveSite files from one server to the other:
1. You must make sure to keep all of the EAs perfectly intact.
2. Whenever you transfer a page or template, make sure to do "Get Latest Components" on it. You will need to always get the latest components and templates; you can't voluntarily leave some components out-of-date. This is necessary because the version info is lost during the transfer. Unfortunately this process can not be automated at this time, either, so I don't know how feasible it is for High Availability.

Alternately, if you are copying the entire store between servers so that it is an exact mirror (including all the EAs and version info), then this should not be a problem. However, I am not sure if this is possible or what the ramifications would be.

Will it help to edit default.page's "Server" tag to hold a virtual address, that is mapped by DNS to either of the system?

It might. This is only used by the "Live Page Edit" and "In-Context Edit" components, so that the production server can send the user back to the development server. I believe the value of the Server tag is read from a property in iw.cfg.

ccprofessional

I understand this is an old thread, and I don't imagine anything has changed. But I'll ask anyways -

Is it still a difficult task to migrate LS components and templates from one development LS 3.0 server( sitepublisher) to another?

What is the best practice in an environment where the LS development code needs to be migrated to another LS development server?

Aryan

As far as the components migration goes, I think the paradigm still remains the same.

As for the best practices, Shannon or Will would be the best people to respond....

Frederik

WHOHHW... this issue really threw me off my feet... :eek: Smiley Sad

We're involved in what could be a first project with LiveSite 2.2.1. We have used TS by itself till now.

Our corporate practice is to have 4 different server environments in any project: DEV (where developers do their thing), TEST (testing out technicalities), QA (testing out functionality), PROD (where end-users make content). That means that the work of developers needs to be lifted from DEV to TEST to QA to PROD. Each environment would have a TS+LS backend and LS frontend.

Is it really that problematic to package new/upgraded components & templates and move them (from DEV) to other servers?

That's never been highlighted by any of the Interwoven Sales Engineers nor Account Mgr that came here to sell LiveSite, and who know very well that this is how we work. Smiley Sad

Aryan

Those kind of things never get h ighlighted.... Smiley Happy

Anyways... its not that difficult to do. It is just a matter of copying the component and running a program to set the EAs. Interwoven has the programs(IWOV KB) to copy and migrate the EAs readily available. You could make use of that if you have the proper permissions from IWOV and have access to the IWOV support site.

niske

there is an easy way to move components and templates from one Teamsite server to another. You simply download them, upload them again on the new system and then set the correct extended attributes.
For components that goes like this;
open a command line on the server and change directory to the directory where the component sits (in case of windows Y:\something\something\livesite\component... etc in case of unix /something/iwmnt/iwadmin/etc....)
and then execute this command;
iwextattr -s TeamSite/LiveSite/Type=component //complete_vpath of the component

(keep in mind that if the component has a name with spaces you need to put the name between single quotes)

and the command for template would be
iwextattr -s TeamSite/LiveSite/Type=template //complete_vpath of the template

Don't try this between different versions of livesite, (2 and 3) cause it deletes the contents of the component.

SebPRG

When im trying to copy the .component to another location, windows said that the file is in used, impossible to copy ... someone can help ?

Thank

vpatel

When im trying to copy the .component to another location, windows said that the file is in used, impossible to copy ... someone can help ?

Thank

General practice is to not copy .components for a lot of reasons. For a simple copy, you my want to create a new component and copy and paste the Appearance XSL, Content XML, and Appearance XML (minus any auto-generated IDs).

PaulW

You can just use OpenDeploy and do a TeamSite comparison deployment. Then you can set the applyExtAttrs="yes" in the targetTeamSite node. This will copy all EA's across.

vpatel

You can just use OpenDeploy and do a TeamSite comparison deployment. Then you can set the applyExtAttrs="yes" in the targetTeamSite node. This will copy all EA's across.

You do NOT want ALL EAs to be copied either.

PDFImage.bmp

PaulW

ok. so what EA's need to be copied for pages and components and templates?

I have been stuck using a development server, because I don't have access to the prod server. Now i have to migrate my pages, components and templates to the production server.