[sshine]

My boss asked me to set up a WordPress for a product landing page.

I naturally won't do this; it's no more than a couple of weeks ago that some SQL injection landed in the search query function of this monstrosity.

WordPress always was and always will be terrible.

So I set up the landing page with a Hugo static site, and I've been vibe-coding a WordPress-like dashboard that operates on git repositories containing Hugo sites.

I call it WorbPress (not released yet), and I'm sure that's what my boss told me to install, or I might've misheard.

And yes, it's written in Rust (with Axum and Alpine.js), because why not?

[techscruggs]

Let me make sure I am hearing you right. 1) The person you report to asked you to accomplish a discrete task 2) of standing up one of the most common websites on the planet 3) and your response was to begin building your own custom CMS?

I know I am removing the train of thought that led you down this path, but is there anything I just said that is factually false?

[sshine]

I’ll try to tell the story in a more responsible way: My boss asked me to install a WordPress, to which I advised against it; while it’s easy to set up, it doesn’t align with our tech stack (his main team won’t be able to support it easily, woohoo army of juniors!), and the convenience of a quick start is outweighed by having a thing that needs CVE patching when, guess what never got hacked: pure, static HTML.

Since my wife had asked me twice the same week to set up a website with a design mock she’d sent me, I thought: what’s holding me back in both cases from giving them a Claude Design’ed Hugo theme is that they need to edit Markdown on their filesystem and run terminal commands.

So I picked an item out of my infinite backlog, which was very well-defined: a web dashboard that acts as the equivalent of the WordPress admin page that lets you manage a Hugo static site, use a rich editor on top of Markdown, and commit to git instead of a database. I spent the better part of a weekend making this, with my wife as the customer, and when it got good enough, I presented it to my boss. He was happy with the choice, but mostly because of the vibed design, he ultimately didn’t care about the technology.

When someone wants “a WordPress” they’re asking for convenience of an easily updated website.

You don’t have to actually give them a WordPress.

[igetspam]

AI has helped us all lose the plot because now we don’t just know better than everyone else, we can prove it by project managing our better versions of the same things.

What I find really great is that we’re only a prompt or two away from proper docs for these novel solutions but we still don’t make them and if we do, we definitely don’t read them first.

[sshine]

I’ll say “proper docs” has shifted for me for two reasons

I used to insist on commenting code richly, so I could better read it. But comments lie, while code is truth. Read the code, that’s what it does.

With AI, the cognitive overhead of getting a human-worded explanation of what’s true, is one prompt away and is never a stale leftover.

So the purpose of docs: Specs for implementing and getting an architectural overview, and API documentation for exploring the interface of something new.

What I find great is that people still don’t test their code when it became practically free to do so.

[asp_hornet]

Is this the “taste” I keep hearing people say they bring?

[kmoser]

Just to clarify: you think your vibecoded dashboard is more secure than WordPress? Not saying you're wrong, just wondering why you think you're right. Are you auditing the generated code, or is it a giant yolo?

[lopatin]

Auditing the generated code would defeat the purpose of reckless insubordination.

[fastily]

I’m reasonably certain GP is (humorously) trolling us

[sshine]

Thank you.

[sshine]

How do you hack a static HTML page?

The point is that most WordPress pages don’t warrant the dynamic code execution on every page load.

When you use a static site generator and make content creation convenient behind the scenes, you move the entire attack surface to, in my case, nginx, the load balancer, and OpenSSL.

[kmoser]

You don't hack a static HTML page, you hack the (presumably public-facing) vibecoded admin panel that can update the static page.

[sshine]

I think "yolo" gets overloaded here to mean "not thinking".

I've described it as static HTML.

The admin dashboard isn't static HTML, but it also isn't public-facing.

The admin dashboard lives behind an oauth2-proxy authenticated via keycloak, and only accessible to the corporate wifi / vpn. The dashboard is really a completely separate application.

The probability that you can hack an admin panel because you know the public URL assumes either there's a "Login" button on the front page, or that the admin panel depends on the source code in the same way as the public-facing pages.

