Issue with baseUrl in 0.112.0 - 0.112.6

Hi there,

I apologize if this is a known issue or if we are simply not using Hugo properly, but I am having an issue with the --baseURL CLI argument. First, some context:

I am building a site using the “course” theme from this repo: GitHub - mitodl/ocw-hugo-themes: A Hugo theme for building OCW websites

We keep the content for course sites in their own separate repos; this is an example: GitHub - gumaerc-testorg/10.01-spring-2020-2

We keep our Hugo config files in a separate repo here: GitHub - mitodl/ocw-hugo-projects: A collection of Hugo project templates for different types of OCW websites

We have an instance of Concourse (a CI/CD platform) that handles running builds and deploying the site. Course sites are built individually and placed in a subfolder of a larger website, and --baseURL is set at build time to ensure links all point to the right place. When the Hugo command is run, it looks something like this:

hugo --themesDir ../ocw-hugo-themes/ --config ../ocw-hugo-projects/ocw-course-v2/config.yaml --baseURL /courses/10-01-ethics-for-engineers-artificial-intelligence-spring-2020 --destination output-online

I’m currently testing upgrading our build to use Hugo 0.112.6, and we’re currently using 0.111.3. When I run the above command using Hugo 0.112.6, links on the site are rendered without the --baseURL setting. For example:

root@595900b2-97e0-4792-4202-cff2b2805295:/tmp/build/b74a5319/course-markdown# cat output-online/index.html | grep syllabus
  <meta name="keywords" content="opencourseware,MIT OCW,courseware,MIT opencourseware,Free Courses,class notes,class syllabus,class materials,tutorials,online courses,MIT courses">
        href="/pages/syllabus">
        href="/pages/syllabus">

When I switch the Hugo version back to 0.111.3, the links render properly:

root@595900b2-97e0-4792-4202-cff2b2805295:/tmp/build/b74a5319/course-markdown# cat output-online/index.html | grep syllabus
  <meta name="keywords" content="opencourseware,MIT OCW,courseware,MIT opencourseware,Free Courses,class notes,class syllabus,class materials,tutorials,online courses,MIT courses">
        href="/courses/10-01-ethics-for-engineers-artificial-intelligence-spring-2020/pages/syllabus">
        href="/courses/10-01-ethics-for-engineers-artificial-intelligence-spring-2020/pages/syllabus">

Here is an example of this course on the live site: Ethics for Engineers: Artificial Intelligence | Chemical Engineering | MIT OpenCourseWare

Is there something wrong with the way we’re using the --baseURL setting here? The documentation says that it should have the full domain and protocol, but using it this way has always worked for us until now. I did try setting --baseURL to a fully qualified URL and that did not work either. Either way, it seems something in 0.112.x has broken this for us and I’m confused as to why.

Doing some more investigation here, it seems to be more specifically an issue with how we are setting up menu URLs. Our content is authored with a custom CMS that we built: GitHub - mitodl/ocw-studio: Open Source Courseware authoring tool. We need to incorporate both internal and external links in our nav and have content editors be able to determine the order, so putting them in a config file made more sense. The CMS writes a file at config/_default/menus.yaml with content that looks like this: 10.01-spring-2020-2/menus.yaml at main · gumaerc-testorg/10.01-spring-2020-2 · GitHub. In our partial that returns this URL, we call {{ return .menuItem.URL }}. So, it seems that baseURL is not applied to URLs implemented in this way anymore?

I can reproduce the behavioral change, and I don’t think it was intentional.

Having said that, the idiomatic way to define menu entries for internal links is with the pageRef property instead of the url property. That works as expected with with v0.112.0 and later.

We updated the documentation after the last time you and I discussed some of this.

I will create an issue to track this.

Right, pageRef! I remembered you mentioning that during our last discussion and was just about to try it out, thank you for reminding me. Our use case is certainly somewhat atypical, but I’m glad that there is a solution.

If you globally change your menu config files to use pageRef instead of url, make sure that the value is a valid page path. I’ve seen some strange settings in the wild. The one config file you shared looks good to me, but you should check nevertheless.

1 Like

Our internal menu items are verified by the CMS before being written into the config as actual page paths, so I believe we’re covered there but that’s a good thought. The bigger challenge for us is making sure that the key is updated in the Github repo for every one of MIT’s 2700+ OCW courses before we start using the new Docker container with Hugo 0.112.x. We can make the change in the CMS to write in pageRef instead of url, but we will need to publish that to every repo while making sure that other changes actually in progress by content editors does not go live. If we don’t do that and push the new Docker container live, rebuilds of already published sites will result in broken nav links.

1 Like

https://github.com/gohugoio/hugo/issues/11062

2 Likes

I suspect this will be fixed very quickly.

1 Like

Thanks for filing the issue, looks like it did get fixed. I’m still going to recommend that we switch to using pageRef as that looks like a better way to reference internal pages.

2 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.