What is a better way to include a full external html page and its resources into blog


#1

Go Hugo!!! :slight_smile:

I have a question regarding where to keep an externally and automatically generated html page (and its associated resources) into my hugo blog.

I have an application that runs some code and generates a full web page containing plots, tables, etc. that summarizes the results for that case.

I then write a blog post describing the case example in detail, e.g., explaining each plot, etc, but I still want to have the option to include that externally generated page and all its resources within hugo. This is because some users (e.g., experienced ones) may just want to scan the results without the details in the blog post.

I am hoping I can just copy the directory of the external web page and embed it somewhere in the hugo directory hierarchy.

Yes, the html page header sections will be different but the application also generates the same body html string but with no headers. Hopefully, I can use the latter somehow if a simple directory copy does not work.

Thanks


#2

Put the pages and their assets under static. If you used static/cases/ then it would translate to:

 http://example.com/cases/case-123324

#3

There are 3 alternative ways to include “full external HTML”:

  1. Put the HTML with all its resources inside /static
  2. Put the HTML in /content (put the resources etc. in /content or /static …)
  3. Same as 3 but with front matter

I will not get into detail about the 3, they should be easy testable – but the the last 2 can include template syntax and the last one is a fulll blown content file with layouts and shortcodes etc.


#4

Thanks Rick.

I tried it.

It worked like a charm.

The layout is different (to be expected) from the blog proper but I can live with that. This is inline with my preference for an automated approach where, after the application is done, all necessary web files are pushed to the appropriate folder in hugo.

I can also organize the results based on folders under /static/cases in your example.


#5

bep,

Thanks for providing multiple options to accomplish my task.

I imagine one of these options will deal with the different layout issue.

The problem is there are many cases, and lots of web-related files for each case that an automated approach, where I dump the files, is the better option.

It seems your 1. solution and Rick’s is in line with that approach.

Thx.