Bug report. Some Section Tree JavaScript layouts failing to generate code

[NormanRouxel]

Using current shipping version of V8 - GIKA.

If I put the following into an Overall Layout (via Insert Layout)

<actinic:variable name="JavaScriptArray" value="All Data From All Sections" />
<actinic:variable name="JavaScriptArray" value="Name Data From All Sections" />
<actinic:variable name="JavaScriptArray" value="URL Data From All Sections" />

and do a Preview then the following code is generated

<script type="text/javascript" src="../Act_section_tree.js"></script>
<script type="text/javascript" src="Act_section_tree_names.js"></script>
<script type="text/javascript" src="Act_section_tree_URLs.js"></script>

The first line is correct - Act_section_tree.js is generated into the Site folder.

However the second two are wrong and also the files Act_section_tree_names.js and Act_section_tree_URLs.js are never generated.

If I generate a live site, the files Act_section_tree_names.js and Act_section_tree_URLs.js are never generated nor uploaded.

I've not checked this with all the other possible variants on the JavaScriptArray layout but I suspect that they'll fail too.

[cdicken]

Many thanks Norman. I have reported this to the development team.

[1stweb]

Any Progress?

Hi Chris, Norman,

What is the latest on this issue? We use the Act_Section_tree_URLS.js and Act_Section_Tree_Names.js in an application we are developing. Are these now available in V8.0.1 ? If so, how do I get access to them?

[NormanRouxel]

As a temporary workaround I'm using Act_sections.js as this contains both the Name and URL structures. A look at the 3 files should indicate how to do do this.

[1stweb]

Thanks Norman, I appreciate there is a workaround. I am looking to see when it will be fixed. If not then I can develop a solution based on the workaround but I would prefer to have this issue fixed so that we are not developing twice.

Chris,

A date for the fix would be helpful

[wfl]

It looks like this one has come back in at least 8.50 HBKA. If not before.

I am using Normans GIKA work around at the moment and that seems to work.

I am not sure the new scripts have uploaded every time although that might be me as I have been uploading and deleting files a lot in order to identify when I got the problem.

[wfl]

I think I know where the problem is.

The menu works correctly if the site is completely within Actinic but I am working with an external design in DW and it is this that is stopping the menu being generated correctly.

I have tested this by taking a standard page from 8.5 HBKA where everything works OK.

I copied the code for this page into DW and registered this design with Actinic. As soon as I did the menu stopped working.

[NormanRouxel]

Alistair,

Look at the source code of the layout before / after it's been saved from DW. Perhaps DW is altering some URLs.

[wfl]

Norman

I can't see any difference in the code I see in DW to the code that is in Actinic.

But it gets stranger and I think I may be getting confused when I do previews and updates and between the different methods and file origins. I have been working between a the Executive design and an External Copy of the same code;

It seems that if I preview before I upload it will generate the "Act....URLs.js" file with "../../../Act_PreviewWarningPage.html?ACTION=SHOWCART".

On the other hand if I upload first it will generate it correctly.

So this may be where the incorrect one is coming from because once it is generated it doesn't seem to get overwritten.

Nothing I do such as editing or swapping views seems seems to regenerate the "Act....js" files.

I have found though that if I delete them from the site folder doing an upload doesn't recreate them but switching from one view to another does.

When I do an upload it does not always send the "Act....names.js " file up, only the "Act....URLs.js" file.

Finally I have tried testing with the GIKA mod which does generate the right files but it still doesn't regenerate the "Act...js" files after editing or when uploading or previewing.