DEV Community: Walid Hassan Tahrim

PHP Is "Dead"...again💀

Walid Hassan Tahrim — Sat, 31 Oct 2026 10:32:48 +0000

A Hackers Hostel story: Submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

Quick question. How many WordPress sites do you know that are technically alive?

Not alive alive. Nobody's posting. Nobody's updating. But the domain renews every year, the server's still running PHP from a different era, and somewhere in there is a blog post that people still land on from Google. The site isn't dead. It's a ghost. It just hasn't been told yet.

Then on October 21, PHP shipped emergency patches for two critical remote code execution bugs (PHP2Shell), and a few days later CISA confirmed attackers were already using them. Guess which sites didn't get patched. Yeah. The ghosts.

We know a lot of those. Some of them are ours. So this week we built something for them.

What We Built

WP2Astro is a WordPress plugin that turns the site it's installed on into an Astro site, pushes it to GitHub, and keeps it in sync whenever you publish.

The flow is: install the plugin, click Convert to Astro, get a repo. No Node.js, no terminal, no copy-pasting application passwords. If you've ever installed a plugin, you're already qualified.

What comes out the other side:

Links stay. Every post, page, category, tag, custom post type and archive keeps its URL. The old weird ones too, like ?p=123, ?page_id=7, /feed/, and slugs you changed years ago. They all redirect where they should. A link someone shared in 2014 still works.
The look stays. Theme CSS, fonts, images and scripts come along, and an AI model rebuilds the header, menu and footer as an Astro layout from your homepage. It still looks like your site, because it is.
The junk gets buried. Shortcodes from plugins you deleted ages ago ([vc_row], [button], the usual suspects) get cleaned up instead of showing up as raw text forever.
You keep WordPress. You write where you always wrote. Visitors just get static pages.

Live Demo at hackershostel.com

HackersHostel / WP2Astro

Turn a WordPress site into a fast Astro site — same URLs, same look — push it to GitHub and keep it in sync. A WordPress plugin.

WP2Astro

Turn a WordPress site into a fast Astro site — same URLs, same look — push it to GitHub, and keep it in sync.

WP2Astro is a WordPress plugin by Hackers Hostel. It converts the site it runs on into an Astro project, pushes it to a GitHub repository and keeps that repository up to date as you publish. You keep writing in WordPress; your visitors get a static site. Free and open source (GPL-2.0-or-later).

Highlights

Installs like any plugin. No Node.js, terminal or application passwords on your side: upload the zip, open WP2Astro, click Convert to Astro.
Same URLs. Every post, page, custom post type entry, category and tag keeps its permalink, and so do paginated archives and year, month and author archives. Old links still work: changed slugs, ?p=123, ?page_id=7 ?s=search and /feed/ redirect to the right place.
Same look. The theme's…

View on GitHub

How We Built It

The AI in this thing runs on open-weight models, on your own machine if you want.

There's a Local model option that works with anything that speaks the OpenAI API: Ollama, LM Studio, llama.cpp, vLLM. Pull Gemma, point WP2Astro at http://localhost:11434/v1, hit Test, done. Your posts never leave your network. If you don't want to host a model, OpenRouter is supported, and even there the default is the open google/gemma-4-31b-it.

We kept the AI's job small on purpose. It does exactly two things:

Writes the Astro layout from your homepage's header, menu and footer (scripts and styles stripped out first).
Fixes posts that have dead shortcodes in them.

That's it. And here's the part we actually care about: we don't trust it. Every answer goes through strict checks. If it fails, WP2Astro uses a plain default layout, or leaves the shortcode alone and writes it into CONVERSION_REPORT.md so you can deal with it. A small model can have a bad day and your site is still fine. That's why "use a small open model" is a real option here and not a downgrade.

It also caches answers, so syncing doesn't ping the model unless your theme, your menu or one of those shortcode posts changed.

The rest is just PHP doing PHP things:

