DEV Community: Getwebup

PHP 8.5 in cPanel: What's New and How to Upgrade Safely

Getwebup — Wed, 28 Oct 2026 23:20:14 +0000

PHP 8.5 has been out since November 2025, and if you're still running PHP 8.1 or 8.2 on your cPanel hosting, you're closer to an unsupported version than you might think. Here's what's actually new in 8.5, why your MultiPHP Manager might not show it yet, and how to move up without a support ticket at midnight.

Symptom: PHP 8.5 Isn't in Your MultiPHP Manager Dropdown

You log into cPanel, open MultiPHP Manager, and the highest version listed is 8.3 or 8.4. You've read that 8.5 is out, maybe even seen a plugin changelog mention it, but your account simply doesn't offer it as an option.

That's not a bug on your end. It's almost always one of these two things:

Your hosting provider's EasyApache 4 (WHM) hasn't pulled in the PHP 8.5 SCL package yet.
Your account is on shared hosting where the server admin controls which PHP versions get compiled server-wide, and 8.5 hasn't been added to that list.

If 8.5 isn't in your list, ask your host which PHP versions your server offers. On a cPanel VPS you control the EasyApache 4 profile yourself, so you can add 8.5 whenever you're ready.

Cause: Why cPanel Lags a Few Weeks Behind a PHP Release

EasyApache 4 doesn't compile PHP from source for every account — it installs pre-built SCL (Software Collections) packages maintained by CloudLinux/cPanel's build system. Those packages need every commonly-used PHP extension to compile cleanly against the new version first, especially ionCube Loader, which is a closed-source binary that has to be rebuilt by ionCube themselves after each PHP release. If ionCube hasn't shipped an 8.5 build yet, most cPanel providers hold off adding 8.5 to the general rollout, because half their customers on licensed themes and plugins would break immediately.

That lag is a feature, not a delay for its own sake — it's the difference between "PHP 8.5 works" and "PHP 8.5 works except for the WooCommerce extension license checker nobody remembers installing."

What's Actually New in PHP 8.5

Nothing here forces code changes on its own — 8.5 is a lighter release than 8.4 was. A few additions worth knowing about before you upgrade:

The pipe operator (`|>`)

You can now chain function calls left-to-right instead of nesting them inside out:

// before
$result = array_sum(array_filter(array_map('trim', $items)));

// PHP 8.5
$result = $items
    |> (fn($x) => array_map('trim', $x))
    |> (fn($x) => array_filter($x))
    |> array_sum(...);

Arrow functions on the right of |> must be wrapped in parentheses, as above; PHP 8.5 rejects the chain without them.

Nice for readability, but existing code doesn't need to be rewritten — it's purely additive syntax.

`array_first()` and `array_last()`

No more reset($arr) / end($arr) gymnastics that mutate the array's internal pointer as a side effect. These two return the first/last value directly without touching pointer state, which matters if you were ever bitten by a stray current() call returning the wrong element after a reset() somewhere else in the request.

Closures in constant expressions

You can now use a static closure in a constant expression: a class constant, a default parameter or property value, or an attribute argument. Mostly relevant to framework and library authors; unlikely to affect a typical WordPress or WooCommerce stack.

The `#[\NoDiscard]` attribute

Lets a function author mark a return value as one that shouldn't be silently thrown away — PHP emits a warning if you call the function without using the result. If a library you depend on adopts this, watch your error log for new warnings that a return value should be used; they're warnings, not fatal errors.

None of these are breaking changes. The bigger practical question for a hosting account isn't "what's new" — it's "what stopped being supported."

PHP Version Support: Where You Actually Stand

Version	Released	Status as of mid-2026	What it means for you
PHP 8.1	Nov 2021	End of life — no security patches	Upgrade now, not on your next slow week
PHP 8.2	Dec 2022	Security-fixes-only phase	Plan the move within the next few months
PHP 8.3	Nov 2023	Security-fixes-only phase	Still fine, but active feature support has ended
PHP 8.4	Nov 2024	Actively supported	Safe default for most sites right now
PHP 8.5	Nov 2025	Actively supported (newest)	Fine to test on staging; wait if your stack has licensed plugins that haven't confirmed compatibility

If MultiPHP Manager shows your account still running 8.1, that's the one to fix first — not because 8.5 has some feature you need, but because 8.1 no longer gets patched against newly discovered vulnerabilities at all.

Fix: Upgrading Without Breaking Anything

Step 1 — Check what's actually installed. In WHM, go to Software > MultiPHP Manager and note every domain's current version. On a VPS with root access you can list the same from the command line:

whmapi1 php_get_installed_versions
whmapi1 php_get_vhost_versions   # the PHP version of each domain

Step 2 — Confirm ionCube and premium extensions support the target version. If any theme or plugin license checker depends on ionCube Loader, check ionCube's own compatibility page before switching a production domain. This one step avoids many "site went white after PHP upgrade" problems.

Step 3 — Clone to a staging subdomain first. cPanel's WordPress Toolkit (if you're on WordPress) or a manual file+database copy to a subdomain both work. Switch the staging copy's PHP version in MultiPHP Manager and load every major page type — home, a product/post page, checkout if it's WooCommerce, and wp-admin.

Step 4 — Watch the error log while testing, not after. Tail it live during your staging test instead of checking it the next day:

tail -f ~/public_html/error_log

Deprecation notices are fine to leave for later cleanup. PHP Fatal error or PHP Parse error entries mean don't switch the live site yet — go fix that plugin or theme first, or hold at 8.4 until it's patched.

Step 5 — Switch the live domain, then re-check the log for the first 15 minutes. Most real breakage shows up on the very first page load after the switch, not hours later. If something's wrong, MultiPHP Manager lets you roll back to the previous version in seconds — there's no migration to undo, since PHP version is just a routing setting, not a data change.

Common Breakage After the Switch

ionCube-licensed themes/plugins go white-screen. The loader hasn't been rebuilt for the new PHP version yet. Roll back until ionCube ships an updated build, or contact the plugin vendor for their timeline.
An abandoned plugin throws a fatal error on activation. Usually a function PHP removed several versions ago finally getting called. Deactivate it and look for a maintained alternative — code that was already deprecated in 8.1/8.2 was living on borrowed time regardless of when you upgraded.
A custom functions.php snippet from years ago breaks. It's usually a five-minute fix once you can see the actual error instead of a blank screen — which is exactly why Step 4 above matters.

Prevention: Make the Next Upgrade a Non-Event

Keep one PHP version behind the newest release on production unless you have a specific reason to be on the bleeding edge — let the ecosystem catch up first.
Set a recurring reminder to check MultiPHP Manager every few months rather than waiting for a security-support deadline to force your hand.
Retire plugins and themes that haven't shipped an update in over a year. If they can't keep up with PHP releases, they're a growing liability regardless of what version you're on today.
Keep a staging subdomain around permanently instead of spinning one up under pressure — it turns "should I upgrade?" into a five-minute check instead of a weekend project.

PHP 8.5 itself isn't a scary upgrade — it's a quiet release with a few nice additions and almost nothing that breaks working code outright. The risk was never really the new version; it's whatever hasn't been touched since PHP 7.

FAQ

Is PHP 8.5 available on my shared hosting yet?

Check MultiPHP Manager in cPanel — it lists every PHP version your server offers. If 8.5 isn't there, ask your host which versions your server has.

Do I need to rewrite my code to move to PHP 8.5?

No. PHP 8.5 is additive — new syntax like the pipe operator and array_first()/array_last() are optional. Existing code that ran fine on 8.4 will almost always run fine on 8.5 without changes.

What PHP version should I actually be running right now?

PHP 8.4 is the safe default for most sites in mid-2026. PHP 8.1 is end-of-life with no security patches, so move off it first regardless of whether you go to 8.4 or 8.5.

My site broke after switching PHP versions in MultiPHP Manager. How do I undo it?

Go back into MultiPHP Manager and select the previous PHP version for that domain. It takes effect immediately with no data loss, since switching versions only changes how PHP executes your existing files.

Why did my licensed theme or plugin go white-screen after the upgrade?

This is almost always ionCube Loader not yet rebuilt for the new PHP version. Roll back to your previous PHP version and check ionCube's compatibility page before trying again.

Originally published on the Getwebup blog.

This article was created with the help of AI.

VPS vs Shared Hosting: Which One Do You Actually Need?

Getwebup — Wed, 28 Oct 2026 23:14:20 +0000

This is the most common upgrade decision in hosting, and it's usually made for the wrong reason — a site feels slow, so the assumption is "I need more power," when the real fix is a caching plugin that costs nothing. Here's how to actually tell whether shared hosting is the bottleneck, or whether it's something a bigger plan won't fix either.

What Shared Hosting Actually Is

One physical (or virtual) server, split across many customer accounts, each with its own cPanel login and its own slice of CPU, RAM, and disk I/O — enforced by something like CloudLinux's LVE limits, which cap how much of the shared machine any one account can consume. You don't get root, you don't touch the OS, and you don't see or affect other accounts on the box. In exchange, it's cheap, it's zero-maintenance, and for a huge number of sites, it's genuinely enough.

What Changes on a VPS

A VPS gives you root access to your own operating system, with a fixed allocation of vCPU and RAM isolated from other customers, though on most plans CPU time is still shared fairly with neighbours (VDS-style plans pin dedicated cores to you). That's the whole trade: more control and more consistent resources, in exchange for more responsibility (unless you pay for managed support) and a higher price.

Signs You've Actually Outgrown Shared Hosting

You keep hitting resource limits during normal traffic - not just during a launch-day spike, but on an average Tuesday. If your host's control panel shows you repeatedly maxing your CPU or entry-process limit under everyday load, a bigger shared plan just delays the same wall.
You need software the shared environment won't allow - a background job queue, a non-PHP runtime, a database engine your host doesn't offer, or a service that needs to listen on its own port. Shared hosting is sandboxed on purpose; if your app needs to step outside that sandbox, no shared plan will let it.
You need root for a real reason - custom PHP extensions, a specific server config your host's shared environment doesn't expose, or compliance requirements around what's installed on the machine.
"Noisy neighbours" are a recurring, provable issue - if you can show (via your host's own resource-usage reporting) that you're within your allocated limits and still seeing inconsistent performance, that's a shared-hosting-specific problem a VPS's reserved resources actually solves.

Before You Upgrade, Rule These Out

A slow site on shared hosting is very often NOT a shared-hosting problem. Check these first — they cost nothing and fix the same symptom a VPS migration is often used to paper over:

No caching. A database-backed CMS (WordPress, most PHP apps) hitting MySQL on every single request will be slow on a VPS too if nothing is cached. A page cache or object cache plugin is usually the single biggest speed fix available, on any hosting tier.
Unoptimised images and no CDN. Large, unresized images are a bigger drag on load time than CPU headroom, on shared hosting or not.
A plugin or query actually causing the slowdown. Check your host's resource usage graphs for what's actually spiking - it's frequently one runaway process or one missing database index, not a fundamental lack of capacity.

The Honest Cost Comparison

Factor	Shared hosting	VPS
Typical monthly cost (India)	₹99 – ₹500	₹450 – ₹5,000+ depending on specs
Server management	Fully handled by the host	Your job, unless you pay for managed support
Root / custom software	No	Yes
Resource guarantee	Fair-use share of a shared box	Reserved vCPU/RAM, yours alone
Setup effort	Minimal - upload and go	OS hardening, firewall, ongoing patching if unmanaged

The real cost of a VPS isn't just the monthly bill - it's the time (or the managed-support fee) that goes into keeping a server patched and secure. Budget for whichever one you're actually going to pay.

The Middle Ground

If the honest answer is "I want more headroom but I don't want to manage a Linux box," a managed VPS is built exactly for that gap - root access stays available for the specific things you need it for, while OS updates, security patching, and monitoring stay with the host. It costs more than unmanaged, but it's still a different trade-off than fully-managed shared hosting: you keep the control that made you look at a VPS in the first place.

If You Decide to Move: A Realistic Checklist

Provision the VPS and secure it first, before migrating anything - root password or SSH keys, a firewall allowing only the ports you need, and OS updates applied.
Install the stack your site actually needs - web server, PHP or your runtime, database engine, matching versions to what's running on shared hosting to avoid surprises.
Copy files and export/import the database onto the new server without touching DNS yet, so the live site keeps serving traffic while you work.
Test the site on the new server using a hosts-file override or a temporary subdomain pointed at its IP, checking forms, logins, and anything database-dependent, not just that the homepage loads.
Set up backups on the new server before you need them, not after - shared hosting often includes this by default, and it's easy to forget it's now your job.
Lower your DNS TTL a day or two ahead, then switch the DNS record once testing passes, and watch error logs closely for the following 24-48 hours while propagation completes.

FAQ

Will moving to a VPS automatically make my site faster?

Not by itself. If the actual bottleneck is an uncached database query or unoptimised images, that problem follows you to a VPS. A VPS fixes resource-limit problems and lets you fix performance problems yourself (caching, tuning) that shared hosting's sandbox might have prevented.

Can I move from shared hosting to a VPS without downtime?

Mostly, yes, with planning: set up the new VPS, migrate your files and database, test the site there (using a hosts-file override or staging subdomain), and only switch DNS once everything checks out. DNS propagation itself takes time, which is the main unavoidable transition window.

Do I need to know Linux server administration for a VPS?

For an unmanaged VPS, yes - enough to apply security updates, configure a firewall, and troubleshoot a service that won't start. A managed VPS plan removes most of that requirement by keeping the OS-level work with the host.

What's actually enforced on shared hosting that isn't on a VPS?

Resource caps (CPU seconds, concurrent processes, memory per account - typically via CloudLinux LVE), restrictions on what software you can install or run, and no access to server-level configuration like php.ini beyond what the panel exposes. A VPS removes all three because you have root.

Is a VPS overkill for a small business website?

If the site is mostly static content or a standard CMS with moderate traffic, shared hosting is usually the right fit and a VPS is unnecessary cost and responsibility. A VPS earns its keep when you need root, a specific runtime, or resources shared hosting's fair-use limits won't provide.

Originally published on the Getwebup blog.

This article was created with the help of AI.

How Much Does VPS Hosting Cost in India?

Getwebup — Wed, 28 Oct 2026 23:13:53 +0000

There's no single answer to "what does a VPS cost," because the honest answer depends on six or seven variables that two different pricing pages rarely present the same way. What follows is what actually moves the number, roughly what the Indian market looks like bracket by bracket, and — more usefully — what to check before you trust a comparison between two quotes. Specific numbers below are broad, current-market brackets, not any one provider's price list; they move over time, so check live pricing before you budget against them.

What Actually Drives the Price

vCPU, RAM and disk. The baseline resource spec is still the biggest lever. Doubling RAM or vCPU roughly (not exactly) doubles the entry cost at most providers.
Disk type. NVMe costs more to provide than SATA SSD, which costs more than spinning disk (rare now, but still sold cheap). NVMe's IOPS advantage is real for database-heavy workloads, not just a marketing line.
Bandwidth allowance. Some plans include a generous or unlimited transfer allowance; others cap it and charge for overage. A cheap headline price with a small included allowance can end up costing more than a slightly pricier plan with room to spare.
Managed vs unmanaged. Managed support - the host handling OS patching, monitoring, and security - typically adds a flat monthly fee on top of the base VPS price. It's real, ongoing work, and providers price it as such.
Region. A server in an Indian datacentre avoids the cross-border latency (and sometimes the currency) of a server in Singapore or the US. Indian regions aren't automatically cheaper, but they remove the exchange-rate variable entirely if the provider bills in rupees.
Fixed tiers vs build-your-own. Some providers sell a handful of named plans; others let you size vCPU, RAM, disk and bandwidth independently. Neither is "better" pricing - but comparing a fixed tier against a custom build only works if you match the actual specs, not just the sticker price.

Typical Brackets in the Indian Market

Tier	Typical monthly range	Typical specs	Fits
Entry	Under ₹500	1-2 vCPU, 1-4 GB RAM, 25-40 GB SSD/NVMe	Small apps, dev/test boxes, low-traffic sites
Mid-range	₹500 - ₹2,000	2-4 vCPU, 4-8 GB RAM, 50-100 GB	Production sites and apps with real traffic
Higher-spec	₹2,000 - ₹6,000+	4-8+ vCPU, 8-32 GB RAM, 100 GB+	Databases, multiple services, higher concurrency
Managed support add-on	Typically ₹1,000 - ₹3,000/mo on top	—	Anyone who doesn't want to own OS patching

These are broad brackets across the market, not a quote - always check a provider's live pricing page for the current number, since these shift with hardware costs, competition and currency over time.

What's Often Left Off the Headline Price

GST. Indian providers billing India-registered customers typically add 18% GST on top of the quoted figure - check whether a price is shown inclusive or exclusive.
Backups. Some providers include automated backups; others charge separately per GB or per snapshot. This one is easy to miss until you actually need to restore something.
Bandwidth overage. Check what happens past the included transfer allowance - metered per GB, throttled, or simply not enforced in practice.
A dedicated IPv4 address. Increasingly billed separately as IPv4 addresses get scarcer; some plans include one, others don't.
Windows Server licensing. A Windows VPS often carries a separate licence cost on top of the base Linux-equivalent price, sometimes bundled free for an introductory period and billed after.

Foreign vs Indian Billing

A number of well-known VPS providers bill in USD even when they have an Indian datacentre region. That means the rupee amount on your card statement moves with the exchange rate month to month, and your bank typically adds a foreign-transaction fee on top - and a USD invoice isn't the document an Indian business needs for GST input credit. If predictable, reconcilable billing matters to your accounting, an India-billed, GST-invoiced provider removes that variable entirely, independent of which one is technically cheaper on paper.

How to Actually Compare Two Quotes

Match vCPU, RAM, disk type and size, and bandwidth allowance side by side before comparing the price - not the plan name. Then add GST if it isn't already included, add managed support if you'll actually need it, and check what a dedicated IP and backups cost if they're not bundled. Two plans that look ₹200 apart on the homepage can end up nearly identical, or wildly different, once all of that is priced in the same way.

A Worked Example

Say you're moving a mid-traffic WordPress store off shared hosting because you keep hitting resource limits during sales. A realistic starting point is 2 vCPU, 4 GB RAM and 50-80 GB of NVMe or SSD disk - enough headroom for WooCommerce plus a page cache without immediately maxing out. In the brackets above that lands in the mid-range tier, typically ₹500-₹2,000 a month before GST. Add managed support if nobody on your team wants to own security patching, and budget separately for backups if they're not included - the total is usually still well under what a single missed sale during downtime would cost, which is the actual comparison worth making.

How the Number Changes as You Grow

Most providers let you resize a VPS upward without migrating to new hardware - more vCPU and RAM at the next pricing step, usually with a reboot rather than real downtime. That means the entry price you start at isn't a ceiling; it's fine to start smaller than you think you'll need and resize once you have real usage data, rather than pre-paying for headroom you're guessing at. The exception is disk: most platforms let disk grow but not shrink, so it's worth sizing that one a little more generously up front.

FAQ

Is cheaper VPS hosting always worse?

Not necessarily - a lower price can reflect genuinely leaner overhead, a smaller resource allocation that's honestly disclosed, or a promotional rate. It's worth being cautious of a price that's dramatically below the market bracket for the specs advertised, since that's more often where a fair-use limit or oversold hardware shows up later.

Does VPS pricing include GST in India?

It depends on the provider - some show GST-inclusive pricing, others show the base price and add 18% GST at checkout. Always check which one you're looking at before comparing two numbers, since an 18% difference easily flips which quote is actually cheaper.

Why do some VPS plans cost more for the same vCPU and RAM?

Usually disk type (NVMe vs SATA SSD), the included bandwidth allowance, whether DDoS protection is bundled or a paid add-on, the region, and whether the price includes managed support. Matching all of those before comparing is the only way the price comparison means anything.

Is billing in USD ever cheaper than billing in INR for an Indian customer?

It can be, depending on the exchange rate at the time and the provider's own pricing - but it adds ongoing currency risk to a recurring bill, and your bank's foreign-transaction fee (commonly 1.5-3.5%) usually eats into any headline saving. It also won't produce the GST invoice an Indian business needs for input credit.

How much does managed support typically add to a VPS price?

It varies by provider and by how much is actually managed, but a flat monthly add-on in the low thousands of rupees is a common range for a standard VPS. Weigh it against the time you'd otherwise spend patching and monitoring the server yourself.

Should I pick the cheapest VPS that meets my minimum specs?

Only after checking bandwidth allowance, backup policy, DDoS protection, and whether support is included - a plan that's cheaper on vCPU/RAM alone can cost more once you add the things a pricier plan bundled in from the start.

Originally published on the Getwebup blog.

This article was created with the help of AI.

ERR_SOCKET_NOT_CONNECTED: Causes and the Fix

Getwebup — Wed, 28 Oct 2026 23:02:08 +0000

ERR_SOCKET_NOT_CONNECTED comes from inside Chrome, not from the network. It means the browser reached for a socket it believed was open, and found it was not - so the request was never sent. Once you know that, the search space collapses to your own machine.

Why this is almost always local

Chrome keeps a pool of open connections and reuses them, which is why a second page on the same site loads faster than the first. If something closes one of those pooled sockets without Chrome noticing - a proxy, an inspecting antivirus, a VPN cycling, or the OS reclaiming it - the next request that picks it up fails at the moment of writing. The server was never contacted, so nothing about the server can explain it.

Confirm it in one step: load the same URL in a different browser. If Firefox or Edge opens it, you are debugging Chrome, not a website.

On a phone (Android or iPhone)

Most people who search this error are on a phone, where the desktop steps further down don't all apply. Same idea, phone version: make Chrome open fresh connections, and take anything that sits between Chrome and the network out of the way. Try these in order and reload after each:

Switch networks for a moment. Turn Wi-Fi off and load the page on mobile data, or the other way round. Or switch airplane mode on for ten seconds and off again. Either way Chrome has to open new connections.
Close Chrome completely, then reopen it. On Android: Settings > Apps > Chrome > Force stop. On iPhone: swipe Chrome away in the app switcher.
Turn off any VPN, ad blocker or "security" app that filters traffic. Many of them work as a VPN on the phone itself. On Android a key icon in the status bar means one is running; on iPhone, look under Settings > VPN. If the page loads with it off, that app is the cause.
Clear Chrome's cached files. In Chrome: menu (⋮) > Settings > Privacy and security > Delete browsing data, tick "Cached images and files" only, and delete.
If it only happens inside another app (a link opened from Instagram, WhatsApp or a shopping app): open the same link in Chrome itself, from that app's menu. If Chrome loads it, update Chrome and, on Android, "Android System WebView" from the Play Store. In-app browsers use WebView.

Still failing on both Wi-Fi and mobile data, with every filtering app off? Then it's worth checking whether the site itself is down. See the one case where it is not local below.

The fixes, in the order worth trying them

1. Flush the socket pools

This directly clears the state the error is about, and it is instant:

chrome://net-internals/#sockets   →  Flush socket pools
chrome://net-internals/#dns       →  Clear host cache

Do both, then reload. For a one-off, this is usually the whole fix.

2. Test in incognito with extensions disabled

Incognito runs without most extensions by default, which makes it a fast test rather than a fix. If the page loads there, an extension is intercepting connections. Ad blockers with network-level filtering, VPN extensions, and privacy tools that route requests are the usual candidates. Re-enable them one at a time to find which.

3. Check the proxy configuration

A stale proxy setting is one of the most common non-obvious causes, particularly a leftover from software that has since been uninstalled. On Windows, look under Settings → Network & Internet → Proxy and turn off both "Automatically detect settings" and any manual proxy you are not deliberately using. On macOS the same lives under Network → Details → Proxies. From a terminal on Windows you can see what is configured with:

netsh winhttp show proxy

and clear it with netsh winhttp reset proxy from an elevated prompt.

4. Look at security software

Antivirus products that scan HTTPS traffic sit between Chrome and the network by design, terminating connections and re-establishing them. When that machinery misbehaves, this error is one of the symptoms. Disable HTTPS or web scanning specifically, rather than the whole product, load the page once, and turn it back on. If that was the cause, add an exception instead of running unprotected.

5. Reset Chrome's network state

If the error persists across restarts, reset the browser's networking configuration. Chrome's settings have a "Restore settings to their original defaults" option that clears the proxy configuration, extensions and cached network state together. Bookmarks and saved passwords are kept.

On Windows it is also worth resetting the OS network stack, which clears Winsock layers that third-party software has inserted:

netsh winsock reset
netsh int ip reset
ipconfig /flushdns

Reboot afterwards - these do not take effect until you do.

The one case where it is not local

If several people on different networks report the same error on the same site at the same time, look at whatever sits in front of the origin. A load balancer or CDN that accepts a connection and then drops it without a response can leave Chrome holding exactly the kind of dead socket that produces this. Test the origin directly to separate the two:

curl -sS -o /dev/null -w '%{http_code}\n' --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com

If the origin answers cleanly and the public hostname does not, the proxy layer is where to look. If both answer, you are back to a client-side cause and the list above applies.

FAQ

How do I fix ERR_SOCKET_NOT_CONNECTED on my phone?

Switch between Wi-Fi and mobile data (or toggle airplane mode), fully close and reopen Chrome, and turn off any VPN, ad-blocking or security app that filters traffic. If the error only appears inside another app's browser, open the link in Chrome and update Chrome and Android System WebView from the Play Store.

Is the website down when I see this?

Almost never. This error is raised inside Chrome's own networking layer when it finds a socket in an unusable state, before or as the request is written. Load the same URL in a different browser - if it works, the site is fine and Chrome's state is the problem.

Why does it only happen in Chrome?

Because it is Chrome's own error string, raised by its socket pooling. Chrome reuses connections aggressively, and a pooled socket that was closed by a proxy or by security software can be picked up and written to before Chrome notices it is dead. Other browsers pool differently and surface the same underlying event as a reset or a generic failure.

Could a proxy setting cause this even if I do not use a proxy?

Yes. A proxy configuration left behind by uninstalled software, or a PAC script that no longer resolves, will silently break connections. Check the system proxy settings and turn off automatic proxy detection, which is a frequent culprit on Windows machines.

I disabled my extensions and it still happens. What next?

Look at software outside the browser: HTTPS-inspecting antivirus, corporate endpoint agents, and VPN clients all intercept connections at the socket level. Disable them one at a time, load the page, and re-enable. If the error stops for one of them, the fix is an exception in that product rather than leaving it off.

Does resetting Chrome's settings fix it?

It often does, because it clears the proxy configuration, extension state and network settings together. Try the targeted steps first - flushing socket pools and testing in incognito - since a full reset also discards things you may want to keep.

Originally published on the Getwebup blog.

This article was created with the help of AI.

Call to Undefined Function in PHP: Enable the Missing Extension

Getwebup — Wed, 28 Oct 2026 23:01:51 +0000

You switch a site to a newer PHP version, or move it to a new host, and a page dies with one line: Call to undefined function. The function isn't misspelled and the plugin worked yesterday. Almost every time, the code is fine and PHP is missing the extension that provides that function - every PHP version keeps its own list of enabled extensions, and the one you just switched to doesn't have it ticked. Here's how to tell which extension it is and switch it on in cPanel, usually in a couple of minutes.

What the error is telling you

The full message names the function and the file that called it:

PHP Fatal error:  Uncaught Error: Call to undefined function mb_strlen() in /home/user/public_html/wp-content/plugins/some-plugin/includes/helpers.php:42

PHP looked for mb_strlen() in everything it has loaded and found nothing. There are only three ways that happens:

The extension that provides it is not enabled for the PHP version your site runs. This is the common case, and the fix is a checkbox.
PHP itself removed the function in the version you moved to - mysql_connect(), each(), create_function() and friends. No extension brings these back; the code has to change.
The function belongs to your code, not to PHP - a plugin calling a helper from another plugin that is disabled, a half-uploaded file, or a typo.

The same problem with a class looks slightly different on PHP 8: Class "ZipArchive" not found or Class "DOMDocument" not found. Treat it exactly the same way.

Step 1: Get the exact function name from the error log

If the page only shows a white screen or "There has been a critical error", the real line is in the log. In cPanel open Metrics → Errors, or open the error_log file in the site's folder with File Manager (see how to find and read error logs in cPanel). Note two things: the function or class name, and the file path - the path tells you which plugin, theme or script made the call.

Step 2: Match the function to its extension

Common functions and classes, and the extension that provides each:

Function or class in the error	Extension to enable
`mb_strlen()`, `mb_substr()`, `mb_strtolower()`	mbstring
`curl_init()`, `curl_exec()`	curl
`imagecreatefromjpeg()`, `imagecreatetruecolor()`, `imagewebp()`	gd
`mysqli_connect()`, `new mysqli`	mysqli (or nd_mysqli)
`new PDO('mysql:...')` failing with "could not find driver"	pdo_mysql (or nd_pdo_mysql)
`simplexml_load_string()`, `simplexml_load_file()`	simplexml
`DOMDocument`	dom
`ZipArchive`	zip
`idn_to_ascii()`, `NumberFormatter`, `grapheme_strlen()`	intl
`bcadd()`, `bcmul()`, `bcdiv()`	bcmath
`iconv()`, `iconv_strlen()`	iconv
`finfo_open()`, `mime_content_type()`	fileinfo
`exif_read_data()`	exif
`sodium_crypto_box()` and other `sodium_*`	sodium
`Imagick`	imagick
`SoapClient`	soap
`apcu_fetch()`, `apcu_store()`	apcu

For anything not in the table, look the function up on php.net: its manual page sits under the extension that provides it. If php.net has no page for it at all, it's not a PHP function - skip to "still undefined" below. Encoded plugins that fail with a message about the ionCube Loader are a separate fix: ionCube Loader errors in cPanel.

Step 3: Check what is loaded for the version your site actually runs

This is where most people lose half an hour. Running php -m over SSH lists the extensions of the command-line PHP, and on cPanel that is often a different version from the one MultiPHP Manager assigns to your domain. It can show mbstring while the website still fails.

The reliable check is from the web side. Create a file with a random name in the site's folder:

<?php phpinfo();

Open it in the browser. The version at the top is the one your site really uses; search the page for the extension name. Delete the file as soon as you're done - it shows server details you don't want public.

If you prefer SSH, call the PHP binary for that exact version instead of plain php:

# CloudLinux servers (alt-php)
/opt/alt/php83/usr/bin/php -m | grep -i mbstring

# Other cPanel servers (EasyApache 4)
/opt/cpanel/ea-php83/root/usr/bin/php -m | grep -i mbstring

Step 4: Enable the extension in cPanel

If your cPanel has "Select PHP Version"

That icon, under Software, means the server runs CloudLinux and you can switch extensions on yourself:

Open Software → Select PHP Version.
Make sure the current version shown is the one your site runs (the phpinfo page from step 3 tells you).
Open the Extensions tab and tick the extension. Newer versions of this screen save as you tick; older ones have a Save button at the bottom.
Reload the page that failed.

Two things trip people up here. First, mysqli and nd_mysqli (and pdo_mysql and nd_pdo_mysql) are two builds of the same functions against different drivers - tick one of each pair, not both, or they conflict. Second, Select PHP Version governs domains that MultiPHP Manager leaves on the server default. If MultiPHP Manager pins your domain to a specific version, the extensions for that domain come from the server's EasyApache 4 build instead, and ticking boxes here changes nothing for it.

If there is no "Select PHP Version"

Then PHP extensions are installed server-wide, as EasyApache 4 packages named like ea-php83-php-mbstring or ea-php83-php-intl. On shared hosting only the host can add them: open a ticket naming the extension and the PHP version, and it's normally a quick job. On your own VPS with WHM you can do it yourself under WHM → EasyApache 4 → Customize → PHP Extensions - see rebuilding PHP with EasyApache 4 without breaking sites.

Functions no extension can bring back

If the function is on this list, PHP removed it. Switching an extension on won't help, because there is no extension:

Function	Removed in	Use instead
`mysql_connect()`, `mysql_query()` and all `mysql_*`	PHP 7.0	mysqli or PDO
`ereg()`, `eregi()`, `split()`	PHP 7.0	`preg_match()`, `preg_split()`
`mcrypt_encrypt()` and all `mcrypt_*`	PHP 7.2	`openssl_encrypt()` or sodium
`each()`	PHP 8.0	`foreach`
`create_function()`	PHP 8.0	an anonymous function
`money_format()`	PHP 8.0	`NumberFormatter` (intl)

The real fix is updating the plugin, theme or script that still calls it - its developer has almost certainly shipped a version without it. If you need the site back right now, switching the domain to its previous PHP version in MultiPHP Manager buys time; just don't stay on an end-of-life PHP. The full approach is in changing your PHP version in cPanel without breaking your site.

WordPress: "missing the MySQL extension"

WordPress has its own wording for one of these. If you see

Your PHP installation appears to be missing the MySQL extension which is required by WordPress.

then the PHP version your site runs has neither mysqli nor nd_mysqli enabled. Tick one of them as in step 4. It usually appears right after a PHP version switch, because each version keeps its own extension list and the new one started without it.

Still undefined after enabling it?

You changed a different version. Recheck with phpinfo: the site may run 8.3 while you ticked the box under 8.2.
The failing code runs from cron or the command line. A cron job calls a PHP binary directly, often /usr/bin/php or /usr/local/bin/php, which can be a different version with its own extensions. Point the cron line at the binary for your site's version, using the paths from step 3.
The function is disabled, not missing. Since PHP 8.0, a function listed in disable_functions is removed outright, so exec(), shell_exec() or proc_open() fail with "Call to undefined function" instead of PHP 7's "has been disabled for security reasons". Shared hosts commonly disable these. Search the phpinfo page for disable_functions; if yours is listed, ask your host, or run that job somewhere you control the php.ini.
It isn't a PHP function at all. Functions like wc_get_product() or get_field() come from plugins (WooCommerce, ACF). The error means that plugin is inactive, half-updated or loaded too late. Reinstall it and check that the plugin calling it is compatible with its current version.

FAQ

What does "Call to undefined function" mean in PHP?

PHP could not find a function by that name in anything it has loaded. Usually the extension that provides it is not enabled for the PHP version the site runs; less often the function was removed from PHP, or it belongs to a plugin or library that did not load.

How do I enable a PHP extension in cPanel?

If cPanel has Software > Select PHP Version, open it, check the version matches your site, and tick the extension on the Extensions tab. Without that screen, extensions are installed server-wide through EasyApache 4, so on shared hosting you ask your host to add it.

How do I fix "Call to undefined function mysql_connect()"?

The mysql_* functions were removed in PHP 7.0 and no extension restores them on a supported PHP version. Update the script or plugin to one that uses mysqli or PDO; switching back to an old PHP version only buys time.

Why does my script work in the browser but fail from a cron job?

Cron calls a PHP binary directly, often /usr/bin/php, which can be a different version with its own extension list. Point the cron command at the binary for the version your site uses, such as /opt/alt/php83/usr/bin/php on CloudLinux.

Why does exec() give "Call to undefined function" on PHP 8?

Since PHP 8.0, functions listed in disable_functions are removed entirely, so calling one reports it as undefined instead of "disabled for security reasons". Check disable_functions in phpinfo(); shared hosts commonly disable exec, shell_exec and proc_open.

Originally published on the Getwebup blog.

This article was created with the help of AI.

PHP2Shell (CVE-2026-109618 and CVE-2026-109619): Check and Patch PHP in cPanel

Getwebup — Wed, 28 Oct 2026 23:01:33 +0000

On 21 October 2026 the PHP project shipped emergency releases for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619 - the pair security researchers now call PHP2Shell. Both are rated 9.2 out of 10, neither needs a login, and attacks were reported from the day the fix came out. The bug is in PHP itself, not in your site: updating WordPress, a plugin or a theme does nothing for it. Here's what is affected, how to check the PHP your site really runs in cPanel, and what to do if it isn't patched.

What PHP2Shell is

Two separate bugs in how PHP sets up and tears down a request:

CVE-2026-109618 - "RCE via OOM corruption". If PHP runs out of memory at the wrong moment while preparing a request, internal data is left half-built, and the cleanup code afterwards treats it as valid.
CVE-2026-109619 - "RCE via stale global state". Data belonging to one request can survive after its memory has been freed, and the next request handled by the same PHP worker can use it.

Both can end in an attacker running their own code on the server. The PHP team puts the risk on "all PHP installations serving web requests": PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP. Apache mod_php is the most urgent, because a working exploit there fires before your application's code even runs. Researchers also showed unauthenticated reads of PHP worker memory, which can expose database passwords and API keys.

On 26 October 2026 CISA added both CVEs to its Known Exploited Vulnerabilities catalog, with 29 October as the due date for US federal civilian agencies.

Which versions are fixed

PHP branch	Fixed in	Note
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	End of life on 31 December 2026
8.1, 8.0, 7.4	No official release	Minimal source backports from the PHP security team, and patched builds from hosts and distributions that usually keep the old version number
7.3 and older	No fix from PHP or cPanel	Some vendors (CloudLinux, Ubuntu Pro, TuxCare ELS) ship backports; otherwise upgrade to a supported branch

Step 1: Check the PHP your site actually runs

In cPanel, Software → MultiPHP Manager shows the branch each domain uses, such as PHP 8.3. The exact patch level is the whole question here, and two quick ways show it:

A temporary phpinfo page. Create a file with a random name in the site's folder containing <?php phpinfo();, open it in the browser and read the version at the top, then delete the file.
The response header, if your server sends it:

curl -sI https://example.com/ | grep -i x-powered-by
x-powered-by: PHP/8.4.27

Don't go by php -v over SSH: on cPanel the command-line PHP is often a different version from the one serving the website.

On 8.2 to 8.5, compare the number with the table: anything lower is unpatched, unless your host or Linux distribution backported the fix without changing the number - some do, so check their security advisory before assuming the worst. On 8.1, 8.0 or 7.4 the number can't tell you anything - a fixed 8.1 build still says 8.1.34 - so only your host can confirm it, and the lasting fix is moving to a supported branch.

Step 2: On shared or reseller hosting, patching is your host's job

You can't update PHP on a shared server; the host updates the packages for everyone. What you can do:

Ask directly: "Have the PHP builds on my server been updated for CVE-2026-109618 and CVE-2026-109619, including the 7.4, 8.0 and 8.1 builds?"
Move off 8.1 or older. Switching the domain to 8.3 or 8.4 in MultiPHP Manager puts you on a branch that gets official fixes. Test first - see changing your PHP version in cPanel without breaking your site.

The stopgap settings below don't help much from a cPanel account either: PHP's advisory says they must be set in the server's configuration, not through ini_set() or a .user.ini file, which is where account-level PHP settings usually end up.

Step 3: On your own VPS or dedicated server

cPanel with EasyApache 4 (ea-php)

dnf update 'ea-php*'        # yum on older systems
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd

Run the plain update, not a security-only one: these packages shipped before their advisory metadata, so --security updates can skip them. To confirm a build has the fix, its changelog should name both CVEs:

rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'

Also update cPanel & WHM itself, which runs its own PHP for the cPanel interfaces and Roundcube webmail. Builds 138.0.18, 136.0.50 and 134.0.66 or later ship PHP 8.4.27 there, and 110.0.153 backports the fix to PHP 8.1.34.

CloudLinux (alt-php)

dnf clean all && dnf upgrade 'alt-php*'    # CloudLinux 8, 9 and 10
yum clean all && yum update 'alt-php*'     # CloudLinux 7
rpm -q --changelog alt-php81-common | grep -E 'CVE-2026-(109618|109619)'

This is the way to check the 7.4, 8.0 and 8.1 builds, whose version numbers don't change. If you added the TuxCare ELS alt-php repository (php-els), keep it enabled. If you disabled it, enable it again. On CloudLinux 10 it is the only source of alt-php versions other than 5.2. Fixed alt-php for CloudLinux 6 is not confirmed yet.

LiteSpeed

On cPanel, LiteSpeed runs sites through lsphp built from the same ea-php or alt-php packages, so the updates above cover it. Restarting LiteSpeed does not restart lsphp: since LiteSpeed 5.3, PHP runs in detached mode. Restart the lsphp processes yourself, either all at once or one by one as each is next used:

pkill lsphp                                          # all at once
touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt   # or one by one

Update LiteSpeed itself too - its WebAdmin console carries its own PHP binary. LiteSpeed's changelog lists the fix in 6.3.7 build 5 (22 October) and later, and in 6.4 RC2 build 3. To update to the latest 6.3.7 build:

/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7

Whatever the setup, restart every PHP worker after updating. A patched package on disk does nothing for an FPM pool or lsphp process still running the old binary.

If you can't patch today

PHP's advisory lists measures that reduce exposure. In its words they "do not make an installation safe" - they buy time until the update:

session.upload_progress.enabled = 0 in the server's php.ini or FPM pool, then restart the workers. This closes the path the public exploit for CVE-2026-109619 uses. PHP now also suggests keeping it at 0 after you update, until its next regular release, because of a further, unlikely RCE path (CVE-2026-115560).
For CVE-2026-109618: memory_limit = -1 set with php_admin_value so applications can't override it (temporary - it removes the per-request memory cap), and a low post_max_size - 8M if the site takes no uploads, 32M if it does - with upload_max_filesize below it.
On PHP 8.5, fatal_error_backtraces = 0.
If the server runs Imunify360 with its WAF enabled: CloudLinux says rulesets 8.83 to 8.88 block the known exploit requests and the public exploit tool, so check that 8.88 or later has arrived. On LiteSpeed, blocking starts with 8.84. A request made to look like a normal upload from the site's own pages may not match, and nothing blocks the out-of-memory path of CVE-2026-109618 yet. The update is still the fix.

Was the site hit before it was patched?

If a site ran unpatched PHP on or after 17 October - the day of the earliest exploit attempt Amazon reported, four days before the fix - spend ten minutes checking:

PHP files modified since 17 October: find ~/public_html -name '*.php' -newermt 2026-10-17. Your own updates will show up; anything you don't recognise is worth a look.
Any .php file inside wp-content/uploads. There should be none.
New administrator accounts in WordPress, and unfamiliar entries under cPanel → Cron Jobs.

Because worker memory could leak, change the database password, admin passwords and any API keys the site holds once PHP is patched. If you do find something, follow cleaning up a hacked WordPress site.

Sources: PHP security advisory, 21 October 2026; GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp; CloudLinux package status and Imunify360 protection.

FAQ

What is PHP2Shell?

PHP2Shell is the name researchers gave two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Both can let an unauthenticated attacker run code on a server through PHP-FPM, Apache mod_php, php-cgi, LiteSpeed or FrankenPHP.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1, 8.0 and 7.4 get no official release: the PHP security team published minimal source backports, and hosts and distributions ship patched builds that usually keep the old version number. PHP 7.3 and older get no fix from PHP or cPanel. Some vendors, such as CloudLinux, Ubuntu Pro and TuxCare ELS, ship backports; otherwise, upgrade.

Do I need to update WordPress for PHP2Shell?

No. The vulnerabilities are in PHP itself, so WordPress core, plugins and themes are not where the fix goes. The server's PHP has to be updated, which on shared hosting your host does.

My site runs PHP 8.1 or 7.4. Is it protected?

Only if your host installed a backported build, and the version number won't show it: a fixed 8.1 build still reports 8.1.34. Ask your host, and plan to move the site to PHP 8.3 or 8.4, which receive official fixes.

Does turning off session.upload_progress fix PHP2Shell?

No. Setting session.upload_progress.enabled to 0 server-wide closes the path the public exploit for CVE-2026-109619 uses, but it does nothing for CVE-2026-109618. PHP's advisory says only the update is a complete fix. PHP now also suggests keeping it at 0 after you update, until its next regular release, because of a further, unlikely RCE path (CVE-2026-115560).

Originally published on the Getwebup blog.

This article was created with the help of AI.

WordPress Site Health Warnings: What to Fix and What to Skip

Getwebup — Wed, 28 Oct 2026 18:35:23 +0000

Open Tools → Site Health in any WordPress dashboard and you'll usually get a mix of green checkmarks and a handful of warnings that sound alarming but rarely explain themselves. "Your site could not complete a loopback request." "The REST API encountered an error." Most site owners either panic and start deactivating plugins at random, or ignore the screen entirely and miss a real problem. Neither is the right move. Here's what each common warning actually means on a cPanel-hosted WordPress site, and how to fix the ones worth fixing.

What Site Health Is Actually Checking

Site Health runs a set of tests against your live install: can WordPress talk to itself over HTTP, is the REST API reachable, are scheduled events (wp-cron) firing, is your PHP version current, are there unused themes and plugins sitting around as an attack surface. It splits results into "Critical" and "Recommended" — the naming matters less than understanding why a test failed, because a few of these will show a warning on a perfectly healthy site.

Critical Issues You Should Actually Fix

"Your site could not complete a loopback request"

A loopback request is WordPress calling its own URL from the server side — it's how cron, plugin updates, and the block editor's preview work. When this fails, it's almost always one of three things:

A security plugin or ModSecurity rule is blocking the server's own IP. Wordfence, Sucuri, and All In One WP Security all have a habit of firewalling localhost/127.0.0.1 or the server's own outbound requests when a rule is too aggressive. Check the plugin's firewall log for a blocked request to your own domain.
DNS isn't resolving locally. If you've moved the site and the VPS or shared server still resolves the domain to an old IP internally, the loopback goes nowhere. Test it directly from cPanel Terminal or SSH:

curl -I https://yourdomain.com/wp-cron.php?doing_wp_cron

If that hangs or times out, the server can't reach itself over that hostname — check /etc/hosts on a VPS, or confirm the domain's A record actually points at this server.

A wildcard .htaccess block or IP allowlist is too strict. Rules that whitelist only office or home IPs for wp-admin will also block the server's own loopback call if they cover wp-cron.php or REST routes. Scope those rules to /wp-admin/ only, not the whole site.

"The REST API encountered an error"

This one breaks the block editor, most contact forms, and some page builders. Test it directly:

curl https://yourdomain.com/wp-json/

If you get a 403, ModSecurity or a firewall rule is the usual culprit — check cPanel → Security → ModSecurity for a triggered rule ID against /wp-json/ and whitelist it for that path rather than disabling ModSecurity site-wide. If you get a 500 or a blank response, it's almost always a plugin hooking into rest_api_init and throwing a fatal error — deactivate plugins one at a time (or use wp plugin deactivate --all via WP-CLI, then reactivate individually) and re-test after each.

If the response is valid JSON but permalinks are set to "Plain," switch to any pretty permalink structure under Settings → Permalinks and re-save — the REST API needs rewrite rules to route correctly.

"WordPress.com requests to your site are being blocked"

This warning doesn't come from WordPress itself. It's Jetpack's, and the admin notice reads in full: "WordPress.com requests to your site are being blocked, usually by a firewall or security rule. See Site Health for details and next steps." Next to it is a Visit Site Health button.

Jetpack's connection runs both ways: your site calls WordPress.com, and WordPress.com calls back to your site's xmlrpc.php file. This notice means the call back was refused — WordPress.com reached your server and something turned it away. Site Health's Jetpack test shows the status code your site sent back, for example "WordPress.com reached your site but the request was blocked (HTTP 403)".

Two things follow. The connection itself can be perfectly fine, and reconnecting Jetpack won't fix it, because the same rule blocks the reconnect — Jetpack's own Site Health text says so. What needs fixing is whatever blocks xmlrpc.php. On cPanel hosting it is almost always one of these:

An XML-RPC block you added deliberately. An .htaccess rule, a "disable XML-RPC" plugin, or a security plugin's XML-RPC toggle — the standard defence against XML-RPC brute-force attacks. It shuts out WordPress.com along with the attackers.
A firewall in front of the site. A Cloudflare WAF, rate-limiting or bot-protection rule, or a ModSecurity rule on the server, answering WordPress.com with a 403.
A server firewall on a VPS. CSF or another IP firewall that has blocked one of WordPress.com's addresses.

Start by checking what xmlrpc.php returns from outside the server:

curl -i https://yourdomain.com/xmlrpc.php

A reachable file answers a plain GET with 405 Method Not Allowed and the line "XML-RPC server accepts POST requests only." That is the healthy result. A 403, a Cloudflare challenge page or a redirect means something in front of WordPress is refusing it. To send a real XML-RPC call:

curl -s -X POST -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>demo.sayHello</methodName></methodCall>' \
  https://yourdomain.com/xmlrpc.php

A working endpoint replies with Hello! inside an XML response. If both tests pass from your computer but the warning stays, the block is aimed at WordPress.com in particular, by IP address or as a bot. Look for refused requests to /xmlrpc.php in the firewall's own log: Cloudflare's security events, the ModSecurity hits in WHM (or ask your host), or your security plugin's log.

Don't fix it by opening xmlrpc.php to everyone again. Either let only Jetpack's IP ranges through the rule — Jetpack publishes them on its "Add Jetpack IPs to an Allowlist" support page, with a plain-text copy at jetpack.com/ips-v4.txt — or keep XML-RPC on and block only the system.multicall method that brute-force tools lean on. Once WordPress.com gets through, the notice clears on its own: Jetpack re-runs the check whenever you open Site Health, and once a day in the background.

"Scheduled events have failed" / background updates not working

This means wp-cron isn't firing, which means scheduled posts, plugin update checks, and backup jobs silently stop running. On low-traffic sites this is common because WordPress's default cron only fires on a page visit. Check what's actually queued:

wp cron event list --fields=hook,next_run_relative,recurrence

If events are piling up with negative "next run" times, disable the request-triggered cron in wp-config.php and replace it with a real system cron job through cPanel:

define('DISABLE_WP_CRON', true);

Then add this in cPanel → Cron Jobs, running every 5 minutes:

wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

This is more reliable than page-load-triggered cron and won't slow down visitor requests.

Recommended Warnings — Which Ones Actually Matter

Warning	What it means	Worth fixing?
"Not using HTTPS for all resources" (mixed content)	Images, scripts, or CSS still loading over `http://` after an SSL move	Yes — run a serialized-safe search-replace: `wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables`
"You should remove inactive plugins and themes"	Deactivated code still sitting on disk	Yes — unused code is still a scan target for malware and a source of stale vulnerabilities
"A persistent object cache should be used"	No Redis/Memcached backend configured	Only if the site is busy enough to need it — skip on a low-traffic brochure site
"PHP version is outdated"	Site running EOL PHP (7.4 and earlier)	Yes, always — change it in `cPanel → MultiPHP Manager` and test the site after
"Your site has a security vulnerability" (specific plugin)	A known CVE affects an installed plugin version	Yes, immediately — update or remove that plugin the same day
"This plugin has not been updated in over 2 years"	Abandonware flag, not necessarily broken	Only investigate if it also has open security reports

When It's Safe to Ignore a Warning

Some Site Health notices are noise. A shared hosting environment you don't control the server config for will sometimes flag "recommended PHP modules" that your host has intentionally left off for security reasons, or a caching-plugin conflict that Site Health can't detect correctly. If a warning has stayed the same for months, the site performs fine, and there's no matching entry in your error log, it's reasonable to leave it. The ones to never ignore are the "Critical" tab and anything mentioning a security vulnerability by name.

Prevention: Keep the Screen Green

Delete inactive themes and plugins as soon as you're sure you don't need them — don't just deactivate and forget.
Scope IP-restriction and security-plugin firewall rules to specific paths (/wp-admin/, /wp-login.php) instead of the whole domain, so they don't catch loopback and REST calls.
Move wp-cron to a real system cron job on any site that gets irregular traffic.
Check Site Health after every major plugin or PHP version change — it catches breakage before visitors do.

Bottom Line

Site Health isn't a scorecard to chase 100% green on — it's a diagnostic tool. Treat the Critical tab as things to fix this week, treat plugin-vulnerability warnings as fix-today, and treat the rest as context you check against your actual error logs before acting on.

FAQ

Why does Site Health say my site can't complete a loopback request even though the site loads fine for visitors?

Loopback requests are the server calling its own domain internally, which is a different path than a visitor's browser request. A security plugin firewall rule, a stale internal DNS resolution, or an IP-restriction rule scoped too broadly are the usual causes - test with curl -I https://yourdomain.com/wp-cron.php?doing_wp_cron from SSH or cPanel Terminal to see the actual error.

Is it safe to just ignore Site Health warnings if the site works fine?

Recommended-tab warnings like unused themes or missing object caching are often safe to leave if you understand why they're there. Critical-tab warnings and anything naming a specific plugin vulnerability should never be ignored, even if nothing looks broken yet.

How do I fix 'The REST API encountered an error' on cPanel hosting?

Run curl https://yourdomain.com/wp-json/ to see the actual response. A 403 usually means ModSecurity is blocking the request - check WHM/cPanel's ModSecurity Audit Log for the rule ID and whitelist it for that path. A 500 or blank response usually means a plugin is fatal-erroring on the rest_api_init hook - deactivate plugins one at a time to isolate it.

Why do scheduled posts stop publishing even though wp-cron looks configured?

WordPress's default cron only fires when someone visits the site, so low-traffic sites can miss scheduled runs entirely. Disable it with define('DISABLE_WP_CRON', true); in wp-config.php and replace it with a real cPanel cron job hitting wp-cron.php every 5 minutes.

Does switching PHP versions fix the 'PHP version outdated' Site Health warning immediately?

Yes, once you change it under cPanel's MultiPHP Manager the warning clears right away. Test the site immediately after switching, since older plugins or themes can throw fatal errors on a newer PHP version - keep a backup or staging copy ready before changing production.

What does "WordPress.com requests to your site are being blocked" mean?

It's a Jetpack notice. WordPress.com tried to call your site's xmlrpc.php file and your site refused, usually because of an XML-RPC block, a Cloudflare or ModSecurity rule, or a security plugin. Reconnecting Jetpack won't fix it. Let Jetpack's published IP ranges through the rule, or block only the system.multicall method instead of all of XML-RPC, then reopen Tools → Site Health. The notice clears once WordPress.com gets through.

Originally published on the Getwebup blog.

This article was created with the help of AI.

MySQL max_user_connections Error: Causes and the Fix

Getwebup — Wed, 28 Oct 2026 18:35:05 +0000

Your site throws "Error establishing a database connection," but when you check the MySQL error log or a debug query, the real message is ERROR 1226 (42000): User 'dbuser' has exceeded the 'max_user_connections' resource (current value: 20). If that looks familiar, you're not hitting a server-wide MySQL limit — you're hitting a per-account cap, and the fix is completely different from the usual "raise max_connections" advice.

What max_user_connections actually is

MySQL has two separate connection ceilings, and mixing them up wastes a lot of troubleshooting time:

Limit	Scope	Who sets it	Typical error
`max_connections`	Whole MySQL server, all users combined	Server admin, in `my.cnf`	`ERROR 1040: Too many connections`
`max_user_connections`	One specific database user only	Per-account grant, or a WHM/cPanel resource limit	`ERROR 1226: User has exceeded the 'max_user_connections' resource`

On shared cPanel hosting, every account usually gets its own database user with its own cap on simultaneous connections — often somewhere between 10 and 25, depending on the plan. The rest of the server can be sitting nearly idle and you'll still get locked out the moment your site alone opens more connections than your account is allowed.

Reading the error, word by word

The full message usually looks like one of these:

ERROR 1226 (42000): User 'dbuser' has exceeded the 'max_user_connections' resource (current value: 80)
could not connect to the database 3306. user 'dbuser' has exceeded the 'max_user_connections' resource (current value: 80)

1226 is MySQL's error number for a per-user resource limit being hit. It is not a password or permissions problem.
user 'dbuser' is the database user your site logs in as, from wp-config.php or your app's config. Only that user is being refused; other sites on the same server keep working.
(current value: 80) is the limit itself, not the number of connections open right now. This user may hold at most 80 connections at once, and a new one was refused because all 80 were in use.
could not connect to the database 3306 is your application's own wording around the same MySQL error; 3306 is simply the port MySQL listens on. The cause and the fix are the same as for the plain 1226 message.

Why it happens

Traffic burst on a low-limit plan

A sale, a newsletter blast, or a bot crawl can spin up more concurrent PHP processes than usual. Each one opens its own MySQL connection, and on a plan capped at 15–20 connections per user, that's not much headroom. Entry-level shared hosting plans are sized for typical traffic, not spikes, precisely because most accounts on the server never come close to their cap — until one day yours does.

Connections that don't close cleanly

Persistent connections (mysqli_connect with the p: prefix, or some poorly written plugins) can hang around longer than they should. So can PHP-FPM workers that stay busy on a slow page and hold their DB connection the whole time. A single slow query — an unindexed WooCommerce lookup, say — can tie up a connection for seconds instead of milliseconds, and if enough requests pile up behind it, you run out of slots even though total traffic looks unremarkable in your analytics.

Multiple sites sharing one database user

If you've pointed two or three WordPress installs at the same MySQL user to save on account limits, their connection counts stack. One site's traffic spike can lock out the others.

A runaway cron job or import script

WP-CLI loops, migration scripts, or a cron job that fires every minute and doesn't release its connection properly will quietly eat your quota in the background, so the error shows up even during low traffic.

Confirm it's really this, not the server-wide limit

Don't guess — check. If you have SSH or Terminal access in cPanel:

mysql -u your_db_user -p -e "SHOW VARIABLES LIKE 'max_user_connections';"
mysql -u your_db_user -p -e "SELECT COUNT(*) FROM information_schema.processlist WHERE user='your_db_user';"

If the second number is sitting right at or above the first, that's your answer. On shared hosting without shell access, check cPanel → MySQL Databases or the resource usage panel — some hosts surface the current connection count there, or you can just check the exact wording of the error your site is throwing. "max_user_connections" in the message means per-user, not server-wide.

See what the open connections are doing

Knowing the count is at the limit is only half the answer. This groups the connections by what they are doing, so the pattern is obvious:

SELECT command, state, COUNT(*) AS connections, MAX(time) AS longest_seconds
FROM information_schema.processlist
WHERE user = 'your_db_user'
GROUP BY command, state
ORDER BY connections DESC;

A database user can always see its own connections, so this also works from phpMyAdmin's SQL tab on shared hosting. If the limit is so full that even this query can't connect, run it as root on a VPS (root sees every user's connections) or retry in a few seconds.

Mostly Sleep, with a large longest_seconds: connections are opened and never closed — persistent connections, or code that doesn't close them. See "Fix what's actually eating connections" below.
Mostly Query, several seconds each: slow queries are piling up and holding connections while they run. Find them with the MySQL slow query log.
A steady count at the limit whenever traffic rises: more PHP workers than the limit allows. Tune the PHP-FPM pool to match.

For immediate relief you can close your own idle connections with KILL <id>;, taking the IDs from SHOW PROCESSLIST;. That frees slots at once, but they fill up again until the cause is fixed.

How to fix it

On shared cPanel hosting (no root access)

You can't edit my.cnf here — the limit is enforced by the hosting account's resource package. Two real options:

Ask your host to raise the per-account MySQL connection limit.
Reduce how many connections your site opens at once — see the fixes below before assuming you need a bigger limit.

On a VPS or dedicated server with root MySQL access

You can set the per-user limit directly:

ALTER USER 'your_db_user'@'localhost' WITH MAX_USER_CONNECTIONS 50;
FLUSH PRIVILEGES;

On older MySQL/MariaDB versions where ALTER USER ... WITH isn't supported, use:

GRANT USAGE ON your_database.* TO 'your_db_user'@'localhost' WITH MAX_USER_CONNECTIONS 50;

Set it high enough to cover real peak traffic, but remember it's still bounded by the server-wide max_connections — raising one without checking the other just moves the wall.

Fix what's actually eating connections

Raising the cap buys time; it doesn't fix a leak. Check these first:

PHP-FPM pool size. If pm.max_children in your PHP-FPM pool config is set much higher than your MySQL user's connection limit, every busy moment will hit the wall. Bring them in line.
Persistent connections. If a plugin or custom code uses mysqli_pconnect or PDO persistent mode, connections can sit open between requests. Turning persistent connections off usually clears this up fast.
Object caching. A Redis or Memcached object cache in front of WordPress cuts the number of database round-trips per page load significantly, which lowers concurrent connection pressure during traffic spikes.
Cron and import scripts. Make sure long-running WP-CLI or migration scripts explicitly close their MySQL connection when done, and don't schedule the same heavy cron job to overlap itself.

Prevention checklist

Give each site its own database user instead of sharing one across multiple installs.
Match your PHP-FPM pm.max_children to what your MySQL connection limit can actually support.
Add an object cache (Redis or Memcached) if your site does more than a trickle of traffic.
Monitor connection counts before a planned traffic event — a sale, a launch, a press mention — and ask your host to raise the limit in advance rather than mid-outage.
Avoid persistent MySQL connections unless you've specifically tuned your stack for them.

If you keep hitting this ceiling even after cleaning up connection usage, it's usually a sign your plan's resource limits no longer match your traffic — worth a quick chat with your host before it becomes a recurring outage.

FAQ

What's the difference between max_connections and max_user_connections?

max_connections is a server-wide MySQL setting that caps total connections from every user combined. max_user_connections caps connections from one specific database user, regardless of how busy the rest of the server is. On shared cPanel hosting, you'll usually hit the per-user limit long before the server-wide one.

Can I fix this myself on shared hosting?

You can't edit the limit directly without root access, but you can reduce how many connections your site opens at once by tuning PHP-FPM, disabling persistent connections, and adding an object cache. If that's not enough, ask your host to raise the per-account limit.

Will restarting MySQL fix it?

It clears the immediate backlog by closing all open connections, but it's a temporary fix. If the underlying cause — a leak, an undersized limit, or an overlapping cron job — isn't addressed, the error comes back.

Does WordPress show a specific error for this, or just the generic database message?

WordPress shows the same generic 'Error establishing a database connection' screen regardless of the cause. You have to check the MySQL error log, enable WP_DEBUG, or query the database directly to see the actual max_user_connections message.

How do I know what limit my hosting plan gives me?

Run SHOW VARIABLES LIKE 'max_user_connections'; against your database user if you have any command-line or phpMyAdmin SQL access. If you can't run queries, check your hosting plan's resource limits page or ask support directly.

What does 'current value: 80' mean in the max_user_connections error?

It is the limit, not the live count. The database user may hold at most 80 connections at the same time, and the error appears when one more is attempted. On shared hosting your host sets that number.

Why does the error start with 'could not connect to the database 3306'?

That part is your application's own message, and 3306 is the port MySQL listens on. Underneath it is the same MySQL error 1226, so the cause (too many open connections for one database user) and the fix are the same.

Originally published on the Getwebup blog.

This article was created with the help of AI.

Cloudflare Turnstile Not Working in WordPress? Here's the Fix

Getwebup — Wed, 28 Oct 2026 18:34:37 +0000

You swapped out reCAPTCHA for Cloudflare Turnstile because it's faster, free, and doesn't track your visitors — and now the widget won't load, or it loads but every form submission comes back "verification failed." Here's how to actually fix it, not just refresh the page and hope.

Why site owners are moving to Turnstile

Google reCAPTCHA works, but it ships third-party tracking cookies, occasionally shows an infinite loop of traffic-light photos to real customers, and adds a noticeable delay before your contact form is usable. Cloudflare Turnstile solves the same problem — tell bots from humans — without the cookie banner headache or the "select all the crosswalks" tax on your visitors. Most of the time it runs an invisible, non-interactive check and just passes.

The catch: because it verifies the visitor's browser and the exact domain it's embedded on, a handful of setup details will silently break it. Below are the most common ones.

Symptom 1: The widget never appears

You add the shortcode or plugin block, save the page, and where the checkbox or Cloudflare badge should be, there's just... nothing. No error in the form, no console warning you'd notice at a glance.

Cause

The Turnstile JavaScript (https://challenges.cloudflare.com/turnstile/v0/api.js) is being blocked by a caching or "defer non-essential JS" plugin like WP Rocket, LiteSpeed Cache, or Autoptimize.
A Content Security Policy header (set in .htaccess or a security plugin) doesn't allow scripts from challenges.cloudflare.com.
The site key was pasted with a stray space or line break.

Fix

Open your browser's DevTools console (F12) on the page with the form. If you see a CSP violation error naming challenges.cloudflare.com, that confirms cause #2.
If you're using a CSP header, add this to your script-src and frame-src directives:

script-src 'self' https://challenges.cloudflare.com;
frame-src 'self' https://challenges.cloudflare.com;

Exclude the Turnstile script from JS defer/delay optimisation. In WP Rocket: Settings → File Optimization → Excluded JavaScript Files, add challenges.cloudflare.com. In LiteSpeed Cache: Page Optimization → JS Settings → JS Excludes.
Re-copy your site key from the Cloudflare dashboard (Turnstile → your widget → Sitekey) and paste it into a plain-text editor first to strip formatting, then into your plugin settings.

Symptom 2: Widget shows, but every submission fails with "verification failed"

The checkbox or badge renders fine. The visitor completes it (or it auto-passes). They click submit, and the form bounces back with a generic error, or the WordPress error log shows something like cf-turnstile-response missing or invalid-input-response.

Cause

This is almost always a mismatch between the site key (public, goes in your HTML) and the secret key (private, used server-side to verify the token with Cloudflare's API). Common ways this happens:

You pasted the secret key into the site key field, or vice versa — they look similar and it's an easy copy-paste mistake.
You have a staging and a production Turnstile widget, and the keys got swapped during deployment.
Your server can't reach Cloudflare's verification endpoint (https://challenges.cloudflare.com/turnstile/v0/siteverify) — outbound HTTPS is blocked by a firewall rule, mod_security, or an aggressive VPS security group.
A caching plugin is caching the form page including the one-time Turnstile token, so the visitor submits a token that already expired (tokens are valid for roughly 5 minutes and are single-use).

Fix

In the Cloudflare dashboard, go to Turnstile and confirm which key is which — the sitekey is the one you never treat as secret. Re-check both fields in your plugin.
Test outbound connectivity from your server directly:

curl -I https://challenges.cloudflare.com/turnstile/v0/siteverify

If this times out or connection-refuses, your hosting firewall (CSF, ModSecurity, or a VPS security group) is blocking outbound HTTPS to that host. On a cPanel/CSF server, whitelist the outbound connection in /etc/csf/csf.conf or ask your host to confirm outbound 443 isn't restricted.

Exclude the page containing your form from full-page caching, or at minimum exclude any URL parameter/cookie the form plugin sets. Most contact-form plugins (Contact Form 7, WPForms, Gravity Forms) already send no-cache headers on their own AJAX endpoint — check that your caching plugin isn't overriding that.
If you run WooCommerce checkout or a login form behind Turnstile, make sure the widget re-renders after AJAX page updates (cart totals refresh, etc.) — a stale token from before the AJAX reload will always fail.

Symptom 3: Works on staging, fails on the live domain

You tested everything on staging.yoursite.com, it passed every time. You push to production and it breaks immediately.

Cause

Turnstile widgets are locked to the exact hostnames you list when you create them in the Cloudflare dashboard. If your production domain, its www variant, or your staging subdomain isn't in that list, verification fails with a domain mismatch — Cloudflare's API rejects it silently from the form's point of view.

Fix

In Cloudflare → Turnstile → your widget → Settings, check the "Domains" list. Add every hostname the form is actually served from:

Hostname you need to add	Why
yourdomain.com	Root domain
www.yourdomain.com	www redirect target, if visitors land here first
staging.yourdomain.com	Staging/testing environment
localhost / 127.0.0.1	Local development — Turnstile has a dedicated toggle for this

Changes to the domain list apply within a minute or two — no need to regenerate the keys.

Symptom 4: Turnstile passes, but the form still submits nothing (WPForms/CF7)

This one isn't a Turnstile problem at all — it's a plugin integration gap. Some older versions of popular form plugins added Turnstile support after reCAPTCHA, and the field name they expect doesn't match what a hand-rolled integration sends.

Fix

Update the form plugin to the latest version — Turnstile support in Contact Form 7, WPForms, and Gravity Forms has matured a lot since first release and early versions had known bugs here.
If you added Turnstile manually via a snippet, confirm the hidden field name is exactly cf-turnstile-response — this is what the server-side verification call reads.
Check wp-content/debug.log (with WP_DEBUG_LOG enabled) for a PHP notice about an undefined index — that usually points straight at the mismatched field name.

Symptom 5: "Invalid request: missing Turnstile response"

This is a different failure from "verification failed." When the error says the Turnstile response is missing, no token reached your server at all — the cf-turnstile-response field was absent or empty in the submission. Cloudflare's own verification API reports the same condition as missing-input-response: "Response parameter was not provided." Your keys can be perfectly correct and this will still fail, because the problem is in the browser or the form.

Cause

The widget sits outside the <form> it's meant to protect — in a popup, a separate page-builder block, or the footer. Turnstile's hidden cf-turnstile-response field is only sent with a form when the widget is embedded inside that <form> element; outside it, the challenge passes and the form still submits without a token.
The form submits over AJAX, and the JavaScript that builds the request never adds the token. With explicit rendering you have to read it yourself with turnstile.getResponse(widgetId) and include it.
The visitor pressed submit before the widget had finished loading, because the Turnstile script is being delayed or deferred by an optimisation plugin (see Symptom 1).

Fix

Open DevTools → Network, submit the form, and look at the request payload. No cf-turnstile-response field, or an empty one, confirms it: the token never left the browser.
Move the widget's container inside the <form> element it protects.
For AJAX or custom forms, get the token with turnstile.getResponse(widgetId) and send it as cf-turnstile-response alongside the other fields.
Exclude challenges.cloudflare.com from JS delay and defer, so the widget has rendered before anyone can submit.

Turnstile error messages, decoded

Most people land here with an exact error string. Each one below points to a different link in the chain: the browser never produced a token, the token never reached your server, or your server sent it to Cloudflare and was told no. Find your message, then jump to the matching fix above.

Error message	What it means	Fix
"Turnstile verification failed", `turnstile_verification_failed`, "Incorrect Turnstile response. Try the verification again."	A token reached your server, your server sent it to Cloudflare's siteverify API, and Cloudflare answered `"success": false`.	Symptom 2 — a key mismatch, blocked outbound HTTPS, or an expired or reused token.
"Invalid Turnstile response", `invalid-input-response`	Cloudflare received a token, but it isn't valid: malformed, expired, or issued by a different widget from the one your secret key belongs to.	Symptom 2, step 1 — check that the site key and the secret key come from the same widget.
`timeout-or-duplicate`	The token is older than 300 seconds, or it has already been checked once. Every token is single-use.	Reset the widget after a failed submit with `turnstile.reset(widgetId)`, and make sure your code verifies each token only once.
"Turnstile token missing", "Incorrect or missing Turnstile token", "The cf-turnstile-response field is required.", "Invalid request: missing Turnstile response", `missing-input-response`	No token arrived with the form at all. The problem is in the browser or the form, not your keys.	Symptom 5.
`missing-input-secret`, `invalid-input-secret`	The secret key in your plugin or code is empty or wrong.	Symptom 2, step 1 — copy the secret key from the Cloudflare dashboard again.
"Something went wrong with Turnstile", "Turnstile not initialized"	The widget failed in the browser before it could produce a token: its script was blocked or delayed, or the page's domain isn't on the widget's hostname list (Cloudflare reports that one as client-side error `110200`).	Symptoms 1 and 3.
"Siteverify isn't being called for this widget" (a notice in the Cloudflare dashboard)	Visitors' browsers are getting tokens, but your server never checks them with siteverify. The widget is on the page, but nothing enforces it, so a bot can simply skip it.	Turn on Turnstile validation for that form in your form plugin, not just the widget. In custom code, POST the token and your secret key to siteverify and reject the submission unless `success` is `true`.

What does "Turnstile verification failed" actually mean?

Turnstile decides whether a visitor looks like a bot in the browser, before a token exists. By the time your form says "verification failed", the browser has produced a token and your server has asked Cloudflare to confirm it. So the message almost never means "this visitor is a bot". It means the confirmation step broke: the wrong secret key, a token used twice or held for more than five minutes, or a server that can't reach challenges.cloudflare.com.

Prevention checklist

Keep a copy of your site key and secret key in a password manager, labelled clearly — don't rely on remembering which is which.
Add every environment's hostname to the widget's domain list before you deploy, not after something breaks.
Exclude the Turnstile script and your form page from aggressive JS-delay and full-page caching from day one.
After any migration (new server, new domain, cPanel-to-cPanel move), re-verify the domain list and re-test the form once DNS has cut over.
If you self-host behind a VPS firewall, confirm outbound HTTPS to challenges.cloudflare.com is allowed as part of your first-hour server checklist.

FAQ

Is Cloudflare Turnstile free to use?

Yes. Turnstile is free for unlimited sites and requests — you don't need to be on Cloudflare's paid plans or even proxy your DNS through Cloudflare to use it. You only need a free Cloudflare account to generate a site key and secret key.

Do I need my domain's nameservers on Cloudflare to use Turnstile?

No. Turnstile is a standalone product — it works on any domain, on any host, regardless of who manages your DNS.

Can I run Turnstile and reCAPTCHA on the same site during migration?

Most plugins let you configure only one CAPTCHA provider per form at a time, but you can run Turnstile on some forms and reCAPTCHA on others while you migrate. Just don't leave both scripts loading on the same form — they can conflict over the same submit button hook.

Why does the Turnstile checkbox stay stuck on 'verifying'?

This almost always means the browser can't reach challenges.cloudflare.com — check for an ad blocker or privacy extension blocking the request, a corporate firewall, or (server-side) an expired SSL certificate on your own domain that's breaking the page's mixed-content rules.

Does Turnstile slow down my page like reCAPTCHA sometimes does?

It's noticeably lighter — Turnstile's managed challenge is designed to run invisibly in most cases and only escalates to an interactive check for suspicious traffic, so the vast majority of real visitors never see more than a brief badge.

What does 'Turnstile verification failed' mean?

Your server sent the visitor's Turnstile token to Cloudflare to check, and Cloudflare rejected it. It is almost always a setup problem rather than a bot: the site key and secret key come from different widgets, the token was used twice or is older than five minutes, or your server can't reach challenges.cloudflare.com.

What is the cf-turnstile-response field?

It is the hidden field Turnstile adds inside your form to carry the token to your server. 'The cf-turnstile-response field is required' means the form arrived without it, usually because the widget sits outside the form, an AJAX form didn't include it, or an optimisation plugin delayed the Turnstile script.

Originally published on the Getwebup blog.

This article was created with the help of AI.

How to Choose a VPS in India: KVM, NVMe, Network and Location

Getwebup — Tue, 22 Sep 2026 08:30:23 +0000

Choosing a VPS is often reduced to one question:
How much RAM and CPU do I get for my money?

That is important, but it is not the whole story.

Two VPS plans with the same 4 vCPU and 8 GB RAM can perform very differently depending on virtualization, storage, network connectivity, CPU allocation, and the physical location of the server.

For developers deploying applications in India, these factors can have a significant impact on performance.

Start With the Virtualization Technology

The first thing to check when choosing a VPS is the virtualization technology.

KVM is a common virtualization technology used by VPS providers. It provides a virtual machine environment with strong isolation and gives users much more control over their server.

A KVM VPS can be useful for developers who need to:

Run Docker
Configure custom networking
Install Linux packages
Host databases
Configure firewalls
Deploy APIs
Run monitoring software
Host websites and applications
Install control panels

NVMe Storage Can Make a Big Difference

CPU and RAM usually get most of the attention when comparing VPS plans, but storage performance is also important.

Applications such as MySQL, PostgreSQL, WordPress, Laravel, Node.js and Docker can perform many disk operations.

NVMe SSDs use PCIe instead of the older SATA interface and can provide significantly better storage performance.

When comparing VPS providers, don't just look for the word "NVMe."

Also check:

Storage redundancy
RAID configuration
IOPS
Snapshot support
Backup options
Disk failure protection

Server Location Matters

If most of your users are located in India, server location should be one of the factors you consider.

For example:

User → Server in India

usually involves less geographic distance than:

User → Server in Europe or the United States

Lower network latency can be useful for applications where users frequently communicate with the server.

This can be particularly important for:

APIs
SaaS applications
E-commerce websites
Databases
Gaming servers
Real-time applications

However, advertised latency should not be treated as a guarantee. Network performance depends on the user's ISP, routing, congestion and other factors.

The best approach is to test the server from the networks your customers actually use.

For example:

ping YOUR_SERVER_IP

You can also use:

mtr -rw YOUR_SERVER_IP

Don't Confuse Network Speed With Application Speed

You may see VPS providers advertising 1 Gbps, 5 Gbps or 10 Gbps networking.

A high-speed network connection is useful, but it doesn't automatically make an application fast.

Application performance also depends on:

CPU performance
RAM
Storage I/O
Database queries
Web server configuration
Application code
Network routing
Caching

For example, a poorly optimized database query can take several seconds even when the server has a very fast network connection.

The important thing is to benchmark the complete application rather than relying only on the advertised network speed.

Check CPU Allocation

Another important factor is how the provider allocates CPU resources.

Two VPS providers can both advertise:

4 vCPU

but the actual CPU performance can be different.

Check whether the CPU is:

Shared
Fair-share
Dedicated
Pinned
Burstable
Subject to throttling

For normal websites and applications, shared vCPU can be sufficient.

CPU-intensive workloads may require more consistent CPU resources.

Examples include:

Game servers
Large databases
Build servers
Video processing
High-performance applications

Therefore, don't compare VPS plans using vCPU count alone.

Compare the Complete Package

A VPS that costs ₹500 per month isn't necessarily cheaper than one that costs ₹700.

You should compare everything included in the plan.

Feature What to check
CPU vCPU count and allocation
RAM Guaranteed or burstable
Storage NVMe/SATA and redundancy
Network Port speed and transfer allowance
IPv4 Included or additional
IPv6 Available or not
Backups Included or extra
Snapshots Available or not
DDoS protection Included or paid
Support Support hours and channels
Control panel Included or additional
Location Physical server region
Billing GST and invoice requirements

This gives you a much better picture of the actual value of a VPS.

Choose the VPS Based on Your Workload

Different applications require different resources.

WordPress

Prioritize:

NVMe storage
RAM
Database performance
Web server performance
Caching
Laravel or Node.js

Prioritize:

CPU
RAM
NVMe storage
Network latency
Process management
MySQL or PostgreSQL

Prioritize:

RAM
NVMe I/O
CPU performance
Backup strategy
Docker

Prioritize:

KVM virtualization
Root access
RAM
NVMe storage
Network performance
CI/CD

Prioritize:

CPU
RAM
Storage I/O
Network bandwidth

There is no single VPS configuration that is perfect for every workload.

Don't Forget Backups

One of the most common mistakes is assuming that RAID means your data is backed up.

It doesn't.

RAID can help protect against certain disk failures, but it does not protect against:

Accidental deletion
Database corruption
Application bugs
Ransomware
Incorrect deployments
Administrator mistakes

A production application should have a separate backup strategy.

For example:

Users
  |
  v
Web Server
  |
  +---- Application
  |
  +---- Database
  |
  +---- Backup System

For important applications, backups should ideally be stored separately from the VPS itself.

Test Before Moving Production

If you are considering moving an application to a new VPS, don't immediately migrate your production environment.

Create a test environment first.

Measure:

CPU usage
RAM usage
Disk I/O
Network latency
TTFB
Database query time
Application response time
Error rate

Useful Linux commands include:

uptime
free -h
df -h
iostat -xz 1

For network testing:

mtr -rw YOUR_SERVER_IP

For HTTP performance:

curl -o /dev/null -s -w '%{http_code} %{time_starttransfer} %{time_total}\n' https://example.com

Real measurements are more useful than comparing marketing specifications alone.

VPS Checklist for Indian Developers

Before purchasing a VPS, check the following:

KVM virtualization
Full root access
NVMe storage
Transparent CPU allocation
Sufficient RAM
Indian network routing
Suitable server location
Backup options
Snapshot support
DDoS protection
IPv4 availability
IPv6 availability
Monitoring
API access
Transparent pricing
GST invoice if required

Conclusion

Choosing a VPS isn't simply about finding the highest number of CPU cores or the largest amount of RAM for the lowest price.

For developers in India, look at the complete infrastructure:

Virtualization + CPU + RAM + NVMe storage + network + server location + backups.

KVM provides a virtual machine environment with root-level control. NVMe can improve storage-heavy workloads. A server located closer to your users can reduce network latency, and a proper backup strategy protects your data when infrastructure problems or human mistakes occur.

Ultimately, the best way to evaluate any VPS is to test it against your actual application and users rather than relying only on specifications listed on a pricing page.

DEV Community: Getwebup

PHP 8.5 in cPanel: What's New and How to Upgrade Safely

Symptom: PHP 8.5 Isn't in Your MultiPHP Manager Dropdown

Cause: Why cPanel Lags a Few Weeks Behind a PHP Release

What's Actually New in PHP 8.5

The pipe operator (|>)

array_first() and array_last()

Closures in constant expressions

The #[\NoDiscard] attribute

PHP Version Support: Where You Actually Stand

Fix: Upgrading Without Breaking Anything

Common Breakage After the Switch

Prevention: Make the Next Upgrade a Non-Event

FAQ

VPS vs Shared Hosting: Which One Do You Actually Need?

What Shared Hosting Actually Is

What Changes on a VPS

Signs You've Actually Outgrown Shared Hosting

Before You Upgrade, Rule These Out

The Honest Cost Comparison

The Middle Ground

If You Decide to Move: A Realistic Checklist

FAQ

How Much Does VPS Hosting Cost in India?

What Actually Drives the Price

Typical Brackets in the Indian Market

What's Often Left Off the Headline Price

Foreign vs Indian Billing

How to Actually Compare Two Quotes

A Worked Example

How the Number Changes as You Grow

FAQ

ERR_SOCKET_NOT_CONNECTED: Causes and the Fix

Why this is almost always local

On a phone (Android or iPhone)

The fixes, in the order worth trying them

1. Flush the socket pools

2. Test in incognito with extensions disabled

3. Check the proxy configuration

4. Look at security software

5. Reset Chrome's network state

The one case where it is not local

FAQ

Call to Undefined Function in PHP: Enable the Missing Extension

What the error is telling you

Step 1: Get the exact function name from the error log

Step 2: Match the function to its extension

Step 3: Check what is loaded for the version your site actually runs

Step 4: Enable the extension in cPanel

If your cPanel has "Select PHP Version"

If there is no "Select PHP Version"

Functions no extension can bring back

WordPress: "missing the MySQL extension"

Still undefined after enabling it?

FAQ

PHP2Shell (CVE-2026-109618 and CVE-2026-109619): Check and Patch PHP in cPanel

What PHP2Shell is

Which versions are fixed

Step 1: Check the PHP your site actually runs

Step 2: On shared or reseller hosting, patching is your host's job

Step 3: On your own VPS or dedicated server

cPanel with EasyApache 4 (ea-php)

CloudLinux (alt-php)

LiteSpeed

If you can't patch today

Was the site hit before it was patched?

FAQ

WordPress Site Health Warnings: What to Fix and What to Skip

What Site Health Is Actually Checking

Critical Issues You Should Actually Fix

"Your site could not complete a loopback request"

"The REST API encountered an error"

"WordPress.com requests to your site are being blocked"

"Scheduled events have failed" / background updates not working

Recommended Warnings — Which Ones Actually Matter

When It's Safe to Ignore a Warning

Prevention: Keep the Screen Green

Bottom Line

FAQ

MySQL max_user_connections Error: Causes and the Fix

The pipe operator (`|>`)

`array_first()` and `array_last()`

The `#[\NoDiscard]` attribute