Office Hours 3 - Website Rebuild Ideas & Explorations

[gerbrent]

Hey all! Help us brainstorm ideas of how to build the coming new Jupiter Broadcasting website. We'd love your input!

GitHub actions? Hugo? mkdocs?

[ironicbadger]

https://github.com/selfhostedshow/show-notes

Here's how we use mkdocs to generate our notes website.

[StefanS-O]

Hi there,

i heard you are looking for input for a possible relaunch of Jupiter Broadcasting and wanted to give my two cents. Congratulations for wanting to move away from Wordpress!

What i have used:

• Hugo
• Hugo with NetlfiyCMS
• NextJS Static Site builds
• NextJS & NextJS Server Side
• GravCMS

What i recommend: Use a headless CMS

I have used Cockpit CMS a lot and really like it so far. It provides a simple Webinterface for managing content and creating fields and provides a great REST or GraphQL API to query, modifying and adding content.

It is also super easy to write custom API endpoints. It is written in PHP which means it does run everywhere and supports a lot of different database engines and is OpenSource.

This eleminates a lot of the painpoints when working with purely static site builders:

• Search
• Form handling
• Webinterface for managing content
• Sending emails
• User Management

Sure, there is client side search like Lunr, but that doesn't perform well on large sites and also the index has to be downloaded by the browser. Or you could use ElasticSearch, but then you need to host and maintain ElasticSearch, which is a bit much. So there are ways to overcome shortages of static site builders, but they are workarounds. If you pile a lot of workarounds together you end up with a huge mess and that's what you want to get away from :D

What you use as the frontend is up to you. For example it would be possible to build markdown files and generate the frontend using Hugo. Or you could use NextJS and query the API directly to build a static site.

You could also integrate a trigger to a Github Action that does the build process of the static site, when content get's changed or added.

The main benefit is that you totally disconnect the backend from the frontend, which is a huge benefit.

I hope that helps a bit.

Much love

Stefan

[reesericci]

Strapi is another good CMS.

[TeamLinux01]

I don't know how System76 does it for their pages that allow GitHub editing, but I think it would be a good idea if the community could make contributions via that kind of editing.

[TeamLinux01]

Also, would it be a good idea to run the Git project on a Self-hosted Gitlab instead of GitHub or is it better to reduce the barrier to editing via GitHub?

If Gitlab would be use, how would users sign up to do edits?

[6543]

Oh and dont forget what we work on: go-gitea/gitea#18240

[StefanS-O]

Always wanted to try out Gitea, thanks for reminding me! Also thanks for all the hard work you do!

[ironicbadger]

Gitea is so great!

[6543]

oh by the way: ref Drone.io Love/Hate - I just like to mention https://woodpecker-ci.org/ - just in case ;)

(A drone v0.8 fork - that has changed (updated/refactored drone) a bit ;) ; tldr: it's independent)

[JR-git-hub]

JB might qualify for the GitLab for Open Source program and could self manage or useGitLab ultimate with 50k CI/CD minutes free. If it does not qualify by default, JB might qualify by exception as noted on the join page:

https://about.gitlab.com/solutions/open-source

I think anyone looking to contribute to JB will happily create an account anywhere needed. We all recognize the chicken vs egg thing - just see how many of us got on matrix for the first time, are getting SATS for the 1st time, etc.

[cjthedj97]

Looks like Jekyll (ruby instead of go like hugo) has not been mentioned at all but that also provides static site generation.

Also if self-hosting isn't required and the SAAS version of GitLab or GitHub are used I would urge you to check out Cloudflare pages rather than GitHub pages as it is a bit more flexible.

[StefanS-O]

I find Jekyll very slow for generating large sites compared to Hugo

[JR-git-hub]

For anyone else looking for a recent video on Jekyll, TechnoTim recently released one that I thought was worth sharing:

https://youtu.be/F8iOU1ci19Q

His docs page made with Jekyll:
https://docs.technotim.live/

[sebdanielsson]

Looks like Jekyll (ruby instead of go like hugo) has not been mentioned at all but that also provides static site generation.

