Whats the point of virtualmin apache2 vhost Removehandler .php

Continuing the discussion from VirtualHost RemoveHandler:

In apache2 Vhost file of each domain i found

RemoveHandler .php
RemoveHandler .php8.1

but actually it does nothing. I removed the FPM .sock directive from vhost and enabled mod php8.1 by using command a2enmod php8.1 and i think PHP files should not work because we are using RemoveHandler to not allow mod php to work. But mod php is still working for that domain even if we have RemoveHandler .php and RemoveHandler .php8.1 in vhost. I can see Apache 2.0 Handler in php info file.

OS type and version Ubuntu server 22.04
Webmin version Latest
Virtualmin version Latest
Related packages SUGGESTED

@Joe earlier you said

The only time Virtualmin should be adding those is if mod_php is enabled in Apache, and you’re using an execution mode other than mod_php. If you aren’t using mod_php I recommend disabling it entirely (I have wanted to disable mod_php, by default, for about five years, but people really get mad when I try!). But, disabling it will cause Virtualmin to not add those directives.

But even after disabling mod php virtualmin adds removehandler in virtualhost. I think removehandler does not prevent php from being working even when using only mod php for that vhost. Then whats the point of adding removehandler.




I just want to know whats the point of adding this in vhost

RemoveHandler .php
RemoveHandler .php8.1

if it does not disables mod php for that specific vhost. I think it can not override sethandler that is used in mod php8.1 conf file. I think RemoveHandler can only override AddHandler.


and my question was why did you “remove the FPM .sock directive from vhost and enabled mod php8.1” which deliberately looks like you were attempting to break what was put in place.

If Virtualmin is still adding them (and they don’t just exist from prior mod_php existence), then you didn’t disable mod_php.

You should never have mod_php installed. Stop doing it. Uninstall mod_php. It is not good for anything.

1 Like

Note this is also covered in the forum guidelines:

If you’re using mod_php, stop. If you’ve installed mod_php, uninstall it. mod_php is usually in the php package or php<version>-php package. Don’t install that package. You don’t need it or want it. If you followed random guides on the internet for installing additional PHP versions, you probably also installed mod_php. Again, uninstall it.

We’re unwilling to help with intentionally made messes, and using mod_php is intentionally breaking your system at this point in history.

1 Like

@Joe I havent installed anything virtualmin is adding removehandler in fresh installed virtualmin even when mod php is not installed and nor enabled. Thats what i am asking why its adding even if i dont have mod php installed.

Whats the point of adding removehandler in vhost in fresh installed virtualmin even if i dont have mod php installed.


That’s where communication is breaking down. Virtualmin does not add RemoveHandler if you don’t have mod_php installed. Ergo, if Virtualmin is adding RemoveHandler entries, you have mod_php installed.

There would be no point in Virtualmin adding RemoveHandler entries if mod_php were not there, and I’ve never seen it do so (at least not in a decade or more).

The only way you would see them “added” would be if you restored a domain from a backup that had them, and even then, I think Virtualmin tries to clean them up (but wouldn’t touch .htaccess files and maybe wouldn’t fix up some custom sections, I’m not sure). So, are these domains where it is being “added” coming from a backup on an old system that had mod_php?

1 Like

I dont know why this happening to me i just reinstalled the virtualmin on fresh ubuntu server 22.04 and added a fresh new domain. everything is fresh and clean. But again virtualmin is adding removehandler.

I checked and verified that mod php is not enabled.

I dont know why :confused:

The RemoveHandler directive in Apache configuration is not specific to mod_php and can be used in conjunction with other ways of handling PHP, including FPM and FCGId/CGI.

Primarily, we always used it to override and disable any default configurations.

1 Like

Exactly what i thought i even private messaged you. Thankyou for clearification.

Thankyou @Joe @Ilia

Love you :slight_smile:

That doesn’t sound right? What “default configuration” would we be disabling other than mod_php?

That sounds like wrong behavior if it’s actually what Virtualmin is doing. Adding a bunch of extra junk to every virtual host config just in case someone has installed mod_php or somehow otherwise broken their Apache feels bad to me. (Note this is specifically about RemoveHandler .php lines.)

If additional PHP versions installed, in particular on RHEL and derivative systems, installing php82-php-fpm package from remi-safe repo does bring /etc/httpd/conf.d/php82-php.conf default config file.

Although, even though it doesn’t hurt having RemoveHandler directives added, I’m not 100% confident that it isn’t really needed to cover all systems with all different versions we support.

@Jamie, what is your take on this? I don’t have mod_php installed and still have a bunch of RemoveHandler directives in my Apache config.


Dang. Don’t like that.

1 Like

But, if it’s so, then we do in fact need RemoveHandler. Nothing to discuss. I don’t like it, but it is what it is. We aren’t going to maintain our own PHP packages to fix this one problem.

Those two statements conflict.

It was not clean you installed/enabled mod php8.1 so you wonder why?

I tried both of the cases just to know what is happening.

I have centos 9 and never installed mod_php and have 4 RemoveHandlers (php 8.1 being used on this virtual server).


Looks like a standard setting. Not sure why your worrying about it. As long as everything works.
I wonder if its because php can be turned on and off and switched between versions.

Yes, as Ilia pointed out above, they are needed when php-fpm is installed (which is now everywhere since it is the recommended execution mode). I don’t like it, but we’re not changing the upstream packages.