Restricting content adapter HTML output

support
1

Content adapters are an impressive feature :smirk:

Really great stuff you guys are doing, as usual.

Did I read also somewhere, there is code to restrict the HTML output for a given type of adapter? Specifically in the case where the adapter is used to pass data from JSON into templates, for example?

2

What do you mean by “restrict the HTML output”?

3

I mean “after using the adapter content to pass data to non-adapter templates, do not create HTML output adapter content”.

That would be more efficient than using .gitignore or deleting the repos in post-processing.

4

I read that twice and still have no clue what you mean. Sorry.

5

It’s unlikely I’m using the most accurate language, since I have no idea what you guys are doing except for what is published here and in the docs.

Let me explain it again.

I’m using content adapters to create frontmatter variables from json files with this code:

{{ $page := dict
    "dates" $dates
    "kind" "page"
    "params" $params
    "path" $path
    "title" $title
}}

{{ $.AddPage $page }}

Then accessing the pages created by the adapter and extracting data, like URL strings, image name strings, and heading text.

I don’t need any HTML output in the public folder for the pages created by {{ $.AddPage $page }}

So I delete the folder in my post-processing pipeline, so it doesn’t get pushed with public to the cloud. It would be more efficient, if the HTML page was never created in public.

It seems likely that is accomplished easily with some setting in config, or by adding a variable I’ve yet to learn about, like ‘publish = false’, to the params for each adapter.

[Disable single page output for designated sections ¡ Issue #3612 ¡ gohugoio/hugo ¡ GitHub]

Is there some simple way I’m missing to create markdown from json with content adapters, but skip rendering the markdown to HTML in public?

6

Mmh that sounds a little strange

  • you have a json file
  • read that data
  • write a page using that data in frontmatter
  • parse the new page to create ???
  • discard the new page

Why not directly create your ??? From the json?

There’s also an addResouce method for the content adapter

1 Like
7

“Why not directly create your ??? From the json?”

It’s about the process, as well as the knowledge I have at hand, which is dependent on the usual various constraints (for example time).

I wrote code a few years ago that crawled the web for data, processed it, then turned it into markdown, which Hugo could generate into pages. I had intended to upgrade that process to the process ‘The New Dynamic’ blogged about. Running Hugo twice to first generate markdown content from json (having the crawlers output to json instead of markdown), and then to generate pages, which in that case needed to be output as HTML, as well as used to create ‘???’

Then content adapters dropped and I explored them, then upgraded that process to content adapters, instead of running Hugo twice.

Now I use them also in a case where ‘???’ is necessary, but outputting to HTML is not. I don’t use the json directly but create adapters instead because I’m using the ‘related’ functionality, and the code I explored with that uses a dictionary and opts then relates pages, based on opts inputs, like tags, keywords, and fragments.

All that should be helpful going forward, since getting related to work well is probably a function of more ongoing experimentation.

Does related work just from resources (example addResource method), or from loading json from the Data directory? If so, please send the link, though I find adapters easy to conceptualize, especially when storing json in assets.

At the end of the day, I’ve written the code to do what it needs to do (which is to relate content), but in the case where it’s only ‘???’ and not ‘??? and pages’, I don’t want to use the compute to turn the pages into HTML and then delete them (unless it’s really negligible, in terms of compute).

8

https://gohugo.io/content-management/build-options/

For example…

content/books/_content.gotmpl

{ $content := dict
  "mediaType" "text/markdown"
  "value" "The _Hunchback of Notre Dame_ was written by Victor Hugo."
}}
{{ $page := dict
  "content" $content
  "kind" "page"
  "path" "the-hunchback-of-notre-dame"
  "title" "The Hunchback of Notre Dame"
  "build" (dict "render" "never")
}}
{{ .AddPage $page }}
1 Like
9

That does it. I had them in $params


{{ $content := dict
  "mediaType" "text/markdown"
  "value" "The _Hunchback of Notre Dame_ was written by Victor Hugo."
}

{{- $params := dict ... "build.list" "always" "build.publishResources" "false" "build.render" "never" ... -}}

{{ $page := dict
  "content" $content
  "kind" "page"
  "path" "the-hunchback-of-notre-dame"
  "title" "The Hunchback of Notre Dame"
   "params" $params
}}
{{ .AddPage $page }}
10

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