So what does this mean for MODX? Is an update needed for it to work with the Litespeed updates?
My web host has just updated Litespeed and I now have 58 MODX sites with broken managers.
Can any of you help to identify the root cause? What is breaking exactly? Any technical information about what breaks (“the manager is broken” is not very specific) would be very very useful to make any meaningful statements.
The manager just sends AJAX requests. Admittedly there are quite a few of them, but I don’t know how those would break Litespeed and I don’t have a way to reproduce that currently. I don’t think the usual core devs use Litespeed regularly either (but could be wrong).
Hi @markh
Apologies - I realise now my reply might not seem very helpful - but I thought the technical side of the issue had been covered in the original post by @snowcreative here
I was frustrated and wanted to lend weight to the call for help.
Symptoms for me are the same - when I open the MODX manager, the resource tree and the dashboard panels won’t load - they just sit empty.
In devtools - the manager’s background requests are failing with:
net::ERR_HTTP2_PROTOCOL_ERROR.
For example:
POST /connectors/index.php?action=Resource/GetNodes
fails with:
ERR_HTTP2_PROTOCOL_ERROR
It looks a bit like - while not necessarily doing anything wrong - MODX’s chatty nature is falling foul of Litespeed’s new rules on HTTP2/3.
I’m currently in touch with my hosts to see if they can offer any help - but input from MODX side might be good too.
Thanks for checking in.
No apologies needed - just asking for more information. Sorry if I came across too direct 
Do you have any server (litespeed/php) logs that indicate anything by chance? I don’t really think PHP has much to say about the protocol so this is an odd issue. Leaning towards it being a LiteSpeed bug personally…
It at least feels like Litespeed has gone in too heavy with limits or something.
I don’t have access to Litespeed logs unfortunately - juat browser-side data.
Another user with same issue: Resource tree disappeared suddenly
Here’s what my host reports:
____________________________________________
We reviewed both the MODX application logs and the LiteSpeed server logs while reproducing the problem.
The logs do not identify a specific MODX header, JSON field, or response body that LiteSpeed rejects. What they show is:
The MODX Manager initially loads normally.
Several AJAX requests complete successfully over HTTP/2.
Requests to both the core MODX Resource tree and the separate VersionX dashboard component then fail.
LiteSpeed records the affected HTTP/2 stream/request as aborted and terminates the associated PHP process.
The browser consequently receives an incomplete or empty response, resulting in the resource tree and dashboard sections disappearing.
The same requests remain stable when the domain is restricted to HTTP/1.1.
We also tested with Brotli compression disabled, cPGuard/ModSecurity disabled for the domain, MODX updated, and LiteSpeed updated to its latest build. None of those changes corrected the HTTP/2 behavior.
There were some unrelated warnings in the MODX logs, but we did not find a MODX or PHP fatal error occurring at the time of the HTTP/2 failures. The server logs also do not expose the contents of the response immediately before the stream is aborted, so they do not currently tell us that MODX is sending a particular invalid value.
Based on the available evidence, this appears to be either:
A LiteSpeed HTTP/2 handling bug, or
A specific interaction between LiteSpeed’s HTTP/2 implementation and the burst of concurrent PHP/AJAX requests generated by the MODX Manager.
We cannot completely exclude third-party MODX components without testing a clean staging copy with all Extras and custom plugins disabled. However, because the core Resource tree request also fails, this is not limited to VersionX or one dashboard widget.
The logs specifically show LiteSpeed recording abort request, code: 4, issuing extappkill for the corresponding lsphp process, and eventually sending SIGKILL; the affected VersionX request was logged as an empty 200 0 response. The same timeframe also shows successful core MODX requests followed by the VersionX empty response, which is why the evidence does not isolate this to one MODX component.
______________________________________
FYI, it’s not just the tree and the VersionX widget. It’s just about every area that uses a grid (users list, etc.)
Thanks @snowcreative.
How’s the behavior on other pages in the manager, e.g. editing a resource at /manager/?a=resource/update&id=1? Does that load better or is it the same as the dashboard?
On the dashboard, do the news feed load or fail?
As I had no clue, I asked AI to analyse the core and see if there’s anything that would upset litespeed or http2/3, and that’s flagging the news and security feeds as potentially locking up on session files while loading remote content, causing other requests to pile up - and fail with this exact error.
It working better on http1 would be because http1 natively throttles requests so any such lock doesn’t cause an equally big pile-up.
Hey @markh
Both news & security feeds fail for me - alongside the resource tree:
[I redacted the site name]
Editing a resource works OK.
But system settings:
Just tested [on my own host of course] with a vanilla MODX 3.2.3-pl install on cPanel / Litespeed – no extras - same results
Playing around on a site @dejaya gave me access to, /connectors/index.php?action=Resource/GetNodes&id=web_0&type=MODX\Revolution\modContext (to populate the resource trees with contexts) seems to be failing consistently even after I added queuing of ajax requests to avoid hammering the server.
With a queuing patch in place, most of the requests complete correctly and the manager is more functional - except that one.
@snowcreative any chance you’re seeing the same and your host could check the logs for that specific request?
The patch needs more work but while I still think litespeed is the problem, it does seem to alleviate it a bit.
We’re seeing this problem on about 100 MODX websites on the same shared LiteSpeed server.
Every time LiteSpeed is updated automatically, the MODX Manager stops working. We get ERR_HTTP2_PROTOCOL_ERROR, the resource tree is empty, grids don’t load, and the Package Manager no longer works.
Our hosting provider rolls LiteSpeed back to the previous version, and everything works again straight away. When LiteSpeed updates again, the same problem comes back.
This has happened several times now with the same result.
Our hosting provider has opened a support ticket with LiteSpeed. At the moment, it looks like this is a LiteSpeed HTTP/2 problem rather than a MODX problem.
Yes, that’s the one that consistently fails, and it’s what I sent to hosting tech support at the start of my support thread with them.
I wonder whether some other CMSs are experiencing this problem.
those fail for me as well, although I have those turned off on the site that is experiencing this problem. And even when I have all the dashboard widgets turned off that aren’t loading, the resource tree still doesn’t load.
Have same with my sites. Do You (modx team) have a plan to verify and correct the modx code to meet new lite speed version?
If your site has a dedicated IP, you may be able to ask your provider to add that IP to Litespeed’s allow list to bypass the throttling. For sites on a shared server that uses the same IP for all sites, providers may not be willing to do that.
see here for a per-site fix
Working on a core workaround/fix here that incorporates the discussions on this topic: Try to work around LiteSpeed on HTTP2/3 issue following updates by Mark-H · Pull Request #16980 · modxcms/revolution · GitHub
Thanks @dejaya for providing a test environment for this, and everyone for providing their input and research to pinpoint the exact things LiteSpeed doesn’t like.
Help with testing the PR (both on LiteSpeed and other servers) would be appreciated!
Just upgraded my servers to litespeed build 6.3.6 (build 6). Everything seems to be working again. Hope this helps anyone else, and yes it was a Litespeed issue.
Build 6¶
Released: August 3, 2026
-
[Bug fix] Allow
\in query string for HTTP/2 and HTTP/3 request headers. -
[Improvement] Support for multiple remote ACL URLs.
@rcarnrick Thanks - confirming that V6.3.6 (build 6) has been implemented my host too - and that after a quick check around I agree it looks to have solved the issue.
@markh Hopefully any work you’ve put in on the PR won’t have gone to waste? Thanks so much for helping to troubleshoot this - it’s been a real headache for me!