Anyone have any recommendations for Blog software?

I was considering for a while just using a mastodon instance as my blog because I just kinda wanna sign in and upload my papers that I’ve written. I was pretty close with Hugo. I’d rather not have to build the site everytime I upload and I want to self host and not use Github actions. I think I still could do it since I like using Cloudflared tunnels.

What is all out there?

  • Omega@discuss.online
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 hours ago

    Can you not make a shell script that auto builds and deploys? It was really simple for me

  • thymos@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    1
    ·
    7 hours ago

    I just wrote a few lines of PHP and put my posts in a SQLITE database. Simple, built to last and no dependance on others.

  • fubarx@lemmy.world
    link
    fedilink
    English
    arrow-up
    9
    ·
    1 day ago

    I’ve had good luck with Jekyll, saving the source on github, and setting it up so pushing to main auto-deploys to a Cloudflare site. Using Markdown and for larger media, uploading to S3.

    Much easier to set up and maintain than github pages. Since it’s static output, pretty snappy. Also includes RSS feeds and permanent URLs.

    Have also set up several Wordpress sites. Slower, but if you want wysiwyg editing, user comments, or there are several contributors, would work better.

    Have also heard good things about ghost, but haven’t actually deployed one yet.

  • just_another_person@lemmy.world
    link
    fedilink
    English
    arrow-up
    13
    ·
    2 days ago

    Ghost, Hugo, Jekyll…etc. all the same ones you’ll probably find by searching around.

    Ghost is probably the most fleshed out if you’re looking for guardrails and a UI.

  • Esjott@feddit.org
    link
    fedilink
    English
    arrow-up
    5
    ·
    1 day ago

    Writefreely can be selfhosted. simple config, no themes (or limited if i remember correctly). But it just works.

  • manxu@piefed.social
    link
    fedilink
    English
    arrow-up
    5
    ·
    2 days ago

    I ended up with Hugo, a git repository, and a cron job for the build. I write an article, check it in, the server picks up the git change and rebuilds the site. What I like about the setup is that the server only has the binaries hugo and git, and a shell script for the rebuild. Also, I write in Markdown, add media to the git repository, and articles are published soon after I check in without any remoting on my part.

    I did look at WriteFreely after the setup, though. I find the minimalist design very beautiful. Didn’t switch to it, but may look at it again for another project. https://github.com/writefreely/writefreely

      • manxu@piefed.social
        link
        fedilink
        English
        arrow-up
        2
        ·
        12 hours ago

        Hugo watch mode (both server and build) does not produce accurate sites on change and is really meant for development. I find after a developing for a while, I have to kill the process and restart it and then things are “fresh”

        From reading the documentation, I strongly have the impression that hugo focuses on being fast on re-render and that the idea is to build and deploy to public site each time there is a change. The big difference is probably whether to render locally and push the generated content, or to push the source markdown and render remotely (which I chose).

        • Ah, Ok.

          I do as (or a similar workflow): I rsync the content directory and let Hugo on the server render. My sites are public, but perhaps they’re just much smaller or not as popular; Hugo renders even my largest site in about a second, but for a large, slow, heavy-use production situation I could see a push-and-swap process for a more atomic site update.

          I don’t see the degradation you do, but there are so many possible variables.

          My biggest gripe about Hugo is how limited it is in supporting source document formats. There’s no mechanism for hooking in different formats, and the team is reluctant to merge PRs for other formats. When I started with Hugo, I had a large repository of essays spanning a decade and written in a variety of markup, from asciidoc (which I used for years), to reST, to markdown; and markdown is by far the worst. I was faced with converting everything to markdown, which was usually a lossy process because markdown is so limited, or not publishing all of that history. And now we have djot, which is almost the perfect plain text markup language, but I again have to first do a lossy conversion to markdown to get Hugo to consume it. It low-key sucks, and I’m actively looking for an alternative that has a more flexible AST-based model for which new formats can be added; something that consumes a format like pandoc’s AST.

          • manxu@piefed.social
            link
            fedilink
            English
            arrow-up
            1
            ·
            4 hours ago

            Did you look at Pelican? I share the frustration with much of Hugo’s infrastructure: the template language is buggy and inscrutable, and the plugin architecture wanting.

            I ended up with Hugo, but I considered Pelican. It uses standard Jinja templates, which I find much more rational (but it might just be me) and I recall there were plugins for a lot of things, including different source formats. The code is written in Python, so that even if there isn’t a plugin for a format you need, there probably is a Python library for it and it should be relatively easy to make it a plugin.

            Crap, now I want to switch to Pelican…

            • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍@midwest.social
              link
              fedilink
              English
              arrow-up
              2
              ·
              edit-2
              3 hours ago

              Did you look at Pelican?

              I have not, but I will. I may also look at Zola, although it, too, appears at the surface level to be tightly coupled with markdown.

              the template language is buggy and inscrutable

              It’s just Go templates, which are pretty solid; I’d be surprised by any bugs, unless they’re in the Hugo short codes. The syntax is challenging, even if you’re a Go developer and use it all the time. It’s a bespoke DSL, and a pretty awful one: it’s verbose, obtuse, and makes some common things hard.

              Go is my language of choice, but my faith gets shaky whenever I have to use templates.

              I’m not a huge fan of Python; despite its popularity, it’s got a lot of problems, not least of which is the whole Python 2/3 fiasco; which, years later, is still plaguing us. However, if I can containerized it so it isn’t constantly breaking in the background when I do a system update, I’m not opposed to using a project written in it. At least it isn’t Node; I won’t let that crap onto any server I admin.

              Edit: Zola has the same problem as Hugo.

  • markstos@lemmy.world
    link
    fedilink
    English
    arrow-up
    7
    ·
    2 days ago

    Simple means different things to different people.

    I self-host Ghost and find it pleasant to use and low maintenance. It is a single Docker container plus MySQL. I recommend a reverse proxy in front of it like Nginx. There are importers from many other blog formats.

  • Moonrise2473@feddit.it
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    2 days ago

    If you want to try again with Hugo, you can self host forgejo and let it build Hugo on your server when you commit, then serve that HTML

  • hertg@infosec.pub
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    1 day ago

    Haven’t seen it mentioned yet, but zola is great. It’s a static site generator in a single binary, and it includes RSS feed generation. Been using it for my blog for a while.

    getzola.org

    • Ah. I was wondering where the “Hugo, but Rust” was.

      I love these rewrites in other languages. They often learn from, and improve on, their predecessors in a way that having to maintain backwards compatability doesn’t allow.