Hugo: Allow "per type" Output Format assignment

Created on 29 Jan 2019  Â·  10Comments  Â·  Source: gohugoio/hugo

Currently, output formats can only be assigned in batch to page kinds.

The Problem

This is problematic as there is no way for a user to assign an output format to only one type of content even though on many big scale projects, Output Formats are rarely shared by multiple content types.

Only current workaround is to simply include template files for the given output format exclusively in the chosen type layout directory and nowhere else.
This workaround used to be satisfactory, but now a sensible warning logs each absence of needed template file. On 5000 pages, this warning can be quite redundant and the user does not have any way to remove it.

__Consider the following project:__

Some content of type "event" needs to generate a calendar file.
The site sports + 5000 pages and a couple hundreds events.
With the current configuration, user can only add the calendar output format to every pages like the following, thus generating + 5000 calendar files :

outputs:
  home:
    - HTML
    - JSON
 page:
    - HTML
    - JSON
    - event_icf

Or, devise a system so the calendar output format is assigned through the Front Matter of each event md file rather than the site's configFile. Though this is problematic when non-developer content editor are in charge of creating them.

Proposal

Ideal solution would be for the user to keep using the current config syntax for current projects while allowing the use of maps instead of slices for « per type » configuration:

outputs:
  home:
    - HTML
    - JSON
 page:
    - HTML
 event:
    page:
       - event_icf
    section:
       - JSON

The values of the maps could either list every needed outputs for each type, or merge listed ones with the "per kind" configuration.

If the above seems to complex to implement we could also isolate "per type" config a new key: types.

Enhancement Keep

Most helpful comment

Let's let this linger for a week or two. It should be fairly trivial to implement an improvement in this area that also considers page types.

All 10 comments

Currently, output formats can only be assigned to page kinds.

That's not true.

I covered FM and it's problematic when content editor are supposed to handle output formats assignation on every page creation. Is there another way than configFile and FM?

Is there another way than configFile and FM?

No, but the statement didn't fit my world view.

So, I kind of agree with you in general, but I think/hope that this will improve once (or if) I finish the work I'm currently doing.

For any of the traditional output format use cases (search is one), you will most often want it for one or more of the list types (typically the home page), but you would want the "page lists" to better match the output format you're currently rendering.

There are, at least, two known issues where this behaves badly:

  • .Render inside ranges
  • Content/shortcode content inside ranges

The last item above will be extra relevant once we get content rendering per output format.

So, I claim that for most output format use cases, you will not configure this on regular pages, and putting this into home/section/whatever front matter would not be that much of a hassle.

I will consider this, but I'm not implementing it before the before-mentioned issues are fixed.

So, I claim that for most output format use cases, you will not configure this on regular pages, and putting this into home/section/whatever front matter would not be that much of a hassle.

I beg to differ. We use that pattern. for /page/ some examples /page/index.json /page/transcript page/archive /page/buyer-info

It's a very helpful pattern for media sites and product sites. In fact, just had a conversation where we're going to use that pattern to differentiate free and paywall content.

Let's let this linger for a week or two. It should be fairly trivial to implement an improvement in this area that also considers page types.

Just an added note, I think the natural change (which also makes it easy to keep the old as "legacy format") is something ala:

[[outputs]]
[[outputs.HTML]]
kinds = ["home", "section" ]
types = ["blog"]
[[outputs.JSON]]
[[outputs.event_icf]]

I do wish, however, that we would somehow standardize on the "config page selection" re. #5455 -- eg. this part above:

kinds = ["home", "section" ]
types = ["blog"]

Which basically means "apply these output formats to this selection of pages". But I guess the above will make an OK start (kinds and types ...)

The syntax above makes all selected types share the same “kind” settings.

Which I guess could cover most cases but not all.

I’ll try and think of something more in the line of what you propose but allowing a more permissive kind/type setting.

Also this make me realize. If this is implemented wouldn’t we have a way for Hugo __not__ to create HTML output on some types (removing some needs of headless bundle) or would this create a problem on the core side ?

If this is implemented wouldn’t we have a way for Hugo not to create HTML

This is not about that. Every page currently needs at least 1 output format. It will be assigned one if not provided/configured.

Think of this particular issue as a improved way to assign output formats to pages.

Think of this particular issue as a improved way to assign output formats to pages.

That said, we should maybe think about adding some future way of telling Hugo that this is a "conclusive list" ...

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

Was this page helpful?
0 / 5 - 0 ratings