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

Question 3 of 4: Changing the location of generated HTML.

WGM

Hello! I'm very new to TeamSite and need some guidance on the best way to implement some things.

If you have reviewed my other questions, this section is the same:

<about>

Background: A vendor has designed HTML for a new site and we need to manage the pages in TeamSite. We have componentized the common aspects of the pages. The vendor developed the pages without consideration for requirements/restrictions of TS. Being a responsive design, we want to match the HTML provided by the vendor as closely as possible. This way, if the design doesn't work, we can push back to the vendor and request they fix it.

Products/Versions/Current Methodology: We are using TeamSite 7.4.1 with SitePublisher. No customizations have been made to the installation. The pages are currently based on custom fixed area layouts used in a template with various components which are then used to create pages using the same general format (c-clamp etc). NOTE: The pages are typical static marketing type pages and are therefore "invariant" with respect to each request, so we are deploying the HTML generated and NOT using the LSDS.

My background: I am an application architecture and have many years of experience. I know countless languages such as Java as well as technologies like XSL, XML, javascript etc. However, often I know only enough to be dangerous and not enough to say I'm an expert.

</about>

Consider reviewing the other questions posted in separate messages in case they would change your recommendation. They will concern controlling the excess divs generated by a fixed layout, controlling structure of the URL namespace when generating the HTML via the PLC and (somewhat unrelated) can a single server also serve as a development environment separate from the current installation so changes suggested for these questions be tested without affecting the current installation.

Question 3:

When the HTML is generated through the PLC workflow, the links to the pages have them located at:

/html/sitename/page.html

So for example, index.page at

//teamsite01/default/main/MySite/WORKAREA/shared/sites/MySite/index.page

will be linked to from other pages using

/html/MySite/index.html

Is there someway to control how the links are generated?

Thanks in advance. Some here recently helped me with a problem in the generated HTML (the stuck in preview mode bug) and would really appreicate your suggestions on these problems.

Find more posts tagged with

Comments

Garth McMillan

You have limited control on changing the location of where the generated HTML is put.

Out of the box

You can edit the workflow model, select the task and change the following task variables (I've put what I think the defaults are):

Suffix: .html
DestinationDirectory: html/${siteName}

Customised

If that is not sufficient, you can do one, or a combination, of:

Use URL aliases
Alter the links with a different rendering processor (Java class can be specified with the Processor task variable)
Moving the files around with OpenDeploy or some custom code/script.

There are additional posts in these forums about those topics.

WGM

Thank you for the information.

Would the workflow route address the links in the various pages to /html/sitename/pagename.html as well as changing where the page is stored?

Would solving that problem require the rendering processor solution?

For example, when using $PAGE_LINK[about_us], the generated HTML links to :

/html/sitename/about_us.html?

We would prefer that the link be just:

/about_us.html

You mentioned URL aliases. Is that a TeamSite concept? If so, in what area of TeamSite would I find it?

Thanks again.

Rick Poulin

Would the workflow route address the links in the various pages to /html/sitename/pagename.html as well as changing where the page is stored?

Yes. Internal links will be adjusted accordingly when it generates the page.

We would prefer that the link be just: /about_us.html

You can make the destination directory be simply "/". Just note that [by default] the PLC sends all branches to the same docroot, so you'll either want to change that behaviour or choose a uniquely named folder. Note that traditionally, generating to the workarea root is not ideal because then you're all mixed up with implementation folders like "sites" and "templatedata". That's why generating to a docroot and then post-processing the links is usually preferred.

You mentioned URL aliases. Is that a TeamSite concept? If so, in what area of TeamSite would I find it?

URL aliases are configured in the sitemap for that website. Each node in the tree can link to a page, and then you can assign it one or more "aliases". In the end, this becomes more of a manual way to solve the internal links problem, and [IMHO] isn't very suitable for larger websites.

WGM

Thank you very much for the detail. I will try the workflow modification as it seems more OOTB.

Garth McMillan

We actually create our URL aliases automatically based on rules we've defined.

Whilst we do use LiveSite to display our pages, we also generate, and publish, HTML versions for a "static failover" version in the event LiveSite fails. We have some simple ASP.NET code to use the same URLs (aliases) for both the LiveSite and static versions.

That being said, there's a little more work to map aliases to the actual file locations, and given you are not using LiveSite etc. I'd say it's probably not worth it in your case.