Is it possible to support Twitter card generation for generated pages. This can be a HTML template which is saved as an image. The HTML template and card template can be generated. The Card template output can be referred in the HTML template.
1 Like
That can be done automatically on your site by adding it to your template no?
How is this done? Can you give me a pointer?
I believe this can be achieved by resource/asset processing pipelines in Hugo.
Ah sorry I thought when you meant Twitter card you mean the preview of the website on Twitter. Do you mean actual images?
Generating images like in: https://og-image.vercel.app (GitHub - vercel/og-image: Open Graph Image as a Service - generate cards for Twitter, Facebook, Slack, etc). But more light weight and built in to Zola.
This can be another HTML template which can invoked from the page template to generate the in memory or temporary output then this output can be rendered using and embedded headless browser component and saved as an image and linked. This way it will be generic and not limited to generating Twitter Card / Open Graph Images this the possibility to have other pipe lines in the future.
1 Like
Hmm that would be a bit tricky to implement in Zola, I would need to see many people wanting that before thinking of implementing it.
I have a similar desire; in many cases I am using whatever images are colocated to serve this function, but as I write more blog posts and pages I find the want for something to make my links a bit more personalised.
I would love for it to be a simple templating language, like Markdown but with a renderer that produces images, or perhaps to take some inspiration from crates.io’s use of typst templates.
I suspect with some clever use of the existing Zola metadata and taxonomies this could be made both simple to start out on and flexible to customise.
Alternately, as this isn’t something you’re personally interested in @keats, perhaps a simple plugin/hook system could be worthy of consideration? Then one could have, say, a before-page hook (perhaps just a script or executable that gets called out to) which gets the page metadata and output path, and can then do some work and inject its own information back into the page generation process.
Obviously there are people who’ve worked around this by using off-site generators, but this is undesirable if your goal is to have a wholly static, self-contained site and not potentially depend on third parties.
Just for completeness, here’s another request for similar functionality: Generate Preview Images , and see also Run commands
ticky, from your post I guess you are running zola by hand.
I would suggest you just use a simple b build script to run it, it will solve all the problems you have without any bloat added to Zola. You just add the hooks in the build script.
For instance, my zola-deploy script calls:
- various checks such as zola check
- git commit
- generate a shortcode with a commit tag
- zola build
- rsync to the server
Sure, though that also defeats a bit of the “one binary, no external dependencies” philosophy, of course at the point I’m asking for hooks I’m already thinking beyond that.
Ultimately the larger issue is that for this purpose I would want to depend on some of the internals of Zola, such as slugification and summaries, to power what I’m trying to achieve here, and put the data in the right places.
Having dug in further, I think I can work around this at build-time by using the load_data filter and running a web server alongside Zola for that purpose, sending it commands (and some of Zola’s computed state, as noted above) via that mechanism, but it ultimately feels like a hack because it is!
I wouldn’t consider a simple image construction pipeline “bloat” any more than I would consider having cropping and resizing functions in it. There’s no real argument against it; the modern web ecosystem de facto expects you to be able to produce these images, and I would rather template them and produce them at build time if possible.
An interesting discussion, for sure.
I would argue that all the scripts local to your installation are the opposite of external dependencies: they are internal, and it is your installation, your site, that depends on Zola.
Also, your favorite feature may not seem as bloat from your perspective, but when you must consider that integrating it into Zola must work on all platforms, for the most people and cxases possible, with documentation, and not degrade performance, things are not so simple.
Notably because a lot of performance in dealing with processing files is done via smart caching of data, that implies that Zola must know the semantics of the relationships (expressed in zola.toml, frontmatters, and tera2), and this is where the bloat creeps in.
And also that these functionalities provided by external tools evolve a lot, and will create work pressure on keats to maintain them relevant. And that Zola appeal is its opinionated minimalist approach.
Take git for instance. I would bet that most people use git “externally” to manage their Zola contents, but integrating git management in Zola would not be worth it.
I think ticky’s problem and your point about caching identify two sides of the same issue.
A build script works well when the external operation can remain independent of Zola. Git is a good example: Zola does not need to understand commits or branches, and Git does not need Zola’s resolved page model.
Ticky wants to use information that Zola computes, such as slugs and summaries, to produce something that belongs to the generated page. Moving that work into a build script does not remove the relationship; it makes the relationship opaque to Zola.
Making that relationship visible to Zola has a cost. Once Zola understands that some generated result depends on page data, it also needs semantics for that dependency: what the inputs and outputs are, when the result becomes stale, and what needs to be rebuilt. That adds complexity and maintenance surface even if the processing remains external.
So I think there are two separate choices here: whether the operation belongs inside or outside Zola, and whether Zola should understand the relationship between that operation and its own build model.
I don’t have an opinion on what Zola shoudl do here, but I think separating those two questions may help clarify the trade-off.
1 Like