Skip to content

hugo new theme does not create a baseof.html #3576

Closed

Description

@juh2

As Block-Templates are the new default I think that the directory layout of a theme created by hugo new should reflect this and create a baseof.html in _default.

Activity

  1. digitalcraftsman commented on Jun 10, 2017

    @digitalcraftsman
    Contributor

    Hello @juh2,

    Block-Templates are the new default I think

    We make no assumptions about the user and the structure of his theme. Block templates are still optional, hence they don't have to be used by default.

    But it would make sense to encourage theme creators to make use of baseof.html since it removes a lot of redundancy. Creating a baseof.html when executing hugo new theme xyz might also help to increase its adaption.

    If you think baseof.html should be created by default then label this issue as a feature request.

    What remains is the question whether the adoption of block templates outweighs the assumptions of the users and his intended theme structure.

  2. juh2 commented on Jun 10, 2017

    @juh2
    Author

    Thanks for the clarification.

    I see no obvious button to label this issue as feature request.

    Could someone with more insight or rights do this?

    TIA

  3. bep commented on Jun 10, 2017

    @bep
    Member

    I agree with @juh2 that most would really want a baseof.html if they knew about it. But we should then set up a basic structure with a content section etc.

  4. rdwatters commented on Jun 10, 2017

    @rdwatters
    Contributor

    Here's what is currently generated:

    .
    ├── LICENSE.md
    ├── archetypes
    │   └── default.md
    ├── layouts
    │   ├── 404.html
    │   ├── _default
    │   │   ├── list.html
    │   │   └── single.html
    │   ├── index.html
    │   └── partials
    │       ├── footer.html
    │       └── header.html
    ├── static
    │   ├── css
    │   └── js
    └── theme.toml
    

    How about the addition of baseof.html, shortcodes, and img? Seems like content and data should stay independent of the theme scaffolding. Also, I'm not especially firm on img:

    .
    ├── LICENSE.md
    ├── archetypes
    │   └── default.md
    ├── layouts
    │   ├── 404.html
    │   ├── _default
    │   │   ├── baseof.html
    │   │   ├── list.html
    │   │   └── single.html
    │   ├── index.html
    │   ├── partials
    │   │ ├── footer.html
    │   │ └── header.html
    │   └── shortcodes
    ├── static
    │   ├── css
    │   ├── img
    │   └── js
    └── theme.toml
    
  5. bep commented on Jun 10, 2017

    @bep
    Member

    Let us keep this issue about ... besof.html and not add a lot of other issues on top.

  6. rdwatters commented on Jun 10, 2017

    @rdwatters
    Contributor

    You mentioned a content section as well, so I was running with it. Is this in the "beginner" or "easy" category,@bep? Maybe I can give it a shot 😄

  7. digitalcraftsman commented on Jun 11, 2017

    @digitalcraftsman
    Contributor

    The general tenor of the comments seems to supports this proposal. I would to extend this thought by linking the files together as follows:

    Hugo generates header.html and footer.html by default. So the baseof.html would look like this:

    {{- partial "header.html" . -}}
    
    {{- block "main" . }}{{- end }}
    
    {{- partial "footer.html" . -}}

    404.html, list.html, single.html and index.html would consist of

    {{- define "main" }}{{- end }}
    
  8. rdwatters commented on Jun 11, 2017

    @rdwatters
    Contributor

    I would second the idea of including some partial calls as noted above by @digitalcraftsman. Simple enough to clue in new users and not so complicated that people end up deleting a bunch of scaffolding to get up and running...

  9. bep commented on Jun 11, 2017

    @bep
    Member

    @digitalcraftsman I think the header/footer is an antipattern that the baseof.html solves -- and we should fix that. In the example you give, neither the header nor the footer is well-formed HTML document that can easily be edited/formatted by an editor. The baseof.html should form a simple and well formed HTML document with closing tags.

  10. digitalcraftsman commented on Jun 11, 2017

    @digitalcraftsman
    Contributor

    @bep with my understanding of your comment you propose that baseof.html should contain the whole skeleton for a page, i.e. it "should form a simple and well formed HTML document with closing tags.".

    Would a minimalistic baseof.html would look like this?

    <html>
        <head>
            <title>Hugo</title>
            <!-- some other stuff -->
        </head>
        <body>
            <div id="content">
            {{- block "main" . }}{{- end }}
            </div>
    
            <footer>
                <!-- copyright etc. -->
            </footer>
        </body>
    </html>

    I see the inclusion of the header.html and footer.html in baseof.html as a composition of simple templates that form a larger and more complex one.

  11. bep commented on Jun 11, 2017

    @bep
    Member

    The partial pattern is still useful and should still be part of the scheleton, as long as the templates are well formed:

    <html>
        {{- partial "header.html" . -}}
        <body>
            <div id="content">
            {{- block "main" . }}{{- end }}
            </div>
            {{- partial "footer.html" . -}}
        </body>
    </html>

    Or variants of the above. In the above, all templates are well formed (base + footer + partial).

  12. digitalcraftsman commented on Jun 11, 2017

    @digitalcraftsman
    Contributor

    Got it.

  13. rdwatters commented on Jun 11, 2017

    @rdwatters
    Contributor

    If I may get more granular, I would only suggest that there be a head.html and a header.html since head.html tends to get very big very quickly:

    <html>
        <head>
        {{- partial "head.html" . -}}
        </head>
        <body>
            {{- partial "header.html" . -}}
            <div id="content">
            {{- block "main" . }}{{- end }}
            </div>
            {{- partial "footer.html" . -}}
        </body>
    </html>

    Anything more than this, though, and I'm probably just getting too opinionated 😄

  14. bep commented on Jun 11, 2017

    @bep
    Member

    @rdwatters sure, but in your example head.html would not be well formed on its own.

  15. 4 remaining items

  16. anthonyfok commented on Jun 2, 2018

    @anthonyfok
    Member

    I got here from:

    1. baseof.html not used unless its executable in Debian #4808
    2. https://discourse.gohugo.io/t/what-are-the-pros-cons-of-using-a-baseof-template-or-the-standard-template/8048/4
    3. hugo new theme does not create a baseof.html #3576 (comment)

    digitalcraftsman wrote:

    But it would make sense to encourage theme creators to make use of baseof.html since it removes a lot of redundancy. Creating a baseof.html when executing hugo new theme xyz might also help to increase its adaption.

    Sounds like a great idea!

    Both bep and rdwatters wrote:

    <html>
        {{- partial "head.html" . -}}
        <body>
            {{- partial "header.html" . -}}
            <div id="content">
            {{- block "main" . }}{{- end }}
            </div>
            {{- partial "footer.html" . -}}
        </body>
    </html>

    Hohoho! Great minds think alike!

    Since everyone has come to a consensus, I think it would be interesting to implement it in hugo new theme and maybe even in hugo new site (in a new interactive mode) with more instruction and guidance to the person starting a new website or a new theme. With new theme especially, perhaps some guidance can ben written and some recommended licenses be offered...

  17. self-assigned this
    on Jun 2, 2018
  18. added a commit that references this issue on Jun 11, 2018
    bdaa62a
  19. added a commit that references this issue on Jun 11, 2018
    9717ac7
  20. added this to the v0.42 milestone on Jun 11, 2018
  21. github-actions commented on Mar 3, 2022

    @github-actions

    This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

  22. locked as resolved and limited conversation to collaborators on Mar 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions