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

Regenerate entire site

felipel

I have searched around a bit and haven't been able to find a solution to my problem, so if this has been answered already, feel free to point me in the right direction and I will seek that out. Having said that, here's my problem:

Our team periodically needs to regenerate our entire site (usually due to a significant change in the presentation template that affects all our pages). We have not been able to find a way to regenerate all pages seamlessly and transparently. Here's the steps we currently take:

1. Create an empty workarea (call it Regen) and do a Get Latest to pull the current versions of all files from Staging. We do this because we have multiple workareas that are not always in sync, so we have to regenerate out of a common workarea that reflects staging.

2. Run the regen script against the root of our generated HTML folder, regenerating all templated files.

3. Go into every other workarea (we have about 15 per branch) and list the locked files in the workarea. All locked files are then unlocked. (We do this to enable the next step.)

4. Submit the root HTML folder from the Regen workarea. Then we publish the branch to push the change out to the webservers.

Following these steps gets the new content out to the web servers but has a couple of major flaws/hassles:

1. Step 3 is a huge pain. It seems like we should be able to perform step 4 without unlocking every file. However, if we try to submit when files are still locked, Teamsite will not allow it. This restriction also means that we have to keep users off the system while we regenerate so that files don't get locked while we're working.

2. Staging now contains a newer version of the files than each workarea (except for the regen workarea). Thus, users are prompted every time they edit a file to replace their file with the newer (regenerated) file from staging. If they happened to have made a change in their workarea that wasn't submitted before the regeneration, their changes will be overwritten with the staging version. Ideally, we'd like to do a Get Latest in each workarea, pulling down the newest version of files that aren't locked. Unfortunately, Get Latest also appears to sync the workarea with staging, so files that haven't been submitted are deleted from the workarea.

Hopefully what I've described makes sense--I'd love to hear of anyone's ideas on how we could better/change the process. We don't have to do this very often, but when it happens it is rapidly becoming a huge pain/risk for both the hundreds of users and the thousands of files we are touching. Thanks in advance!

Find more posts tagged with

Comments

Bowker

Felipel,

Without reading your whole problem, will this help you?

I have a custom menu item that will, starting at the current folder, find all templated files and regenerate them, then navigate to all sub directories and regenerate them recursively. Thus it will regenerate all pages that are templated on the system.

If you would like I can send you the code.

Dan Bowker

felipel

No, we have that functionality already. I don't have a problem with the actual regeneration of the pages, it's just the surrounding issues before and after the pages are regen'd. Thanks, though...

Physical Runtime Output Connector Settings.jpg

akshathp

I understand you are facing two issues:
1. Locks
2. GetLatest

Is it possible for you to have a custom script called by your regen script to first unlock the files and then do getlatest on these folders in all workareas. Ofcourse you could use iwunlock and iwupdate Command Line Tools(CLTs). And to make the script bit more generic, you could also have it scan the extended attributes on the file to see if it was templatized or not and then only use unlock CLT. You could alos gather information about locks either by iwlistlocks, iwlockinfo or even iwattrib with istagged attribute check. I believe you could add these calls to these CLTs within the regen custom script that you are using.

Hope this helps.

Akshat Pramod Sharma
Interwoven Inc.

testUnpack.txt

felipel

My issues do revolve around locks & get latest, but not really related to the regen script itself--that piece works fine. Here's my issue from the perspective of the two pieces you brought up:

1. Locks -- locks seem to prevent submit from occuring. When we submit from the Regen workarea, if any of the files are locked in another area, it stops the entire submit process. In my mind, the submit should take place regardless of whether or not the file is locked in another workarea.

2. Get Latest -- Why does Get Latest (from a high level directory) remove files that do not exist in staging? In my mind, it should take all the files that exist in staging and push them back down over existing files in the workarea (unless the files are locked, in which case leave them alone). Files that are in the workarea but not in staging shouldn't be touched.

Thanks for your info, though. I'm sure that we could probably write a custom script to accomplish what we're after. I just figured this is a fairly common task that someone has probably already conquered.

akshathp

OK. I do understand your *regen* script is working fine. And am assuming you have it as a custom menu item. So, the steps for your execution would be to select assets and click the custom menu item. And later when the execution is done, user would select assets once again and do submit operation.

Considering that would be the execution steps, I suggested to either have a custom script called before regen script to unlock the files. To detect the locks you could use iwattrib with istagged attribute, iwlistlocks or iwlockinfo CLTs in this additional custom script.

Later when user is done submitting the content, user could execute anoterh custome script(using custom menu item) which will perform getlatest on the workareas. That would be using iwupdate CLT.

Incase it suits your requirements, you could also have a use of CLT iwsubmit with option to override conflicts and remove locks while submitting. This could be part of the custom script itself and user won't use submit from TeamSite UI. Only disadvantage would be that this will always do a force submit and will not prompt for conflicts or merge. Which incase you are regenerating the files, I am assuming you are anyways overwriting using overwrite option.

So, yes, your regen script is fine but I suggested to have these CLTs used in addition to take care of locks and getlatest.

Hope this helps.

Akshat Pramod Sharma
Interwoven Inc.

felipel

What you're saying makes sense, and it certainly sounds like it would work. I guess I was hoping/expecting that someone else has done this (it seems like it would be a fairly common task) and has a procedure already in place. Or that there's something already built into Teamsite that does what I need. But perhaps I was expecting too much...

BUADH

Hi Dan,
Could you send me the code please? It'd be really handy for our current project.

-Vic Keegan