Content becomes Markdown with frontmatter. Text that only looks like Markdown gets escaped, because we learned the hard way that __init__ turns bold if you let it.
Work is split into small steps run by the dashboard, WP-Cron or WP-CLI, so it doesn't time out on cheap hosting.
GitHub login uses the device flow. Syncs only commit what changed, and if you edit a file in the repo yourself, we never overwrite it.
SEO data from Yoast, Rank Math or AIOSEO comes over, plus RSS, a sitemap, robots.txt and Pagefind search.
Media can live in the repo, in Git LFS, on WordPress, or on S3, R2 or Bunny.

Each repo also comes with an agent kit (AGENTS.md, CLAUDE.md, skills) so a coding agent can pick up whatever the conversion flagged.

Why Open Innovation Matters

WordPress got this big because anyone could take it and do whatever they wanted with it. It'd be pretty backwards to build a tool for WordPress people that only works if they rent a closed model forever.

With open weights the whole stack is something you can actually own. GPL plugin, Astro, Git, a model on your own hardware. Free to run, private by default, and none of it stops working if we stop paying attention to it. For a tool whose whole job is making sure old stuff doesn't disappear, that kind of matters.

Also, real talk: this design only works because open models got good enough at being small. Checks plus fallbacks means a modest Gemma does the job.

Spirit of the Project

So much of what people wrote online sits on WordPress installs that nobody wants to babysit anymore. Those sites don't get shut down because they stopped mattering. They get shut down because updating PHP is boring.

We'd rather they stick around. Same words, same links, same look, way less maintenance. 🕯️

And to be clear, this isn't a "PHP bad" post. WP2Astro is PHP too, and PHP has been "dead" for about 30 years now. It's just that after PHP2Shell, PHP belongs backstage. Your WordPress still runs it, so you still patch it, and you can keep wp-admin off the public internet entirely. What your visitors hit is plain HTML. No PHP runs there for anyone to pop.

👉 github.com/HackersHostel/WP2Astro

— The Hackers Hostel crew: @mahmudurrahmanlabib, @tahrimwalid and @mahedi

One Face, Many Agents: Meet AgentWebUI

Walid Hassan Tahrim — Sun, 25 Oct 2026 02:52:38 +0000

A Hackers Hostel story: Submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

It's 1 a.m. and I have three coding agents running on the little Linux box in the corner of my room. Codex is refactoring something in one tmux pane. Claude is still "thinking" in another, on "medium effort" mind you. Gemini CLI has been waiting for me to approve a file write for twenty minutes, in a terminal I forgot I opened.

I'm in bed, laptop closed. To see what any of them are doing, I have to SSH back in and go pane-hunting.

That's the part nobody tells you about CLI agents: they're brilliant, and they live in a terminal. Each one has its own slash commands, its own approval prompts, and its own idea of what a diff looks like (usually a wall of text scrolling past faster than you can read it). My sessions are scattered across panes, tabs, and, because I'm that kind of person, two machines and two accounts. My muscle memory has filed for divorce and is asking for the good keyboard.

How we got here

A few of us at Hackers Hostel share a group chat that is roughly 40% memes and redacted content, and 60% complaining about tooling. One week the complaint was always the same: every agent speaks its own dialect. New commands, new prompts, new way of showing you what it just did to your code, and no way to check on any of it without being glued to the terminal it started in.

From the builder side it's worse. Every agent team ends up writing the same dashboard: a chat pane, a message list, a model dropdown, a little loading animation, a button to stop the thing before it rewrites your entire git history. Between us, we've built that exact dashboard more times than we'd like to admit. One of us built it in three different JavaScript frameworks. You know the drill: "Oh, this one's a tad bit faster than the other..." Bro, pick a lane.

Then someone (name withheld, they know what they did) typed: "why does every agent get a new face? just give them all the same one."

The chat went quiet for about four seconds. Then everyone started typing at once.

What made that more than a group-chat topic was timing. Agents had finally started speaking a shared protocol (ACP, more on that below), which meant one interface could actually talk to all of them instead of needing a custom integration per agent.

The big one, and the small one