Also if self-hosting isn't required and the SAAS version of GitLab or GitHub are used I would urge you to check out Cloudflare pages rather than GitHub pages as it is a bit more flexible.

+1 for Cloudflare pages. I recently switched to it from Vercel and whild build times are a little bit slower the page loading performance is great.

[10leej]

Hugo can make and manage a podcast feed. Great for the old shows maybe.

https://brendamour.net/2021/04/18/how-to-publish-podcasts-with-the-hugo-static-site-generator/

[elreydetoda]

That's pretty cool! I didn't even think to try and do that with Hugo!

Ya, I'd definitely say that Hugo, IMO would be the simplest while still being powerful, versatile, and robust enough to handle something like this and host the JB website on. The other nice thing about Hugo is it's multitude of templates/themes, there is the official one here and other unofficial ones as well (i.e. here). I will say though, IMO if you want to build it right (as I've found out) is you can use the themes for inspiration/ideas but at least for styling it's probably better to just do it all yourself. I constantly fought the styling for themes to do what I want it to compared to just doing all the CSS/SCSS myself (since I took the time to learn it in more depth since I started to get more serious with learning about web dev). I'm happy to see that @StefanS-O had mentioned using Hugo + NetlifyCMS 😁

I actually am finishing up a job right now for a client, and I'm using Hugo, GH pages, SmugMug (for hosting images), NetlifyCMS (for a UI to author content) + Netlify (authentication for CMS), and Algolia (for search). IMO it's pretty nice that the client is pretty much on the free tier or free for most things.

The website I co-built built is here: https://www.climaterefugeestories.com/
The repo we used is here: https://github.com/Climate-Refugee-Stories/crs-website

You should be able to at least preview the admin UI (after you login) here: https://quiet-cannoli-ed0267.netlify.app/admin/#/
you won't be able to push any content of course (since you don't have rights to on GH), but it'll give you a sense of what it could look like. The nice thing about the NetlifyCMS (headless CMS (you don't have to host it) that lives next to your repo code) is that it's pretty easily extendable. I'm by no means very good at JS, but I was able to build and register custom components with relative ease (defined here). Below is a preview from the CMS:

While it doesn't look the best in the CMS, you get a build preview built with the Netlify account you create (for authenticating to GH (which can be done outside of Netlify as well, but is overkill for a simple use case)). So, you can see what the actual site looks like with your changes: Climate-Refugee-Stories/crs-website#79 (comment)

Netlify is only needed for the authentication gateway and hosting the admin UI, but the actual website can be hosted on Github pages and authorization is handled with Github permissions (even though authentication is through Netlify).

