-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Comments
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? |
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:
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. |
I beg to differ. We use that pattern. for 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:
I do wish, however, that we would somehow standardize on the "config page selection" re. #5455 -- eg. this part above:
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 ? |
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. |
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. |
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 :
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:
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
.The text was updated successfully, but these errors were encountered: