Interactive shell/tool?

in the hugo docs,[1]
There are examples where it appears as if the author is interacting with hugo querying for data evaluation in a dynamic fashion:


{{ (index .Site.Data.locations .Params.location).pop_city }}
=> 658390

is there an elegant way to do this from a cli?

or is it not really a thing, but just contrived examples to convey the current behavior being demonstrated
This was kinda discussed here: 12708
I’m not sure if there are other places.
I dunno how useful this would practically be for most people, so I don’t imagine it’s a thing, but I didn’t want to just assume it wasn’t without askin :wink:

  1. Which have gotten MUCH MORE INTUITIVE in recent months. THANK YOU SO VERY MUCH FOR THIS!!! ↩︎

Dynamic playground as described in the linked thread: no.

CLI command to pull data from /home/user/my-project/data: yes.

  • JSON: use jq
  • TOML or YAML: pipe output from yj to jq

yeah; formatters / cross-datatype like y2j, et al are neat… but that’s not really what I was hoping existed.

if hugo is running in server mode, is there a way to interact with a site being served in a more dynamic/debugger/data-exploration-centric fashion?

My idea/desire was around being able to query/interact/peek into a site context and observe data structures in an accurate-to-the-rendered-site-in-question way…

barring that, are there tools that are current / actively used to interact with a hugo site object outside of a webbrowser context?

I ask, as I’m trying to figure out some of my various egregious logic flaws…

I was thinking that if I could observe the data structures that hugo has built from my feeble attempts to create a thing and then contrast that by observing the data structures hugo creates from other[1] sites[2] I could identify my logic flaws in my site with greater ease.

  1. hopefully better architected ↩︎

  2. by cloning the public repos and serving their examplesites ↩︎

What “site”? Hugo produces and (as a server) delivers HTML documents. In server mode, it does nothing but send the documents via HTTP to the browser. You could use your browser’s devtools to interact with those. That’s the only “interactive tool” I know of.

What’s that supposed to be?

You would make sense if there was anything dynamic in what hugo produces, but there is nothing to ask interactively about static html/whatever pages. The source code is all the data they’ll ever contain.

Hi there…

I don’t intend to be antagonistic; however your response feels a bit… snarky?
I’m assuming that i’m simply misreading your tone; which is easy to do in text :slight_smile:

pleased to meet you, I’m wolf.
thanks for talking through this with me.

sure, most stuff is built only when hugo first assembles the site… but it seems to me that when running in server mode hugo needs an awareness of the site context and content in some proto-rendered state to facilitate interactions which leverage data via getjson / other remote data to generate the static html content… yes, some stuff is fetched and processed client side,

however i think (but certainly could be wrong here) its doing a bit more than jus serving the static assets it previously built…. but thats also why im askin this :slight_smile:

by the site object, im referring to the abstract notion of $site for a domain… IDK if each lang variant gets its own bubble of context or if they’re sub-entities of the parent (I’d assume the latter but ¯\_(ツ)_/¯ )

what would you refer to that as?

All stuff is built …

What is a “proto-rendered state”? getjson as everything else is executed first to create the HTML documents, sitemap, whatever you’ve defined.

Check it out by having Hugo render to disk in server mode. Then turn Hugo off and look at the public directory. There’s nothing magic proto or IDK (no idea what that is) or a “site object”. Just a directory full of stuff a web server can serve.

yep! AND, some is cached/static thereafter; some can be rebuilt on the fly per request, yes?

(granted, one has to disable caching, etc)

IDK = I Don’t Know :slight_smile:

yep! AND… by protorendered state I mean the difference between fastrebuilt and full rebuild on change… how’s that work if there’s no par-baked phase?

The snarkiness was unintentional :upside_down_face:

heya Tom,

nah, you’re fine. I wasn’t referring to yer response there… but even if I were, it’s nothin to fret bout

I am just as guilty of being momentarily thoughtless wrt wording in responses as any of us….

We’re all human, an well… I don’t know bout you, but I myself am pretty strange an my humor occasionally lands quite poorly.

regardless… the point is that i’m under the impression that hugo creates an object in memory that it manipulates to create the site… and retains that object, or some flavor of it, while running in server mode…

assuming that impression is accurate, the question on the table is
how might one view, (and interact ??) with that object in more of a diagnostic mode…

I want to use this in a fashion similar to how you were trying to identify recently why that if statement in a menu resulted in exiting in a different context … (i’m actually trying to pin down a logic bug of mine somewhat similar to this)

the ability to assess/ view / interrogate the context as it transits these conditionals to better understand how I’m being dense is what I’m looking for…

does that make more sense?


It’s in fact a lot clearer. But I don’t think it’s possible. If you get an error was the one you referred to, you have to hunt down it’s source in your code. And if Hugo doesn’t recreate all files that it should recreate after a change, you have to restart the server.

To see what Hugo generates, use renderToDisk and check out the public directory.