Transferring files to a new Flare project structure

[ceriwilliams]

My team currently works in a single Flare project, and over time the amount of content we write has outgrown it.

I have been working on a new structure of multiple projects - a top-level project with stylesheets etc., one project for each product we write for, and a low-level project to build documents that include content from multiple products.

It seems to be working well, but now I need to move a bunch of our existing content from the old project into the new structure, so I can properly test it and eventually start using it with the team.

I think if I just drop the files from one project to another, things like stylesheet links will break. Is there a safer way to do it, or is it more of a manual job? If so we might need to be more selective about what we move over instead of moving everything. Is there any other advice on this kind of thing?

Thanks in advance!

[doloremipsum]

I've done this kind of thing a few times... My main piece of advice is to be aware where you are moving the files - either in File Explorer or in Flare itself. If you move the files in Flare, it will try to update the links, whereas File Explorer just moves the files.

My suggestion:
1) Create your new empty project
2) In File Explorer, move the directories you want into the new project. Maintain the same directory structure and filenames for now - this will prevent the links from breaking.
3) Open the new project in Flare. Now you can restructure the files/directories within this project and allow Flare to update any links automatically.

That's the basic procedure for moving the content. For the shared items (e.g. stylesheets) you might need to do some manual work. You can move them into the parent project as above, but step (3) won't update the links in the child projects. It should be easy enough to do that yourself with a Find/Replace (use 'Find in Source Code').

[ChoccieMuffin]

Following on from what doleremipsum said, for the shared items you should definitely look into Global Project Linking. If you search for that term, or for GPL, in these forums you'll find loads of posts - I know I've gone into detail several times on how I use GPL. There may be stuff in Flare's help too.

In brief, you keep "common" items such as stylesheets, page layouts, master pages, copyright info, global variables, global snippets, skins, glossaries, etc etc in a separate project from your production projects, and then create import files in all the other projects to import stuff from that common project. That way, you only update your common stuff in ONE place, which helps to prevent them getting out of synch in your multiple projects. Your team will know when they're looking at an imported file because they're shown in Flare with a padlock, and if you do try to edit it, and then save it, you get lots of warnings.

[ceriwilliams]

Thank you both - a GPL structure is exactly what I'm aiming for, though it's my first time setting it up.

It sounds like I need to set up my structure to match my old project, pull the content over, then make any tweaks to the structure in Flare (so it updates links).

I'll keep experimenting and will be back here if I get stuck again!

[NorthEast]

I'd definitely suggest using a project import (GPL) for importing a project's stylesheets, skins, page layouts, conditions, variable sets, etc. - basically most of the shared stuff that is not content.

If you're using project imports to import the actual content (topics, snippets), then that's where I'd start to question whether to stick with a single project, or use multiple projects and imports.

Generally, splitting a large project into smaller projects will only work if the content in those projects (and the targets you're producing from them) is already quite separate. It won't work so well if you end up with a lot of shared (imported) content between projects, or any of that content needs xrefs or links to topics in the 'host' project (since you can't insert links).

A lot depends on what you mean by "outgrown" - I wouldn't suggest splitting a project just because it's large, but I would split it up if the content in that project is actually quite separate anyway. Using separate projects and project imports can introduce more limitations and complexity, so I'd only do it if necessary.

[ChoccieMuffin]

For clarity, in your big project you could sort your content into folders. Obviously problems arise if there's a lot of shared content, but you could have another folder called \Shared to cope with that, if it helps. If there's a lot of duplication between targets you could instead sort your Content Explorer stuff into features rather than projects. Which way is best for you really depends on your own project so we can only make suggestions rather than say for definite which is going to be the best thing.

[ceriwilliams]

Thanks all for the continued advice. This at least reassures me that GPL is the right way to go (this is all based on a plan my former senior colleague put together before he jumped ship!).

Right now, the problem I have is retiring the old project and moving existing content into the new structure. I don't need to maintain connections between the old project and the new ones - this is a one-off move. After that I'll use import files between the GPL project structure as recommended.

Setting up my new GPL structure so that the directories are identical to the old one seems to be the way to go.

[Nita Beck]

You can use GPL to import the files from the old project into the new project and then, afterward, delete the import file. That'll break the association with the old project. You can then move the files around in the new project wherever you want them to be.

PRIOR to importing files from the old project, you might want to do a little prep work in the old project. Create a folder in the Content Explorer and then nest the existing folders into it. Maybe call the folder OLD. That way, when you use GPL to do a one-time import from the old project, all the files will be in that OLD folder, so you can easily distinguish them from the folders and files already in the new project.