related to the favicon/manifest question... pwa?

[wolfspyre]

Not sure if you've seen this:
https://hugomods.com/en/docs/pwa/

These kids have put together a pretty robust piece of kit that handles a client-side js worker/caching, and the associated metadata to tie it all together...
I don't know that it's a thing to adopt/integrate carte blanche... but it might have some worthwhile bits to integrate.... is this something that's been on the to-do list?
something that you're not excited about at all?

I'm not really for or against it so much as wanting to lay stuff out in a cohesive, well integrated fashion

[jpanther]

This is not really one that I'm interested in at this point. I don't see why this would add any value for the types of sites that are being developed with the theme - maybe I'm wrong? I'm also very much against including third party code into the base theme as much as possible. It introduces uncontrolled code, negatively impacts performance and just generally adds bloat.

The good thing about modules is that they are available for those who want them, and so I prefer to leave it to individuals to make their own choices about when they add value to a particular project.

[wolfspyre]

I'm against bolting in externally owned stuff as well.... it's best to own the decision of when to adopt change.

I wasn't suggesting slurping the module in, so much as implementing the webappmanifest / favicon / (and maybe the service worker stuff ) into the site in an elegant fashion.

I pointed out the module because you're already doing more than half the work that this module does in appearance.js

The needful remainder is adding some more metadata keys,
resizing some images, or consuming them from the user, and
creating the webmanifest json blob.
that would be the entire solution for 'supporting webappmanifest/favicons' ...

to be able to handle the pwa component isn't THAT much further a stretch; as it's essentially just including a homegrown js script that's capable of caching content on-device in case of no-network-access.

kinda out of scope, yes... but the two components use the same moving parts, and
Since you already have a sprocket that's in play to manipulate the meta tags; it felt klunky to me to come in after the fact and attempt to change it.

make sense?

[wolfspyre]

I've raised this question on the hugo discourse forums to try and get some insight into how best to generate a webmanifest resource which the hugo docs assert there's a default output type for; but there's no docs on implementation, nor exemplars ((that I could find)) in the hugo repo...

My guess is that there'd be a page bundle that has the needful articulated in the index frontmatter, and the images to resize associated with the pagebundle, and its' output is /webmanifest.json or something...

if that's the case, then I think the head.html partial would need to be able to notice this is setup, and add some extra metadata bits into the site header, as well as reference the proper manifest asset.... but ¯\_(ツ)_/¯

hopefully will have some more useful info soon.

[wolfspyre]

well, gj52 pointed me to his webmanifest generator template, which looks pretty simple to retool to be aligned with wot you're doing already. would this be a valuable improvement in your mind?

[jpanther]

I'm grouping this thread into a single issue to track this feature in one place - see #720.