[sureglymop]

I feel like not choosing WordPress was a great choice but I'm not sure about the rest of the comment. A simple html file might make for a good landing page though.

[is_true]

Why not use headless WordPress?

[brailsafe]

> because why not?

I'm not certain, but it seems like you're not being entirely serious here, however..

If you aren't joking, or for other people in this position, I'd first wonder if the landing page required a search function that would hypothetically be subject to the vulnerability, then I'd wonder about what the normal nature of your business is and how much latitude you personally have in the allocation of billable hours to arbitrary technology choices and whether those do actually align with the deliverable, then if I was the boss I might wonder why you created a bunch of (potentially) out-of-scope random liability using unusual lesser-known tools based on a personal vendetta against WordPress.

I've been in this position, conceptually if not literally, and I've probably been (in a way, rightfully) fired for it, but my country's labor protections are likely not quite as good as Denmark's.

If there's a question about why money was spent on implementing a bunch of stuff nobody knows for a reason nobody cares about, especially for a very short-lived thing like a landing page, then it's a sticky situation if the answer is basically novelty. Something like this, if it does serve a purpose, should be planned for and a case made for it, but that also doesn't really seem like agency work.

If I was asked for WordPress, which I have, and I delivered Rust, I don't think I'd keep that job, but mileage may vary.

Most work is about solving problems as they are, not what we wish them to be, and if a 5 min job becomes a month long job that the customer didn't ask for, it's an extreme case of yak-shaving.

[sshine]

I get what’s you’re saying, and if I couldn’t justify making the best alternative I can imagine in my free time, because I’ve wanted it for a long time, I’d install “a CMS” (not WordPress).

> If there's a question about why money was spent on implementing a bunch of stuff nobody knows for a reason nobody cares about, especially for a very short-lived thing like a landing page, then it's a sticky situation if the answer is basically novelty.

The economy behind a decision like is this: alternative SaaS website builders are $20-60/mo./seat. We’ve historically paid $720/mo. for the ability to edit a single website that doesn’t look great but is dead simple to modify.

So if I can make something that scales up to any amount of sites and any amount of editors with ~10 hours on landing the design (which isn’t included in “a WordPress” either way), at ~$700, then I can justify making ten sites per year at the cost of our first.

Or more realistically: The total operating cost of the current website gives me 125 hours in a year to make something better.

Then the question is not “Can I make something better?” (Yes.) Or “Is it affordable to make something from scratch?” (It is.) But rather: Could I make more money doing something else? (I could halve the Azure budget in less than a month by optimizing and cleaning up.)

[brailsafe]

Makes sense to me, your other comment that elaborated on the scenario adds some useful context. I assumed there was quite a lot missing and tried to frame the comment for future versions of myself that might think it's a good idea to just run with a wildly out-of-scope idea with too much hubris.

[sshine]

> might think it's a good idea to just run with a wildly out-of-scope idea with too much hubris

I'll say that using git as a database instead of simply SQL leads to a lot of corner cases.

For example, you are inside a transaction from the moment you make a single change to anything.

But the filesystem is conventionally thought of as something that can be shared between sessions.

So I need a git worktree per user.

In both my use-cases there's very few users, but if there were two, and they decide to change things independent of one another, then

  - their worktrees will become stale, and I need to add somewhat automated checking how far behind they are
  - their stale worktree will have conflicts, and dealing with merge conflicts in a pedagogical way is a big task
  - working on multiple things at once is possible, but introducing "committed" on top of "draft" + "publish" adds mental gymnastics
  - using the filesystem as a database makes deployment to Kubernetes less trivial because you need persistent storage

One thing you get "for free", though, is authentic preview: Since the final site is a static site, I can just run the generator when the user wants to see a preview.

The nice thing about this is that if you remove the admin dashboard, it's just another static site.

It can be maintained perfectly fine with regular git and e.g. VSCode.

Add Nix + Claude and you have an entirely different mode of operation.

Which is what I like about plaintext (Markdown). It's not tied to any one program.

[librasteve]

what, no HTMX?