UglyURLS = true, results in conflict which requires workaround for directory /content/directory/ level files of "legacy" sites

Please pardon, I had posted this as a bug, however it seems I was in remiss in that it seems that one discusses a possible bug (as it might not be) and then if it is a bug, posts it as a bug. . My English is not the best, and this is my first (second as I posted this as a bug) posting in a technical forum, so I appreciate everyone’s patience.

This has been the subject of two previous threads, however, one post originator was excessively rude, so I believe a valid concern was buried under disrespect, also, now dealing with a more intensive production environ and legacy sites, I can perhaps shed more light.

The issue:

A seemingly common method of organizing a site is to have files represented by .html, and a directory represented by an index.html site within that directory.

  1. Al la: /content/category/index.html
    would resolve to:
    /content/category/

and

  1. /content/category/this.html
    would resolve to
    /content/category/this.html

Now, if one wants to keep large swaths of their legacy content intact in terms of paths and URLS
one can set Ugly URLS to true in their config file.

This allows one to keep their structure in tact for point “2” above.

However, it does not for point “1” above.

This then leads one to:

As this is an existing site, existing blog (well, many existing sites) their are existing structures, directories, links, hardcoded URLs. Tens of thousands.

One then needs to progress into intensive, highly intensive GREPing, Aliases and/or redirects, which are not optimum.

Of note, their seems nothing actually wrong with the described pattern of file paths explicitly represented (/content/category/this.html) and directories (/content/category/) being represented by (/content/category/index.html). Possibly their is something wrong with that system, however it is somewhat widely in use and that then pushes necessity of use.

It seems that their is a bug in that a relatively common or standard system structure is between the two options of “true” and “false” of UglyURLs, and since most production environs will port existing structures and content it seems an option does not exist that possibly should, to standardly implement the above structure.

I will move forward by creating simply Aliases, but that is a workaround. This is a possible incorrect concept, but, I have found truth in Physical Engineering, where a workaround signifies avenues of valid research and thought (though, albeit, this is a small point).

Only in that I believe this thought process could be a small, more seamless, improvement allowing further use of an excellent tool, I wanted to take the time to share this. Thank you for your time.

uglyURLs is a site wide configuration and when set to true Hugo will output the URL of all pages with the .html extension.

There is no way to use it selectively, so that top level sections and taxonomies are published without the .html extension (as you describe above).

Current behaviour seems unlikely to change as it would break many existing Hugo projects.

Your only option is to use redirects or Hugo aliases.

Thank you for the fast answer, I much appreciate.
Your points sound valid but their is possibly a logical fallacy. I’m not remotely experienced enough to validate the undercurrents of your logic, are you by chance (I do not mean that rudely if it sound such, I don’t know how to ask that appropriately and google translate looses nuance)? Your point is valid if the only way to implement the concept is by breaking uglyURLs, I do not know how it is implemented, I do not know even how to check… I would very much appreciate anything you have to say on this or clarify…

Setting url in front matter is a little cleaner: no page refreshes, and no debris in the public directory.

With uglyURLs = true in config.toml, this directory structure:

content
└── articles
    ├── article-1.md
    └── _index.md

where the contents of _index.md are:

+++
title = "Articles"
date = 2021-04-13T10:51:17-07:00
draft = false
url = "/articles/"
+++

Produces these files in the public directory:

public/
└── articles
    ├── article-1.html
    └── index.html
1 Like

It turns out you can accomplish this via site configuration.

baseURL = "http://example.org/"
languageCode = "en-us"
title = "@@TITLE@@"

uglyURLs = true

[outputFormats]
[outputFormats.html-pretty-urls]
mediaType = "text/html"
isHTML = true
noUgly = true

[outputs]
section =   ["HTML-PRETTY-URLS", "RSS"]
taxonomy =  ["HTML-PRETTY-URLS", "RSS"]
term =      ["HTML-PRETTY-URLS", "RSS"]

You don’t need to create additional templates, and you don’t need to change front matter anywhere.

I only spent a couple of minutes testing this, so caveat emptor.

4 Likes

Mr. Mooring, thank you very much and excellent! Pardon my assumption it was a bug, this works perfectly and rather! I wasn’t aware caveat emptor was used in English. Yes! Strict Tort liability would be funny in such an environ no :slight_smile: ? Nonetheless, much appreciated! I’ll be working with this and if I find any cases Sui generis I will note for the sake of sharing.

I do however need to understand more of WHY this works, so will research it out, hopefully not remain a neophyte forever…

Clever technique @jmooring

Perhaps you should post it as a dedicated tips & tricks, so that it is easier to find, when using the forum search.

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