My AI-built PHP engine in Rust passes 17% of PHP-src tests, renders WordPress • Hacker News Board

Re: My AI-built PHP engine in Rust passes 17% of PHP-src tests, renders WordPress

#71

Post by brailsafe » Sun, Jul 05, 2026, 10:00 PM UTC

sshine wrote: post #56

brailsafe wrote: post #31

Earlier quoted context omitted.

> 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 billa…

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 answ…

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.

Re: My AI-built PHP engine in Rust passes 17% of PHP-src tests, renders WordPress

#72

Post by sshine » Sun, Jul 05, 2026, 11:10 PM UTC

kmoser wrote: post #69

sshine wrote: post #53

Earlier quoted context omitted.

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.

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

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.

Re: My AI-built PHP engine in Rust passes 17% of PHP-src tests, renders WordPress

#73

Post by sshine » Mon, Jul 06, 2026, 5:52 AM UTC

brailsafe wrote: post #71

sshine wrote: post #56

Earlier quoted context omitted.

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 answ…

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.

> 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.