That message turned into the first AgentWebUI: one web interface for driving CLI coding agents like Claude Code, Codex, Gemini CLI and OpenCode, plus anything else that speaks ACP. You pick the agent, the interface stays the same. Your brain gets to keep its shortcuts.

Then it grew. It picked up features. It picked up more features. It got heavy in the way your backpack gets heavy when you keep tossing chargers in it and never take any out. No offense, but those people are psychopaths.

So we gave the big one a new name, AgentWebUI Pro, and let it keep the control-room job it had grown into. Then, for Hacktoberfest week 3, we set ourselves a constraint: rebuild AgentWebUI from scratch, this week, as the smallest thing that still does the job. One dependency. No build step. A codebase you can read in one sitting. It takes the idea and the lessons from Pro, and it's what carries the AgentWebUI name now.

The whole design goal fits on a sticky note:

Install it. Open the browser. Talk to your agent. If that takes more steps than making toast, we messed up.

Setup, for people who also hate reading setup instructions:

git clone https://github.com/HackersHostel/AgentWebUI.git
cd AgentWebUI
cp .env.example .env   # fill in your models and agents
docker compose up -d

That's the whole onboarding. No accounts, no setup wizard, no twelve-page wiki, no "first, install our other CLI to install this CLI." Everything lives in .env. Running it on a homelab box or a VPS like I do? There's also an install script that sets it up as a systemd service with Caddy for HTTPS. Want to poke it before you clone anything? There's a live demo: agentwebui.hackershostel.com

