templates: migrate Research Group template from v1 to v2 blocks

[Agos95]

Purpose

Content of this PR:

• update research group template to block v2 system (fix Update Research Group Template to Block v2 #2908)
• port Slider block to the v2 collection
  • parameters for the background of each slide have been aligned to the ones of section background, with the exception of the video background
• text content of the Contact block is put inside a <p></p> tag, to preserve the correct spacing between the text and the contact form
• port People (aka Team Members) block to v2 collection

Documentation

Need to create two entries in the blocks documentation for the v2 version of Slider and People.

Updated versions of the code blocks in the docs are:

• Slider

---
title: My Page

type: landing

sections:
  - block: slider
    design:
      # Slide height is automatic unless you force a specific height (e.g. '400px')
      slide_height: ''
      is_fullscreen: true
      # Automatically transition through slides?
      loop: false
      # Duration of transition between slides (in ms)
      interval: 2000
    content:
      slides:
      - title: 👋 Welcome to the group
        content: Take a look at what we're working on...
        align: center
        background:
          image:
            filename: coders.jpg
            filters:
              brightness: 0.7
          position: right
          color: '#666'
      - title: Lunch & Learn ☕️
        content: 'Share your knowledge with the group and explore exciting new topics together!'
        align: left
        background:
          image:
            filename: contact.jpg
            filters:
              brightness: 0.7
          position: center
          color: '#555'
      - title: World-Class Semiconductor Lab
        content: 'Just opened last month!'
        align: right
        background:
          image:
            filename: welcome.jpg
            filters:
              brightness: 0.5
          position: center
          color: '#333'
        link:
          icon: graduation-cap
          icon_pack: fas
          text: Join Us
          url: ../contact/
---

• People

---
title: My Page
type: landing

sections:
  - block: people
    content:
      title: Meet the Team
      # Choose which groups/teams of users to display.
      #   Edit `user_groups` in each user's profile to add them to one or more of these groups.
      user_groups:
          - Principal Investigators
          - Researchers
          - Grad Students
          - Administration
          - Visitors
          - Alumni
      # # Field to sort by; one of: last_name (default), first_name, title
      sort_by: last_name
      sort_ascending: true
    design:
      # Show user's social networking links? (true/false)
      show_social: false
      # Show user's interests? (true/false)
      show_interests: true
      # Show user's role?
      show_role: true
      # Show user's organizations/affiliations?
      show_organizations: true
---

[netlify]

✅ Deploy Preview for hugo-portfolio-theme canceled.

Name	Link
🔨 Latest commit	7a2d5f2
🔍 Latest deploy log	https://app.netlify.com/sites/hugo-portfolio-theme/deploys/643eef3f9ed8f500080e6bd5

[netlify]

👷 Deploy Preview for markdown-slides processing.

Name	Link
🔨 Latest commit	6d828c1
🔍 Latest deploy log	https://app.netlify.com/sites/markdown-slides/deploys/63dfda3028ae91000902f686

[netlify]

✅ Deploy Preview for markdown-slides canceled.

Name	Link
🔨 Latest commit	7a2d5f2
🔍 Latest deploy log	https://app.netlify.com/sites/markdown-slides/deploys/643eef3f86934c00085dbb35

[Agos95]

Added the requested changes. In addition, I also substituted markdownify with $page.RenderString for block.content.text, to be compliant with #2919.

Also, I updated the first comment with the new parameters for the people block.

As soon as the PR will be merged, I'll send another one to fix the go.mod file in the research group.

[gcushen]

@Agos95 please resolve the merge conflicts (contact.html)

[Agos95]

Solved!

[gcushen]

If we prefix .Params. to the sort_by automatically, we should probably do the same for any other uses of the sort_by option in Wowchemy, such as in the Collections (and Portfolio?) blocks, otherwise different behaviours will be very confusing to users.

[Agos95]

Ok, I also remove the automatic .Params. prefix to align this block to the others.
Although, I think maybe it could be nice to have an autoprefix just if last_name, first_name or title are passed as parameters, since these are the most common options to sort the people.

It could be something like:

{{ if in "last_name first_name title" $sort_by }} {{ $sort_by = printf ".Params.%s" $sort_by }}  {{ end }}

What do you think? Otherwise, I'll just remove it, no problem!

[gcushen]

If the first letter of the sort_by param is capitalised then it's a built-in Hugo param right, otherwise it's a parameter which requires prefixing with Params.?

I have also observed that users find this Hugo behaviour very confusing and prone to error.

So I suggest we check if first letter of sort_by is capitalised, if it is then pass it as it is, otherwise prefix it. If this works successfully, then let's apply this logic to all instances where sort_by is used.

[Agos95]

I need to think about this. In principle, I think nothing stops me to create a custom parameter (eg. LastName instead of last_name), so I don't know if this logic can actually be applied.

If you agree, we can close this PR (which I'll immediately follow with a new one to fix the Wowchemy version in go.mod) as it is, so that users need to input .Params.last_name to sort authors by their last name.

Then, I'll open another issue to discuss and investigate about your proposed solution to discover built-in or custom parameters.

[gcushen]

@Agos95 the Wowchemy parameters are all standardised to lowercase-underscore convention, so that is fine, we can go ahead and make things easier for the user based on my above comment at #2914 (comment)

[Agos95]

Ok, I added the function in the wowchemy-core module, since it is independent on bootstrap, and I tested it locally.
I also add it in people, collection and portfolio blocks as comments. This is due to the fact that the version of wowchemy-core must be updated (in modules/wowchemy/go.mod) in order to detect the new function, and I don't have any idea on what I should do.

Maybe the best thing is to merge this PR, create a new tag/version for wowchemy-core, and then I can follow with another PR to fix the versions. But I wait for your instructions, since I don't have any experience on this.

[gcushen]

See #2914 (comment)

In order to merge this PR without splitting it into separate PRs for each module change, we will go ahead with the latter suggestion you made.

[gcushen]

@Agos95 You have attempted to modify 3 Go Modules which depend on each other in a single PR.

However, Hugo needs us specify in each module's go.mod which versions of modules it depends on and we cannot retrieve the version (Git commit ref) until we have merged the PR.

So in future, we should generally submit a separate PR for each module when improvements are made to multiple inherited modules.

To help facilitate merging this, please rebase the branch on the latest "main", uncomment the commented code (it's bad practice for us to commit commented code like {{/* $sort_by), and set the dependency version of each module to main.

Then once we merge, please submit an update as soon as you can to fix each module's go.mod to require a specific version.

Also, feel free to feedback to Hugo team if you have suggestions on how they can improve the module system to make it easier for contributors.