Forums

Hard-coded stack not loading all dependent files

Permalink
I have stacks hard-coded into my template files thus:

<div id="mainNav">
<?php
$stack = Stack::getByName('Navigation');
$stack->display();
?>
</div><!-- #mainNav -->

The autonav block (with custom template) in this stack is not loading its associated .js and .css files. What's the fix?
jawbonelid
 
Remo replied on at Permalink Reply
Remo
That's a tricky but common issue. When your code gets called, the header has already been rendered. There are parts of a block (or stack) that are fetched when the header is rendered but concrete5 can't analyze your code and extract the header items automatically.

You could print the header items manually by adding a code to your header. It's not complete and I haven't tested it but something like this might give you the right direction:
$blocks = $page->getBlocks();
foreach($blocks as $b) {
$bi = $b->getInstance();
   if('Controller' != get_class($bi)){
      $bi->outputAutoHeaderItems();
   }
   $bi->runTask('on_page_view', array($v));
}


An alternative to this would be to use addFooterItems in your block because the footer is rendered after your block.
jawbonelid replied on at Permalink Reply
jawbonelid
Thanks. The wierd thing is it works fine for my old page types. It's only a page type that I just created that is broken. I'm wondering now what precarious thread those other page types are hanging on...
Remo replied on at Permalink Reply
Remo
There's only one way I could think of that makes it work: If you have another add-on that includes the JavaScripts too, they are picked up from there. Beside that it's pretty much impossible that this works.
jawbonelid replied on at Permalink Reply
jawbonelid
Would this scenario explain the inclusion of the JS on old pages:

1/ template for page type created with a "navigation" editable area.

2/ Autonav block added to "navigation" in page type defaults

3/ Pages generated with this page type

Then later...

4/ Stack created with autonav block

5/ "navigation" editable area deleted from template and replaced with hard-coded stack

Result: Old pages and new pages using old page-types still load relevant JS and CSS. Whereas new page types do not.
I assume the default blocks (with all related files) for the old page types are still being loaded even though there is now no 'area' in which to place them? If I'm correct, this also raises the question of optimisation... How do I prevent these orphan blocks from loading?

Joe
jawbonelid replied on at Permalink Reply
jawbonelid
Hmmm. This is a site that I recently upgraded to 5.5 and converted hard-coded scrapbook items to hard-coded stacks.
There must be something left over on those old page-types. Thanks for your help. Need to do some digging...

BTW I assume this is a bug and not the intended behaviour? ie. If the methods to hard-code a stack exist then they should correclty load all related files?

Joe
JohntheFish replied on at Permalink Reply
JohntheFish
The internals of the code that loads a stack also have code to look for and load associated scripts and css for blocks in the stack. However, if block caching is enabled, that could get out of step, and I have no knowledge if a hard coded stack would behave the same way.
jawbonelid replied on at Permalink Reply
jawbonelid
It seems that the only solution to this is to create a global area. However, I'd like to lock down editing of the global area and when doing this in Dashboard > Stacks > Global areas the settings do not seem to make any difference...
jawbonelid replied on at Permalink Reply
jawbonelid
My bad. The admin account is not affected by permission settings!