What you get (and what you don't)

Basically you get what you bargained for:

One chat interface, no matter which agent is doing the work behind it.
Every agent on your machine or server, reachable from a browser. No more SSHing in to find out which pane is waiting on you.
Readable diffs and approval prompts in one consistent place, instead of a different style per agent. Like getting intel from five squads who all refuse to use the same map.
Switch agents without relearning where anything is.
A small codebase you can actually read in one sitting, which matters a lot if you plan to send us a PR (you do, keep reading).

You don't get:

The full control-room experience. That's what our big sibling, AgentWebUI Pro, is for.
A dashboard with 14 tabs you'll open once. AgentWebUI is for when you just want to talk to your agents, not manage a fleet of them. Well, not yet at least. Fingers crossed.

Under the hood (the part where I brag a little)

Remember the three JavaScript frameworks? The web client uses none of them. It's Preact through htm with no build step. No bundler config, no node_modules folder with its own weather system. You change a file, you refresh, it's there.

The server is about 3,000 lines of Python with exactly one dependency (aiohttp), and it runs in around 40 MB of memory. A single browser tab usually eats more than that just to show you a loading skeleton.

The thing that makes "one face for every agent" actually work is the Agent Client Protocol. Think of it as LSP, but for coding agents. Zed and Google started it because every new agent-plus-editor combo needed its own custom integration, which is the exact same headache we were complaining about, just with better funding. Anything that speaks ACP over stdio plugs straight in: Claude Code and Codex (through their ACP adapters), Gemini CLI, OpenCode, Hermes, Pi. You pick the agent, then its model and effort, then the folder it works in. It streams the thinking, the plan, the tool calls and the diffs, and it asks before it touches anything.

If your eyes glazed over somewhere around "stdio," here's the squad-briefing version: the agents are your squad, ACP is the radio, and AgentWebUI is the one headset that talks to all of them. Nobody has to learn a new radio every mission, and nobody gets left on an open channel waiting for orders while you're in bed.

On the model side, anything with an OpenAI-compatible API works: OpenAI, OpenRouter, Groq, or a local model through Ollama, LM Studio or vLLM. So your quick questions can go to a small model on your own laptop and never leave the building.

Why open, though?

Every agent vendor wants you living in their tab. Totally fair from their side. From your side, it means your workflow breaks every time someone ships a better model somewhere else.

Open protocol, open models, open code: switching becomes an edit to .env and a restart, not a migration weekend. And since it's self-hosted, your code and your chats stay on your machine instead of taking a field trip to someone else's cloud. No telemetry phoning home, no mystery servers. As Captain Price would put it: "Bravo Six, going dark."

RIP, Captain. (Yes, that's an MW4 spoiler. If you haven't finished the campaign, you've had two days. We're not sorry.)

Code

HackersHostel / AgentWebUI

The lightest web UI for OpenAI-compatible model APIs and ACP agents.

AgentWebUI

One small web page to chat with AI models and with command-line agents, on your own server. Open it and chat there is no setup screen and no accounts. Everything is configured in .env. The package and command are still named agentwebui-lite.

Models: any OpenAI-compatible API (OpenAI, OpenRouter, NVIDIA, Groq, Ollama, LM Studio, vLLM, …).
Agents: anything that speaks the Agent Client Protocol over stdio: Claude Code, Codex, Hermes, Pi, Gemini CLI, OpenCode, … Pick the agent, then its model and effort, then the folder it works in. It streams its thinking, plan, tool calls and diffs, and asks before it acts.

The server is about 3,000 lines of Python with one dependency (aiohttp) and uses about 40 MB of memory. The web client is Preact through htm with no build step. Nothing loads from the internet unless you pick a font other than Geist.

…

View on GitHub

Our very "punctual" release process

Version 0.1.0 went up on PyPI at 00:23 GMT on October 20. Version 0.2.0 went up at 10:48 GMT. The same day.

That's ten and a half hours between releases. That's not a release cadence, that's a sleep schedule asking for help. (We're on 0.3.0 now. Please don't ask what time it is.) It also means, with total honesty, that there are bugs in here. Some we know about. Some are hiding. Some are probably features we haven't explained yet.

Which brings me to the real reason I'm writing this.

Hacktoberfest: come break our code

As Captain Price used to say : "We get dirty, and the world stays clean." That's open source in one sentence. Somebody digs through stack traces at 3 a.m. so everybody else gets software that just works. We're recruiting for the digging.

Hacktoberfest is different this year: it's all about building with open-source AI, which is basically our whole personality right now. There's no PR count to chase anymore, but contributions still get you our eternal gratitude and your face in the contributors list. Here's the mission briefing:

Star and fork the repo: github.com/HackersHostel/AgentWebUI
Install it and try to break it. Point it at whatever agent you've got. Click things you shouldn't. Paste a 9,000-line stack trace into the chat. Resize the window to the width of a breadstick.
When it breaks, open an issue. Repro steps are beautiful. "it doesnt work lol" is less beautiful, but we'll still read it.
Then fix it and send the PR. We review fast, partly because we're excited and partly because we're awake anyway.

Things we would love help with:

Bridges for more agents. Anything that speaks ACP already works. If your favorite agent doesn't, help it learn. That's the whole point of the project.
UI polish. Our CSS was written at 3 a.m. by people who think !important is a personality trait. Not to mention thousands of edge cases that we ignored like a div that’s never gonna be centered. Besides who uses Safari anyway right guys?!
Tests. We have some. "Some" is doing a lot of heavy lifting in that sentence.
Docs. If you got confused anywhere during setup, that's a docs bug. Please fix the sentence that confused you.
Accessibility. Keyboard nav, screen readers, contrast. We want this to work for everyone, not just people with our exact monitor.

While you're in the Hacktoberfest mood, have a look at hacktoberfest.com: this year it's local Fests and building with open models instead of counting PRs.

One small request: no drive-by PRs that change one typo into a different typo. We see you. We love you. Please write a test instead.

Stop learning a new interface for every agent. Teach one interface to speak every agent!

Come help us build it. Bring coffee. Queue up a match of MW4 while the Docker image pulls; we won't tell.

👉 github.com/HackersHostel/AgentWebUI

— The Hackers Hostel crew: @mahmudurrahmanlabib, @tahrimwalid and @mahedi

P.S. Mahmudur wrote about the same project from a very different angle (sloths, chainsaws, too many tabs). Go read that one too.
This is my very first Dev.to post. Kindly ignore my oversights.