Theme standards and general experience

[lebarde]

@jhabdas

On GH you mentioned WordPress child themes. My understanding is the primary benefit for Child themes in WordPress is to prevent individual theme customizations to the functions.php file from being wiped out during WP Core upgrades. Because Hugo does not use such a rig, I’m having trouble understanding the upside to the whole extends idea. Given Hugo supports the ability to perform layout inheritance within sites (which works especially well with block templates), what value would adding another N levels of inheritance buy us in your eyes?

In my understanding, the primary benefit for Child Themes in Wordpress is to prevent all individual theme customizations from being wiped out during theme upgrades.

I am so glad to learn about the block templates thing!! I did not know that we could already do template inheritance. This is great news for me, as I understand now that it is easy to extend a theme by externally modifying templates.

@jhabdas

What exactly is a Widget and why would I want one? The terms widget, component, plugin, module, etc. are all traditionally loosely defined and, as a result, seem to complicate the CLI proposal using get which may never be used for more than themes (assuming widgets aren’t a thing, because they don’t exist yet) and building such a thing would be difficult given the ambiguous definition of “widget”, adding friction to advancement and justification of a get sub in the CLI.

Here I described what I intended widgets for: Widget mechanism.

@jhabdas

It seems the primary goal here is to ease the selection of themes for improved DX and Hugo end user experience. Is that correct? If so, given current themes and tooling do you feel the existing theme gallery could be improved? And, if so, what if any thoughts do you have to help improve the gallery without introducing a new CLI command?

Totally correct from my views

Actually, I find that switching themes is not so easy for the moment. As it is, the theme gallery is very nice and I like it very much. It is easy enough (at least for me) to install new themes, although I don’t know if it is easy to do it without git.

I experienced that switching themes:

• often broke my site (the site did not build anymore or had empty pages)
• often needed big modifications to my config file, because themes required arbitrary params. This is nice because the theme developer has freedom, but after only 3 theme tries this leads to config files that look like this:

baseurl: "http://www.blah/"
languageCode: "fr-fr"
title: "my title"
subtitle: "my subtitle"

theme: hemingway2
#theme: hugo-material-docs
#theme: hugo-me-theme
#theme: hugo-multi-bootswatch

metadataformat: "yaml"
canonifyurls: true
# Enable Google Analytics by entering your tracking id
googleAnalytics: ""

paginate: 5
paginatePath: "page"


params:
    # FOR THEME hugo-material-docs

    author: Le Barde
    # General information
    description: ""
    copyright: "Licence CC-BY-NC."

    #version: "1.0.0"
    logo: "images/logo.png"
    favicon: ""


    # Custom assets
    custom_css: []
    custom_js: ["https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML", "mathjax-support.js"]

    # Syntax highlighting theme
    highlight_css: ""

    palette:
      primary: "deep-purple"
      accent: "red"
      
    font:
      text: "Ubuntu"
      code: "Ubuntu Mono"

    # FOR THEME hugo-theme-me
    colorscheme: red
    sidebar:
      name: "Me"
      description: "A Simple Hugo Theme"
      #navigation:
      #  label: "About"
      #  link: "/about"
    about:
      title: "Hello, It's Me!"
      intro: "Welcome to my page!"
      text: "I am a simple responsive theme for [Hugo](http://gohugo.io) based on [Read Only template](http://html5up.net/read-only) by HTML5UP. To install Me just run inside your Hugo project:\n\n    $ mkdir themes\n    $ cd themes\n    $ git clone https://github.com/aerohub/hugo-me-theme.git hugo-me-theme\n\n See [README](//github.com/aerohub/hugo-me-theme) for more information."
    skills:
      label: "About"
      link: "/about"
    work:
      title: "Few Works Made by Me"
      intro: "Let Me present here its color schemes"
    email: "contact@mydomain.fr"
    footer:
      copyright: "[My site](http://www.mydomain.fr). Licence CC-BY-NC."

    # FOR THEME hugo-multi-bootswatch
    theme:
      inverse: false
      name: cerulean
    # list of possible theme names that can be used
    # name: "cerulean"
    # name: "cosmo"
    # name: "cyborg"
    # name: "default"
    # name: "flatly"
    # name: "journal"
    # name: "lumen"
    # name: "paper"
    # name: "readable"
    # name: "sandstone"
    # name: "simplex"
    # name: "slate"
    # name: "spacelabs"
    # name: "superhero"
    # name: "united"
    # name: "yeti"



social:
  #twitter: "lebarde"
  github: "lebarde"


menu:
  main:
    - name: "Accueil"
      url: "/"
      weight: 0
    - name: "Articles"
      url: "/articles"
      weight: 10


blackfriday:
  smartypants: true
  fractions: true
  smartDashes: true
  plainIDAnchors: true

So, I think the community would appreciate standardization for params (e.g. “Author should be described with params.author”). IMO this should not be a mandatory requirement, but only a recommendation for theme developers that want to share widely.

@jhabdas

And now some opinion. I’m packaging up my theme using NPM because some users might want to install it that way if it makes sense for them. That feels like a very user-specific and personal choice. And I don’t believe attempting to push standards unto themes is going to be effective unless done via standardization during introduction to the theme gallery.

Lastly, what about build pipelines? We have bash and NPM scripts, toolchains like Hugulp, boilerplates using pukes in mouth Webpack etc. How should users be using those in combination with the concepts being proposed here?

What I proposed was not to reinvent the wheel. Only to specify to Hugo what was the push command. This would have enabled to make a hugo full-upgrade command that updated everything, builded and pushed the site to the public server directory. But as I said here, we can already do that externally, so this is not useful.