Recently, while browsing these forums regarding the 'strange' errors thrown by PHPIDS on the logs, I noticed that this package — which, as far as I can understand, seems to be mandatory — has been abandoned by its sole maintainer, Ananda Krishna, precisely one month before it was introduced in ISPConfig3. Obviously, at the time, nobody could even imagine that the September 2014 version would be the last version of PHPIDS... ever. PHPIDS was designed to run under PHP 5.6. It seems to be possible to run it under 7.4, however, since that's what ISPConfig3 uses (for now). But the road to the future is unclear. There have been some forks of PHPIDS, maintained for a while, but long since abandoned; the most 'recent' version is from circa 2019, and may not even be fully compatible with the PHPIDS configuration. Also, it makes little sense to replace a deprecated package with a different deprecated package. Having an intrusion detection system for PHP applications makes a lot of sense — perhaps even more so now than back in 2014 — and even if it's just 'advisory' (and very cryptic in its 'warnings'), it's clearly much better than nothing. Old hacking scripts are still being used all the time by wannabe hackers and 'script kiddies', and they can be annoying, especially if they do manage to break into old parts of someone's code. On the flip side of the coin, having an 'unupgradable' component of ISPConfig3 around, means that ISPConfig3 itself cannot be fully upgraded to work under contemporary (and not EOL!) versions of PHP — which is especially important now that the PHP core team is back on track with their major-releases-every-two-years roadmap, after (almost) 20 years of sticking with the PHP 5.X codebase. PHP 9 and 10 are just around the corner, lurking, waiting to jump on those who have been neglected their own code for far too long In my experience, there is a huge amount of work to do to move PHP code to at least satisfy PHP 5.6 (with warnings), to get it ready for 7.0 (where warnings become errors). 7.1, 7.2 etc. will just flag more and more warnings as errors, and some functionality might not work exactly as intended; finally, starting with 8.0, what were errors in 7.X become deprecated functions, which will simply panic and abort the script. Not taking those pesky warnings into account leads to code that becomes impossible to maintain if you skip a few major versions. This is the case of PHPIDS today. I have not the slightest idea if the ISPConfig3 core developer team is keeping PHPIDS up to date with recent PHP versions (and guys, if you are, be nice and release it as pull requests on GitHub, under the LGPL-3.0). But one thing is having PHPIDS running under 7.X or even 8.X; the other is having PHPIDS being useful in its current, outdated form. I'm not really sure about that. There might be still good reasons to keep it around. There might really be no alternatives — as said, some PHPIDS fans have been searching for active forks or even completely different packages doing the same kind of analysis — and failing to find anything worthwhile. Or there might be a few around, which, however, would require a new integration with ISPConfig3. I think that the best solution for now is to either completely drop PHPIDS from ISPConfig3 or make it an option that could be turned off by the administrator. There seems to be such an option on the configuration stored inside the database (they must have been loaded from /usr/local/ispconfig/security/security_settings.ini), but I have no idea if (or how!) it works: in my case, although I have ids_enabled=no, PHPIDS still seems to be operational; then again, ids_anon_enabled=yes and ids_user_enabled=yes, so I guess this somehow overrides the first? The security/README.txt doesn't say... Anyway, I have placed a suggestion/feature request on ISPConfig3's GitLab (#6499).