Generating HTML produces URLs with /iw-preview

I'm trying to generate HTML with the ootb Publish LiveSite Content workflow. The workflow is enabled and I changed the settings so that it generates HTML.

The issue is the generated HTML always has links that begin with /iw-preview and refer to a .page file instead of .html. The images url begin with /iw/cci/meta/no-injection/iw-mount/default/main

I need to host this content without LSDS and need simple HTML with simple relative links to .html

I've tried assigning a url alias in the site map and publishing to "production" as some posting implied that publishing to "development" would use the /iw-preview references.

Others seem to be doing this. What is the secret?

This is 7.4.2.

Find more posts tagged with

Comments

Garth McMillan

In our case we have a custom class which extends the PostRenderingProcessor class for the HTML generation task.

In it we have a bunch of manipulation that gets done on the HTML produced by LiveSite, one item of which is rewriting the links.

Whilst we are currently using TeamSite 7.4.1 with update 1, the code was originally written for an earlier version, so I'm not sure what has changed with the out-of-the-box HTML generation.

WGM

Thank you for replying.

NOTE: I had a typo. This is 7.4.1.

Am I interpreting your response correctly as that out of the box, the generate HTML function won't generate "normal" HTML that can be served without the LSDS runtime?

The impression we received from the sales engineers is that it is supported and something that should work.

To restate the issue, the links to other pages begin with /iw-preview and end in a file name such as need_help_to_afford.page whereas we expect the links to be simply /need_help_to_afford.html

Edit Text Item.png

Rick Poulin

It should work OOTB. You typically only need to post-process links if you don't like the default docroot (of /html).

How are you capturing your links? It sounds like you're putting a literal href value instead of using $PAGE_LINK.

tableHierarchy.rptdesign

WGM

Thanks for replying as we are desparate to get this working.

Nope, I'm using $PAGE_LINK for all the page references. It would be great if the links started with just /html/. We could work with that.

The issue is that the HTML is generated as if it is to be previewed.

And I'm referring to the HTML that is placed in default/main/<sitename deleted>/WORKAREA/shared/html

Would the deployed HTML be different than that in default/main/<sitename deleted>/WORKAREA/shared/html? We have a problem with OD at the moment so I can't see what would be deployed.

Can you think of any reasons why the generated HTML looks like the attached file snippet (under_30.html)? The attached "component appearance HTML.txt" shows how these are referenced in the component.

Please don't assume that I know what I'm doing. This is my first experience with TeamSite/SitePulbisher so if there is something you think is obvious, it might not be to me so please suggest it.

Like is there something I need to do in the workflow beyond setting it to alway generate the HTML?

I'm at my wits end!!!! Please help if you can!

Thanks.

WGM

Rick Poulin

The deployment step does NOT affect static files, so they would be no different on the runtime.

Your XSL looks ok, so I would think there's two possibilities.. either the task that generates your HTML is not configured properly, or you found a bug in 7.4.1 (last time I checked the generating of html was 7.3.2).

Post the details of your generation task -- url command and all task variables.

Also, try using the manual generation from the SitePublisher menu in CCPro (outside of workflow) and see if it yields any different.

WGM

Really appreciate the fast response.

Being a newbie, I'm not sure how to find and provide the information you are requesting.

I can tell you what I did in hopes it will set the context:

-- I use the OOTB PLC workflow after enabling it for the site.

-- In -

/iwadmin/main/workflowModels/WORKAREA/iw-wa/Config/Publish LiveSite Content_config/custom_instantiation.cfg

I changed this line -

IWDatacapture.getItem("/Config/
ConvertPagesToHtmlFlag").setValue("false");

to -

IWDatacapture.getItem("/Config/
ConvertPagesToHtmlFlag").setValue("true");

per the 7.4.1 users guide.

-- Then in CC pro, I select the .page file (or all of them), click submit and I'm presented the option to choose:

Publish LiveSite Content or

Submit Workflow

-- I choose Publish LiveSite Content

-- I'm presented with a page for the job description, target nodes (I've tried both Development and Production)

-- Then I click submit and it churns a little.

-- I'm asked for some titles and tags for the referenced content. To whick I click Next>>

-- I'm asked for Task Comments to which I click Next>>

-- It churns a little more and fails on the OD phase (because our OD isn't configured, something I'm trying to remedy to remove it from the equation).

However, the .html file is generated but with the iw-preview links.

I also tried checking the page to select it and then invoking SitePublisher -> Generate HTML and the HTML is generated with the references to /iw-preview and the links have .page instead of .html.

I'm hoping this is just a lack of understanding and I need to do something like build a site map for the pages. Something that someone brand new to TS doesn't know that it needs to be done. I did build a site map but the behavior didn't change. I even tried using $URL_ALIAS in place of $PAGE_LINK and the only change was the links ended in .alias instead of .page. But nether gets the /iw-preview out of URLs or the extension to be .html.

Thanks for any help you can supply.

Bill

Rick Poulin

So you're basically using the OOTB PLC.. have you made any changes to any of the Spring configuration files? (xml files where you'd find a lot of <bean> tags). Assuming no, this sounds like a bug in this version of the platform. I can't independantly confirm though, as I don't have a 7.4.1 box available at the moment. I suggest you open a ticket with HP Support.

@ALL: is anybody else able to confirm whether their Generate HTML feature works on their 7.4.1 instance?

WGM

No changes (since I'm new and don't want to break things) to any config files. Bone stock installation.

I opened a ticket with support and I'm asking to have it escalated.

Mahtab

This is a bug, and Engineering has recently came up with a Patch for it already. Support can provide that to you. Patch LST-10857 is for your particular issue for the html file. 

Root cause of the issue description: 
On a Freshly installed Teamsite 7.4.1.1 server, we noticed the same issue when generating Sitepublisher Pages.

The $URL_PREFIX and $PAGE_LINK tokens are being ignored when generating a HTML page from a Site Publisher component.

Component XSL contains the following:

<img src="$URL_PREFIX/test.gif"/>

<a><xsl:attribute name="href">$PAGE_LINK[<xsl:value-of select="'test'" />]</xsl:attribute><xsl:value-of select="'test'" /></a>

Generated HTML file contains (to the path a website would exist):

<img src="/iw/cci/meta/no-injection/iw-mount/default/main/component-guide/WORKAREA/shared/test.gif">
<a href="/iw-preview/52616e646f6d4956bde969303df4beacd14fc285e0e3c901b51130d8ce8f166aee762f9845096934de22dda71ce70e70d17dc6499cf2f46b665e3c19e63359160a75ebf043ae2cc8/hv9vdcvx/Component+Guide/test.page?">test</a>

It looks like that Generate HTML, Generate ASP, Vpath Meta, Fixed Layout css path,  are all thinking they are still in PREVIEW mode when Generating.

When Testing in Java:
- context.isPreview() alsways returns True.
- context.getMode()  always return 'PREVIEW'

We are currently trying to migrate to 7.4 but all our Generated pages have the wrong paths.

WGM

THANK YOU!!!!!

a billion times over!

Mahtab

Smiley Happy Glad to help.

Add to Page Number.rptdesign

Rick Poulin

@WGMwhen you confirm that this patch fixes your issue, please don't forget to come back and 'accept' Mahtab's solution to effectively close this thread.

WGM

Absolutely...

Thanks for everyone's help. Hopefully, the patch will fix it.

Add to Page Number.rptdesign

WGM

I can confirm that the patch mentioned previous and which I marked as the solution adresses this problem.

Thanks again everyone!