Default non-post layout is Archive?

[erichgoldman]

In [siteroot]/templates/_layout.mustache the logic say if post, use post layout else use archive layout.

However, if you then make a new regular page in contents without explicitly making a template, it would default the archive display. Given contents/test.json:

{
        "page-title": "Test Page Here",
        "title": "Test",
        "content": "This is my test page's content"
}

without a templates/test.mustache it will display an archive page that is of no use.

I imagine I could just make a page.mustache and swithc the login in _layout.mustache, but I am also guessing there is a reason for the default to archive?

What logic is needed to create something like a {{#is_page}} check?

Is it also possible to specify the layout at a given level explicitly in the page's json? This would be very helpful if you had some basic layouts (e.g., use 2 column or 3 column on a particular page) you would want to reuse without having to make a new layout in templates or even using a symlink which can make for a cluttered directory?

[erichgoldman]

I'm new to git so I'm not sure how to make and set a patch, but here is what I did to address this

[siteroot]/templates/_layout.mustache:

{{> header }}

                {{#is_post}}
                        {{> post}}
                {{/is_post}}

                {{#is_page}}
                        {{> page}}
                {{/is_page}}

                {{^is_post}}
                        {{^is_page}}
                                {{> archive}}
                        {{/is_page}}
                {{/is_post}}

{{> footer }}

Was not sure if you could do an expression in mustache above `{{^(is_post && is_page)}} or if there was a if/elseif/else or case syntax for musache.

[siteroot]/templates/_page.mustache:

<div id="main-content">
  <h2>{{title}}</h2>
    {{{content}}}
</div>

[siteroot]/content/test.json:

{
        "page-title": "Test Page Here",
        "title": "Test",
        "content": "This is my test page's content",
        "is_page": true
}

The problem with this approach is that I would need to explicitly call is_page, thought I was successful if i just added this to the JSON in [siteroot]/content/shared.json; if you make an explicit template e.g., test2.mustache for test2.json it will still load that because the page template take precedence. I wonder if its also possible to set the template name explicitly this way? With some type of JSON property "use_template" which will try to find a named template then roll back to the default?

It also seems that if you put "is_page": true into the [siteroot]/content/shared.json then it will also apply the property to any of the posts as well. You would have to modify [siteroot]/templates/_layout.mustache with a more complex logic test.

The negative outcome of this is that is breaks the archive page because it still thinks its a page, but its not a page in the actual contents directory, so you cannot set "is_page": false.

Though if you want in any other file you can override shared.json

{
        "title": "Don't load the page layout",
        "is_page": false
}

This method is quickly getting very messy and complicated, so how can we do something similar that is more simplistic and increases the universality of the app?

[laktek]

Blog boilerplate is intended to be used for a blog with few pages (eg. index and about pages). I think it makes sense to define explicit layouts for such pages, as each of them got its own structure.

However, if you want to have bunch of similar pages along with the blog, consider moving the blog into a sub-directory (ie. /blogs). So you can move the layout for the blog into templates/blogs/_layout.mustache and keep the global _layout.mustache clean for the pages.

Using directories to structure the site's content and using section layouts would be the best way to handle this case.

[erichgoldman]

I'll give that a try a report back. Though, if I need to maintain two different installs for a "site" vs "blog" that seems very little difference then just using jekyll for the blog part? I think it makes the "punch system" more robust if its treated as a feature rather than separate.

When you say subdirectory, do you mean moving [siteroot]/posts to [siteroot]/contents/posts? Will that still work?

[laktek]

You don't need to maintain two different installations for the "site" and "blog". Both will work together. I only suggested to change the directory organization, so the most appropriate layout will be picked for the context.

You don't need to change the [siteroot]/posts. Just change the output path for the posts in config.json:

"blog": {
        ....    
        "post_url": "posts/{year}/{month}/{date}/{title}", 
}