NetlifyCMS is also looking to build in (currently beta, and wasn't necessary for the site I was building) "Open Authoring", so essentially it'll for the repo for you and let contributors submit PRs upstream to your repo: https://www.netlifycms.org/docs/open-authoring

netlifycms.org actually has this enabled, so you can check it out just by editing one of their pages: https://www.netlifycms.org/admin/#/edit/docs_Workflow/open-authoring

The other thing about this CMS is that on the backend it's just using GH PRs, so you could run automation tasks (in the process of setting up now) through GH actions on a per PR basis. That'll let you push updates to Algolia for indexing your search or anything else that needs updating with each new post that gets created & merged.

Also, for comments on each episode you could do something like this: https://decovar.dev/blog/2019/04/19/github-comments-hugo/
and use GH issues as comments as well. Alternatively if you want to allow anonymous comments you could use something like https://commento.io/ not free, but pretty cheap from my experience.

Overall, was it a labor of love putting everything together yes, but overall I'm pretty pleased with how extensible Hugo is, but still very simplistic.

[reesericci]

Can confirm that Netlify CMS is excellent.

[joncartee]

I'll throw gatsby into the mix.
There are a lot of starter libraries to see the options. It's a framework around react and js handling react-router stuff giving you a template for your react site. All the starters I have looked at start with a responsive web design.

https://www.gatsbyjs.com/starters/

When I make Gatsby sites, I personally use GitHub to host the code and use Netilify to build and deploy the site. Netilify will automatically rebuild and deploy your site when the associated repo is updated, so I typically deploy main as the production site and a dev branch as dev.domain.com. So when you push your post to dev, you can then let Netilify build it and then go to your secret testing page and do some quality control to make sure it looks right and then merge to main when you are happy with it.

Posts are handled through markdown documents and applied to js pages built in react, so building your blog page can be dev heavy if you want to make a lot of changes to how your site/pages look but once it's tweaked to your liking every blog post follows the same design format. So adding content is as simple as creating a markdown document with some metadata at the top, and adding that to your posts or blog folder in the directory. This looks similar to the notes docs with the exception that the metadata would be sitting at the top of the markdown document.

Some starters have tied in cms platforms, I have never used them to speak to how well they work or don't, but they are an option. I like to just work in the repo directly.

With react if you can think of something to do you can probably implement it via react or just straight javascript.

Let's encrypt ties into Netilify and don't really need to be touched if you don't want to. When I want to add something that is very different from the site where it doesn't follow the design subdomains can be used pretty easily in Netilfy.

Most starters include graph ql for querying the site.

Things I like about Gatsby, once your site is running and you play with modding your pages you can make it to the point where you understand what's being imported to each page where it's being used and the properties that you can change. It's that feeling like I know what's going on and through understanding it you can make changes and extend it the way you like, I get the same feeling on Fedora on my x1.

Things I don't like, are it could have better error messages when a build fails, also dealing with npm dependencies. I prefer the gatsby deploys with fewer features/fewer npm dependencies for that reason.

https://www.gatsbyjs.com/docs/how-to/adding-common-features/adding-an-rss-feed/

Building a podcast feed.
https://www.youtube.com/watch?v=0hGlvyuQiKQ&ab_channel=LearnWithJason

[reesericci]

I have to disagree about Gatsby due to its dependence on React. React has a steeper learning curve as compared to Svelte or just plain HTML/CSS/JS. I'd rather see something more framework-agnostic instead, like Eleventy, which can also be deployed to Netlify. I'd also be happy with SvelteKit, that contradicts previous points though, but I believe that unlike React, Svelte is much easier to read and get up-to-speed because it uses regular tags like <script> and <style> while still isolating components.

--reese

[elreydetoda]

Ya, while I've heard that Gatsby is really powerful and versatile (IIRC you can use Google Docs as a datasource 😅). If you're not comfortable with JS it'd be a steep learning curve for general system maintenance or enhancements (IMO).

[cbeauhilton]

Re GitHub, the easiest fairly future-proof option is to have an independent git install on whatever server you like, and set up someone's config so that pushes go to both GitHub and that server. One of the maintainers could occasionally pull and push locally to keep them in sync, or you could set up a GitHub Action to do that. If GitHub goes away or does something stupid, you'll still have the source files and their history, mirrored on N+1 contributor's machines, and you can then pivot any way you like. You'd lose the discussions and issues, but they're second-tier imo. No need to futz w GitLab.

[elreydetoda]

You could use gitlab as another mirror point as well though. That way they'd have 3 copies of the repo (at minimum).

Also, ya I've heard a lot of people use Gitea for doing something like this mirroring GH repos. Looks like this section in their docs talked about it: https://docs.gitea.io/en-us/repo-mirror/#pulling-from-a-remote-repository

Gitea, IIRC is a lightweight Go based Git server and a lot of people self host like using it.

[cbeauhilton]

For sure, the more mirrors the better! I'm old and grumpy at heart, so I like plain ol git, but I've heard good things about gitea, and nothing in particular is wrong w GitLab.

[cbeauhilton]

A strange and glorious idea:

I've been following Simon Willison's work for a while now, he's one of the original Django creators, absolutely brilliant dude. He accidentally created a CMS based on flat files ingested into SQLite databases, and it's fantastic. He put up a video very recently (https://www.youtube.com/watch?v=B55hcKYye_c) that goes over the basic premise of his Datasette project (SQLite explorer with SQL-injection-as-a-feature and baked-in json/csv/graphql APIs) then teases how the Datasette website itself is built on Datasette, noting that scaling is very easy bc you just spin up more instances (copy the entire db and the logic around surfacing it to a new node).

I love how portable the whole thing is, how using markdown and json for articles and structured data is eminently collaborative and versionable, that you can administer entirely with GitHub Actions if you'd like or spin to bare metal/VPS/etc., how flexible it is (SQLite has support for json fields, so you can make yourself a NoSQL-within-SQL platform if you are so inclined), and how speedy the SQLite backend is, for page rendering and search, natively on a single machine and with the ability to scale horizontally with ease.

Not saying any sane person should build his or her whole life on SQLite, but...

[elreydetoda]

Ya, while I know that most of the people at JB are...let's say adventurous...😅
I'd say that's a very novel concept, but asking for a world of hurt to run a simpler website off of IMO.

I really liked the video he posted though, it looks like a really great tool for dataviz. I might try and check it out for some of the tools I use, and try to explore the information from those tools using an sqlitedb

[cbeauhilton]

Absofrigginlutely, agree w both points. I do think it's ripe for someone to build a CMS/SSG hybrid that pulls it all together, but it ain't me, this year at least.

I use Datasette all the time for dataviz and exploring, love the mapping plugins in particular. The built-in API makes it also great for throwing something up on a free host (e.g. Vercel) if you would like to have data easily accessible in the cloud (I have some WorldBank data that is only available buried in some Excel sheets on their website, pulled out the stuff I want and threw it up on a Datasette instance so I can pull it down for data science workflows).

[reesericci]

What about Ghost? Its a fully-featured CMS like Wordpress but actually nice to use. I don't know how well it would fit the usecase though, just spitballing.

[reesericci]

Fair enough, flat files are great, but maybe take a look at Strapi as it's a headless CMS that has an amazing GraphQL API.

[cbeauhilton]

This Rust-based ssg, Zola, is interesting, may fit your use case - no dependencies, fast generation, support for custom TOML/YAML front matter

[elreydetoda]

This Rust-based ssg, Zola, is interesting, may fit your use case - no dependencies, fast generation, support for custom TOML/YAML front matter

Oh no...now we know which one they'll go with... 😞

@ChrisLAS can't resist anything that's rust based 😂😁 (JK)

[elreydetoda]

I’ve used ghost for a number of years myself from linuxserver.io to my personal blogs. It’s a fine blogging platform sure.

We’re looking for a flat file based publishing method. This means no DB and most likely no CMS (unless you can demonstrate it has a scriptable API).

I’m imagining front matter loaded with a dozen or more fields that our automation would read from. The harder I look the more I’m certain such a thing doesn’t exist yet so it’s probably going to be up to us to build it.

Not that I'm advocating for it (because I don't think it'd be a good idea personally when there are better options IMO), but technically Ghost has a scriptable API and can act like a headless CMS 🙃😁

(Again not recommending this 😅)

[reesericci]

I've tried to use Ghost as a headless CMS, and it is awful in that state.

[reesericci]

I'll throw SvelteKit in here with mdsvex. Svelte is great because it has a really low learning curve compared to React. Svelte can be used for the layout and styling, while with mdsvex, Markdown files can be used for the actual content. It will take more work though to set up and maintain compared to Ghost, but it has a lot of flexibility to create whatever layout makes sense.

[d4n3sh]

I like and currently use Hugo. I used to be on WP for so long, useful tool but always felt it was overkill for a personal blog.

Markdown --> GitHub --> GitHub Action --> Artifacts (html files) --> GitHub pages --> Cloudflare DNS + CDN + SSL

[awfulwoman]

S’up. I’m an ex-Frontend Developer (and now Platform Engineer). I’d solidly SOLIDLY recommend keeping all content in markdown and using Eleventy to generate your site. Markdown is, I feel, a no brainier as it allowed you to accept pull requests for community contributions, and keeps things simple. No databases, no corruption, yeah?

Eleventy I recommend because it’s fast, documented, and has a community surrounding it. People do some fantastically complex stuff with it. Most importantly, unlike some other so-called “SSGs” it only outputs HTML. No React, no client side stuff. Just blazing fast sites.

Check it out and I think you might find it useful!

https://www.11ty.dev/

[elreydetoda]

So, if I'm understanding this thread properly Eleventy is all JS based, correct? So if the https://github.com/JupiterBroadcasting team was to maintain it themselves (without community), then they'd have to know and understand JS to do so?

That is true; but in its defence, one would have to understand Hugo's Go-based templating language in order to maintain Hugo without help.

To set up Eleventy, it is best to know some javascript, as well as have some understanding of web development (how to build templates; how to write html and css; what to look for when setting up static assets properly). The depth of javascript knowledge depends on the complexity of the web site. There are lots of starter projects that one could possibly even clone and start tweaking without having to fully know what they are doing. It's probably inevitable that one would have to install Node though smile

Ya, that's definitely true about the Go-based templating, I just thought that Hugo's Go-based templating was more simplistic than trying to begin learning JS (IMO). Especially if they've worked with Jinja2 templates it feels really familiar (at least to me). The other thing is that Hugo's got a limited set of ways you can do things compared to JS, and while that can feel like a curse (if you want to do something really extensive) it's nice (IMO) to not have to question if you're doing something right. Since it's not a full programming language, but has just enough feature to get 99% of the work done w/o too much difficulty.

The other nice thing about hugo vs a JS option (IMO) is that you wouldn't have to install node and maintain that + dependencies. Instead you just install a static go binary, per your OS, but everything is built-in to that binary (I'd opt for the -extended version of hugo, because it has native SCSS compilation).

I've definitely heard great things about Eleventy, and seeing such high recommendations/praise for it here has me thinking about trying to use it for my personal blog or something. I've been trying to get into more frontend stuff on the side, so learning more extensive JS for me wouldn't be a problem 😅

[reesericci]

I think that using something that's based on JS is a good idea because it's the language of the web. You're not restricted to templating, you can write whatever the browser supports. You're also not tied down to Hugo because you learned something tool-agnostic that's supported in all browsers.

[elreydetoda]

I think that using something that's based on JS is a good idea because it's the language of the web. You're not restricted to templating, you can write whatever the browser supports. You're also not tied down to Hugo because you learned something tool-agnostic that's supported in all browsers.

So, (IMO) I think learning JS is great...if you want to be a frontend developer or any other type of web developer. I think it is quintessential in those cases.

But if you're just a bunch of podcasts/linux sysadmins, and web dev hasn't/isn't you main occupation it's too much of a learning curve.

(No idea if this is the case or not for JB, so don't quote for me for the circumstance) If all you've learned to program is through bash (and possibly python) script, then learning a whole programming language just for you website is way overkill (IMO).

[reesericci]

But wouldn't you have to learn Hugo's templating?

[elreydetoda]

But wouldn't you have to learn Hugo's templating?

I already acknowledged there here

I just thought that Hugo's Go-based templating was more simplistic than trying to begin learning JS (IMO).

[reesericci]

Here's an idea: how about generating the pages from the RSS feed? That way you don't have to manually update the website, just the feed.

[reesericci]

Maybe use Fireside to update the site?

[mxuribe]

How about considering Lektor for the CMS? See https://www.getlektor.com

It is a static site generator-style of CMS...so the output remains nice and fast for visitors to the website...But, managing the content is done through a simplified WYSIWYG; not unlike Wordpress, but simpler. Obviously, you can read details for yourselves...but the gist:

• Produces static html pages but allows for GUI/WYSIWYG editing.
• Is based on python and employs Jinja for templating...you don't happen to ahem know a developer who uses/knows python do you? ;-)
• Has plenty of flexibility in case you eventually want to migrate to a different platform in the future.
• Is open source software - of course!
• Is made by the team that builds/has built some pretty essential python modules, so high quality stuff
• Deployment/Publishing can be handled via built-in functions, or actions, or good ol' fashion bash scripting, or any number of approaches that sys admins/devops can enjoy...yes, i said enjoy. ;-)
• The content - much like other SSGs - merely lives as text files in a set/hierarchy of directories.
• ...Making backups easy peesy.

[nmcdaines]

[nmcdaines]

As a bonus comment, there is a really cool form project for react called Formik by Jarred Palmer (who has recently teamed up with Vercel with Turbo Repo).

The docs site they have is pretty cool; they used to have an integration with notion however it appears they are now using markdown files in the git repo. - might be some good inspiration

https://github.com/jaredpalmer/formik/tree/master/website

[reesericci]

It's not that React is boring, it's that it's a pain to use, especially if you're new to frontend development. https://component-party.dev

[azangru]

There are several points made in this comment, which, while starting with totally valid premises, reach somewhat unexpected conclusions.

1. Web page speed is important. This is absolutely true; but one would expect the conclusion from that to be "therefore, prefer plain html/css with as little javascript as possible", i.e. not React, unless you strip it out, as do Astro or Remix.
2. Boring reliable technologies are good. Absolutely true; but one would expect the continuation of that argument to be "therefore, prefer plain html/css that has been around for three decades, rather than a framework (Next) upon another framework (React) that are innovating at a breakneck pace".
3. Long-term support and longevity are good. Perfect point; but the logical conclusion of that would be "therefore, prefer web standards, which are guaranteed to be supported in the decades to come, over a frontend framework that comes with its own fork of html".

There are also other considerations to take into account, such as the maintenance of the site. Someone in a comment above was worried that the maintainers of the new site may not know javascript. Well, with React you need to know both bog-standard javascript, and the idioms of React.

Now, some examples:

• The Smashing Magazine, built with Hugo, is plenty fast
• CSS tricks, built with Wordpress, is quite fast; as is the site of the Shoptalkshow podcast by one of the founders of CSS tricks
• The site of Biden's White House, all politics aside, is an incredibly well-made Wordpress site
• Alex Russell's blog, probably built with Eleventy, is insanely fast; as is Zach Leatherman's site, which is definitely Eleventy, probably hosted on Netlify
• The site of No Agenda Show that Chris likes to mention — built with Symfony and enhanced with web components

[nmcdaines]

It's not that React is boring, it's that it's a pain to use, especially if you're new to frontend development. https://component-party.dev

I appreciate there is a lot of sentiment around React having a steep learning curve, and that other frameworks are simpler to dive in, not to mention other considerations like bundlers (in particular webpack) - although this later concern is definitely obfuscated by modern boilerplates and tooling.

I've personally only dabbled a bit in vue, and haven't touched Svelt so don't want to make assumptions; however I've been very interested in reading about these frameworks and how they differ from React.

For small projects; I definitely could see value in lighter frameworks as mentioned as you don't need as much javascript knowledge however I think as a project scales the way a react project is structured and also the way React manages state whilst maybe at times being cumbersome and rather repetitive it has a significantly better flow.

[reesericci]

I haven't personally given it a shot, but Elder.js seems pretty cool: https://github.com/Elderjs/elderjs/

[ironicbadger]

So many great suggestions in this thread but it's very hard to fully understand the technical merits of any single solution from recommendations alone. Therefore, I'd like to suggest we build a few of these frameworks into MVPs. An MVP in this case is a home page with a few episodes, a single episode page and a basic explanation of how the CI behind it would work.

Nothing has to be fully fleshed out or designed or whatever. But some straightforward examples of how you take a page like this of pure markdown and turn it into what we need.

The show notes website already scrapes fireside using python and beautifulsoup so feel free to reuse that code as needed. Ideally, though, the new JB site would become our source of truth - NOT fireside as is currently the case.

Feel free to add frontmatter to the MD file to enable host profile linking and what not - remember that is a key feature. If a host or guest shows up on multiple shows we should only have to edit one file to update all the episodes they appeared in. Apply that logic to any other "relational" type data structure that you come across too.

Good luck!

[elreydetoda]

Sounds like it's going to be fun 😁

A few of clarifying questions:

1. Should the MVP be showing how to generate a Podcasting 2.0 compatible feed, or just showcasing functionality + a bit of design layout (basic things to not have everything left aligned and uninterruptable 😅)
2. You mentioned about the new JB site will be the new source of truth. Yesterday @noblepayne 's recording that @ChrisLAS played for Office Hours talked about the first iteration of this will have fireside as the source of truth. So, just trying to make sure I'm understanding properly this MVP is going to be an MVP for the "final state" of the JB website, and not the interrem state (i.e. this upcoming summer) of the JB website, correct?
3. Yesterday they also chatted about having more modern publishing flows with some restrictions, so someone not having to author a post to publish an episode, and since fireside won't be the source of truth (in this MVP), is there a preferred way of handling assets + info per show? (i.e. a script of JB's backed initiates "publishing" the episode and assets are uploaded to Linode's s3 compatible object storage, but not having the episode publish before a specific time). Are we taking all of that into account as well (to help architect/understand the workflow for the MVP) or just focusing on people manually publishing the content for this MVP to understand what it could look like? (without automation)
4. Since the JB website will be a source of truth, will it also need to have an API of current source/info? (i.e. All authors, all shows, etc...)

[reesericci]

I started on one using SvelteKit and mdsvex. Currently all it has is an episode page but I thought I would share it

https://github.com/reesericci/jb-sveltekit-mvp

[RealOrangeOne]

Speaking as someone who professionally builds custom CMSs, I'd recommend using something that already exists. So much of what's needed already exists in the world, it'd be a shame to rebuild it.

Also, speaking as the person who wrote the notes site, I'd recommend against anything which is static. The ability to have something fully data driven is incredibly powerful, and also means non-technical users can make changes as needed, and pull in live data from other places. The downside however is that the community can't PR in to update the content, which I think could be quite a nice feature (and something which was spoken about).

As static site generators go, Hugo and Zola are definitely the 2 best out there (the latter being Rust 🥳 ).

For a more custom CMS, building off of something existing like Wordpress or Drupal means we don't need to build from scratch, and there' plenty of community around the frameworks to build some custom integrations if we need it. Alternatively, if we do want something pretty custom, Wagtail is a really good framework for building these things, and used by tonnes of people (Disclaimer: I work for the company behind Wagtail).

From experience, step 1 is definitely getting some form of feature spec together. From there, we can match it against the best technology to solve the problems and go from there!

[StefanS-O]

@ironicbadger

Repo: https://github.com/StefanS-O/jupiterbroadcasting-hugo-mvp
Demo: https://jb.codefighters.net/

A lot is still missing, but i only spend 6 hours.
I think the next day i add a bit more content / shows and look at the feed generation. I prepared it but am to tired now.
Also it includes the whole Github Action workflow to build and deploy. Currently it is using SSH and RSYNC but options are endless.
So everytime i push to main the site gets automatically build and deployed :)

I think i will add some issues for planning and of course design is far from finished.

[StefanS-O]

I got multipage site builds kind of working \ o /

That means you can also build subsites with their own domain, menu structure and everything but still use content from the main content.

Its here: https://github.com/StefanS-O/jupiterbroadcasting-hugo-mvp/tree/feature/multisite

I didn't know about Hugo Module Mounts, it's quite a powerful feature:

[module]
#[[module.mounts]]
#  source = 'sites/coderradio/content'
#  target = 'content'
# currently it prevents us from mounting sites/coderradio/content directly
# https://github.com/gohugoio/hugo/issues/7123
[[module.mounts]]
  source = 'sites/coderradio/content/community'
  target = 'content/community'
[[module.mounts]]
  source = 'content/show/coderradio'
  target = 'content/episodes'

You can see the whole config for coderradio here: https://github.com/StefanS-O/jupiterbroadcasting-hugo-mvp/blob/feature/multisite/config.coderradio.toml

[elreydetoda]

I got multipage site builds kind of working \ o /

That means you can also build subsites with their own domain, menu structure and everything but still use content from the main content.

Its here: https://github.com/StefanS-O/jupiterbroadcasting-hugo-mvp/tree/feature/multisite

I didn't know about Hugo Module Mounts, it's quite a powerful feature:

[module]
#[[module.mounts]]
#  source = 'sites/coderradio/content'
#  target = 'content'
# currently it prevents us from mounting sites/coderradio/content directly
# https://github.com/gohugoio/hugo/issues/7123
[[module.mounts]]
  source = 'sites/coderradio/content/community'
  target = 'content/community'
[[module.mounts]]
  source = 'content/show/coderradio'
  target = 'content/episodes'

You can see the whole config for coderradio here: https://github.com/StefanS-O/jupiterbroadcasting-hugo-mvp/blob/feature/multisite/config.coderradio.toml

That's really awesome! I didn't realize Hugo could do that either! 🥳🎉

[StefanS-O]

Update:

Multiside builds now working, so for reference:

• Main Site: https://jb.codefighters.net/
• Coder Radio Subsite: https://jb-cr.codefighters.net/

Cool about that:

1. Content: they share the same content for episodes, guests and hosts
2. Template: template inheritance is working, so there is the jb base theme, which get's only partly overwritten by the sub theme. You can use the same sub theme for multiple sub pages, or create your own per show.
3. Github Action: i modified the Github Action so it builds and deploys two sites now
4. Configuration: each site has it's own configuration where most of the stuff happens (like menu configuration, meta keywords, show title, URL, etc). So if you don't have specific content for a subpage you just create a config file and add another step to the Github Action and BAM you are done

Hosts / Guests Overview

There is now an overview page of all hosts in Jupiter Broadcasting: https://jb.codefighters.net/hosts/ i plan to do the same for guests. On subsides this will only display the hosts of the show and the guests in the show. On Jupiter Broadcasting all hosts and all guests are displayed.

[StefanS-O]

Update:

Making process on the audio player (including chapter support, multiple audio files versions and multiple download options)

[StefanS-O]

Update:

i am still at it :D

Currently working on the content scraper that get's all information from jupiterhub.com and the Fireside sites and collect them in a headless CMS. Once that is done we have a REST API with all content merged. It's taking good shape but it will probably take until next sunday.

I think no matter which solution get's chosen having the content available via a unified rest interface is pretty good to have.

[oneproxima]

It seems like your have a solution before you determined what requirements you want to hit/problem you want to solve. Note I've never create more than a basic website. Some requirements could be easy management (determine how this would look like for each avenue or tech stack), speed, user contributions or issue tracker, mobile view, content format (think flat files vs database for file storage but for content), application/stack management, other potential features, etc.

[elreydetoda]

Hey @oneproxima, most of the requirements are defined in the podcast episodes. Most of the https://www.officehours.hair/ episodes (especially recently and future) will cover requirements/wants.

IIRC, there was one or two other shows, but I can't remember which ones 😅. @ChrisLAS has been talking about it recently in most shows. So if you checkout the all shows feed you should be able to find them.

You might also be able to search https://notes.jupiterbroadcasting.com/ for "website" and look at recent episodes only to find them as well.

[reesericci]

Stripe just came out with Markdoc and I thought it might fit the usecase

[reesericci]

What about using something like Castopod? It's a podcast host that supports Podcasting 2.0 and can be self-hosted or has paid offerings. I think it bundles a homepage for multiple podcasts as well but not sure.

[thebiblelover7]

Castopod looks really promising and beautiful!

[reesericci]

In fact I've started using it recently and it works like a charm

[devotoare]

Payload just went open source. I haven't used it but the excitement and sentiment seem good. https://payloadcms.com/blog/open-source

For things I have used Nuxt with the Nuxt Content module is great for static sites. Content can be written in MD or JSON (or more) and then gets templated out.

I'd also love to just help with the work in general and know JS, Vue, go, rust, WordPress, and a few others pretty well so if I can be of some help please tag me.

[StefanS-O]

Interesting, have never heard of Payload before. I have used Strapi before, but found the freemium model to annoying.

[reesericci]

Wow payload looks super nice. I'll probably try it on one of my own websites.