Hi,
I have created a new Velocity page variant for an existing content type which has an existing XSL page variant
I have set both the new velocity template and existing XSL page variant to publish when Never and created a dispatch template to dispatch to the correct variant depending on the default variantid set on the CE
I have modified the location sheme to point to the new dispatch template (originally it pointed to the XSL variant)…the code for which is…
$start_letter = $sys.item.getProperty(“rx:start_letter”).String.toLowerCase();
$end_letter = $sys.item.getProperty(“rx:end_letter”).String.toLowerCase();
if($sys.item.getProperty(“rx:default_variantid”).String != “520”)
{
$location = $sys.pub_path + “az-” + $start_letter;
if(!$start_letter.equals(“0”) && $start_letter != $end_letter)
{
$location = $location + $end_letter;
}
}
else
{
$location = $sys.pub_path + $start_letter;
}
$location = $location + ‘.html’;
This seems to work ok as I have tested publishing both variants using publish now and the files publish out no problem.
The problem is that the existing XSL variant is now generating links to other instances of the existing variant pages incorrectly. I.e. the existing resource uses an exit called sys_casGenerateLocation. It generates the internal links ok ie. when sys_context is 0 the links works fine, but when the files are published the links are as follows
<a href="/environment/planning/atoz/17062.html">A to B</a>
(the format xxxxx.html is the default location scheme when no other scheme is defined)
when the correct path should be
<a href="/environment/planning/atoz/az-AB.html">A to B</a>
(as defined by the location scheme above).
This inevitably is causing broken links.
I’m pretty sure I can workaround this by reinstating the content type back to a single XSL template and creating a new content type with the new velocity template, handling the location schemes separately and then publishing / links should work fine…but surely there is a way to fix this problem.
Thanks
Jason