Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow "per type" Output Format assignment #5652

Open
regisphilibert opened this issue Jan 29, 2019 · 11 comments
Open

Allow "per type" Output Format assignment #5652

regisphilibert opened this issue Jan 29, 2019 · 11 comments

Comments

@regisphilibert
Copy link
Member

regisphilibert commented Jan 29, 2019

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.

@bep
Copy link
Member

bep commented Jan 29, 2019

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

That's not true.

@regisphilibert
Copy link
Member Author

regisphilibert commented Jan 29, 2019

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?

@bep
Copy link
Member

bep commented Jan 29, 2019

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.

@bep bep added the Proposal label Jan 29, 2019
@budparr
Copy link

budparr commented Jan 29, 2019

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.

@bep bep added this to the v0.55 milestone Jan 29, 2019
@bep
Copy link
Member

bep commented Jan 29, 2019

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.

@bep
Copy link
Member

bep commented Jan 30, 2019

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 ...)

@bep bep added Enhancement and removed Proposal labels Jan 30, 2019
@regisphilibert
Copy link
Member Author

regisphilibert commented Jan 30, 2019

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 ?

@bep
Copy link
Member

bep commented Jan 30, 2019

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.

@bep
Copy link
Member

bep commented Jan 30, 2019

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" ...

@bep bep modified the milestones: v0.55, v0.56 Feb 1, 2019
@stale
Copy link

stale bot commented Jun 1, 2019

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.

@stale stale bot added the Stale label Jun 1, 2019
@bep bep added the Keep label Jun 1, 2019
@stale stale bot removed the Stale label Jun 1, 2019
@bep bep modified the milestones: v0.56, v0.57 Jun 14, 2019
@bep bep modified the milestones: v0.57, v0.58 Jul 31, 2019
@bep bep modified the milestones: v0.58, v0.59 Aug 13, 2019
@bep bep modified the milestones: v0.116.0, v0.117.0 Aug 1, 2023
@bep bep modified the milestones: v0.117.0, v0.118.0 Aug 30, 2023
@bep bep modified the milestones: v0.118.0, v0.119.0 Sep 15, 2023
@bep bep modified the milestones: v0.119.0, v0.120.0 Oct 4, 2023
@bep bep modified the milestones: v0.120.0, v0.121.0 Oct 31, 2023
@bep bep modified the milestones: v0.121.0, v0.122.0 Dec 6, 2023
@bep bep modified the milestones: v0.122.0, v0.123.0, v0.124.0 Jan 27, 2024
@bep bep modified the milestones: v0.124.0, v0.125.0 Mar 4, 2024
@bep bep modified the milestones: v0.125.0, v0.126.0 Apr 23, 2024
@bep bep modified the milestones: v0.126.0, v0.127.0 May 15, 2024
@bep bep modified the milestones: v0.127.0, v0.128.0 Jun 8, 2024
@bep bep modified the milestones: v0.128.0, v0.129.0 Jun 21, 2024
@bep bep modified the milestones: v0.129.0, v0.131.0 Jul 22, 2024
@bep bep modified the milestones: v0.131.0, v0.133.0 Aug 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants