Does PHP still have a future in 2026 — or is it just the language the web can’t uninstall?

PHP is the language the web cannot uninstall. That is not an insult. It is a description of WordPress, Laravel apps that print money, Magento shops nobody wants to touch, and a billion index.php files behind nginx. The interesting 2026 question is not whether those files vanish. They will not. The question is whether I would still start a product in PHP, or only inherit one.

I have shipped both. I have also spent a year trying to talk a founder out of a greenfield Laravel app because they wanted to look modern, and a year talking another founder into keeping theirs because the alternative was a rewrite they would not finish. The future is not a vibe. It is a staffing and operations story, like Java’s, with worse conference branding and a better “get a page on the internet” story.

What is actually still alive

PHP 8 is a different language from the one people mock. Types that mean something. Enums. Attributes. A JIT you will not notice on a typical request. Composer that is just how you work. Laravel, Symfony, and WordPress as three different civilizations that share a runtime.

Laravel is the product-shaped future. A small team can ship auth, queues, a sane ORM, a scheduler, and a deploy story with Forge or a container. I have seen a three-person shop outrun a six-person Node team because the Laravel conventions decided the arguments for them. That is a future. It is not a keynote future. It is a billing-future.

WordPress is the un-uninstallable future. The CMS, the plugin economy, the agency food chain, the “we need a site on Tuesday” economy. Gutenberg and a headless REST or WPGraphQL layer keep it in the conversation. I would not build a novel product inside WordPress PHP if I could avoid it. I would still hire people who can operate it, because the business already did.

Symfony is the enterprise-shaped future inside PHP: explicit, testable, a bit joyless, hireable in Europe. If your company is already there, leaving for Spring or Nest is a religious project. I do not start religious projects for sport.

The runtime is fine. FrankenPHP, Octane, a workers model that is not “spawn php-fpm and pray” — the old process model jokes are dated if you bother to update. Plenty of shops have not bothered. Their future is the future of unpatched PHP 7.4, which is to say: a CVE waiting room.

The future I would not bet the company on

I would not bet a new consumer social product on PHP because I wanted a monoculture. I would not bet a latency-sensitive fan-out system on it — hire the BEAM or Go for that. I would not bet a mobile-heavy startup’s only API on WordPress. I would not hire a team whose only growth path is “more plugins.”

I would not pretend PHP is a great systems language. Shared-nothing request workers are a feature for typical web work and a limitation when you want long-lived connections and a lot of in-process state. You can do WebSockets. You will do them worse than a shop that picked the runtime for that job.

I would not pretend the hiring brand is fine in every city. In some markets Laravel seniors are plentiful and cheap relative to the work they ship. In others, every ambitious mid wants TypeScript and will treat PHP as a stain. That is a real constraint. Defaults are local. If I cannot hire, the language does not have a future here, even if it has one on the internet.

When I would still ship a product in PHP

A B2B CRUD with a lot of forms, a queue, mail, and a finance export — Laravel, Postgres, Horizon, a test suite, Forge or a boring container. I would ship that tomorrow. The product is the domain, not the runtime. Agents write Laravel as happily as they write Next.js. The difference is whether the conventions keep the generated code inside a shape I can review.

A content business that is already WordPress. I would not migrate it to a headless fashion stack unless the editorial team asked and the plugin tax was actually the problem. Most “we should leave WordPress” projects I have seen were a designer’s taste and a six-month hole.

An agency that lives on PHP. I would not convert the agency to Node as a strategy. I would convert the worst legacy file to a Symfony module or a Laravel app, one client at a time.

A team that already has PHP scars and a working deploy. Greenfield in the same language is how you keep on-call sane. I have already written the Java version of this paragraph. It applies here with more memes and the same truth.

When I would not start a new one

When the team is TypeScript-native and the product is a TypeScript UI with a thin API. Starting Laravel “because PHP is fine” adds a second culture for no operational win.

When the core problem is a long-lived connection fabric, a native mobile sync engine, or a data-heavy worker that wants Go and sqlc. PHP can worker. I would rather the worker language match the people who will be paged for the worker.

When the founder’s only reason is “WordPress is cheap.” Cheap to start, expensive to make unique, expensive to secure, expensive to staff if you outgrow the agency model. I would start with a boring Laravel or a boring Next and a boring database, not with a CMS I will spend two years fighting.

When the compliance story wants a JVM or a .NET shop’s existing audit muscle. I will not introduce PHP to look scrappy in a bank. Scrappy is not a control.

A year I wasted, and a year I did not

The wasted year was a Magento 1 shop we tried to “just move to Node.” We moved the catalog. We did not move the fifteen years of promotions, tax hacks, and a warehouse export that lived in a PHP cron. Six months in we had two catalogs. The Node app was prettier. The money still ran through PHP. We should have upgraded the PHP and put a nicer storefront in front. We wanted a story. We got a dual-write incident.

The year I did not waste was a Laravel app for field inspections: forms, photos, a queue, a PDF. Three engineers. Postgres. Horizon. We said no to a microservice for the PDF. We shipped. PHP was not the interesting part. The interesting part was that we did not invent a second culture. That is the future I will keep buying.

The uninstall problem

The web cannot uninstall PHP because uninstall is a rewrite, and rewrites are how companies lose a year. The future of PHP is the future of those rewrites not happening. That is a large future. It includes a lot of unglamorous money.

It also includes a trap: treating “cannot uninstall” as “should install more.” I will maintain. I will extend. I will not add a new line of business in PHP solely because the old line of business is PHP, if the new line is a different shape. Shared runtime is not shared destiny.

Security is the other uninstall problem. Old PHP is a scanning target. If your future is PHP, your future is current PHP, composer audit, and a patch habit. A language with a future that you refuse to update is a language with a past that will visit you on a Friday.

What I tell leads who ask “should we leave”

Leave if you cannot hire, cannot patch, or the runtime is the actual constraint — connections, CPU, a library you will not rewrite. Do not leave because a conference laughed. Do not leave because a senior wants to put Nest on the résumé. I have paid for that résumé. The users did not notice, except when the rewrite slipped.

Stay if the product is forms, workflows, content, commerce, and the team can write tests. Upgrade the version. Kill the global functions. Put a queue on the email. That is a future. It is not romantic. Neither is most of the web.

Does PHP still have a future in 2026? Yes: as a default you inherit, as Laravel for a certain shape of product, as WordPress for a certain shape of business. Is it just the language the web cannot uninstall? That is most of the future, and it is enough to make a career if you are honest about it. I would still ship. I would not start a new one unless the team, the shape, and the hiring lined up. Excitement is not one of those three.

If you are choosing this week: write the constraints on a page. If they say “we have Laravel people and a CRUD product,” stop interviewing languages. If they say “we want to look like a 2026 startup,” ask whether looking like one ships the invoice. PHP will still be there when the looking is over. That is either a comfort or a warning. I treat it as both.