apache downloads the php file instead of executing it

Howdy -- did you by chance change to a version of PHP that comes from a third party repository? That can cause the problem you're describing now.

What is the output of this command:

rpm -qa | grep php-

Ah, it looks like the Remi repository was enabled, which is a third party repository. Using packages from that can indeed cause a variety of problems (including websites not working).

There's information on that PHP issue (and how to work around it) here in the section "Why does PHP / ProFTPd no longer work after performing updates? (I'm using CentOS, and enabled third party repositories)":

https://www.virtualmin.com/documentation/system/faq

The newest PHP version that CentOS provides is 5.3.3, unfortunately.

However, you can use the CentOS SCL repository to install a second PHP version. They provide PHP 5.4.x, though I think it's less than 5.4.34.

There are instructions on using the SCL repository to install a second PHP version here:

https://www.virtualmin.com/documentation/web/multiplephp

I have suddenly the same problem. CentOS 6.* + PHP7 - worked without flaw till maybe a few days ago (I don't check everyday, might not work for w few weeks).

It's a VPS with 3 domains, lets call them 1, 2 + 3

1 + 2 want to DL the PHP 3 works fine

http.conf has no SetHandler, but I commented it out in php.conf

Now it's the other way round,

1 + 2 are fine 3 want to DL the PHP

What can I try?

Try running the following command:

virtualmin modify-web --mode fcgid --all-domains

Here is what I get. I get this error only on the domain that is currently not working.

The download option stopped, I get internal server error 500 now.

Update: I set domain3/fcgi-bin/php7.0.fcgi both to 777 and the "virtualmin modify-web --mode fcgid --all-domains" ran without errors, problem is exactly the same (Apache was restarted).

Sorry that you're having problems with PHP!

You may want to take a peek at this here and see if this applies to your issue:

https://www.virtualmin.com/documentation/system/faq#toc-why-does-php--pr...

However, as this request is a few years old, and it looks like you're using Virtualmin GPL there -- you'd actually want to start a new Forum thread to discuss the issue you're seeing there. We monitor the Forums, along with lots of wonderful folks in the community. Thanks!

Ok, will do a new topic on my issue

Here we go: https://www.virtualmin.com/node/48373

Try running virtualmin fix-domain-permissions --all-domains --subservers and then virtualmin modify-web --mode fcgid --all-domains

On Ubuntu 16.04 I just experienced the issue of being unable to serve PHP files and only download them. The fix was to comment out this line [ SetHandler application/x-httpd-php] as shown below snippet in the file

/etc/apache2/mods-available/php5.6.conf

@martlam this is not a good fix, all your websites will be using mod_php in this case.

The command virtualmin modify-web --mode fcgid --all-domains should fix this problem in the correct way ( adding missing fcgid handlers to virtual servers).

That's actually our recommended fix; when that SetHandler line is active, it forces all websites to try and use mod_php, regardless of the Virtualmin setting.

Virtualmin comments out all SetHandler lines in the PHP config file during installation, but certain third party packages can re-add that (such as adding PHP from an alternate repo).

There's some additional details on that here:

https://www.virtualmin.com/documentation/system/faq#toc-why-does-php--pr...

When I ran:

virtualmin modify-web --mode fcgid --all-domains

Rather than fixing the domain that was downloading php files, it made all my sites download php files.

I noticed output Saving server details for each of the modified domains, during the execution of that command.

Is there some way to reverse this so I can get the websites working again?

PS: I found the /etc/apache2/sites-available/*.bak files but when I copied them to restore the sites, I got:

jabowery, it sounds like you may be seeing the issue described above. For most of the folks here, they have a third party PHP version installed.

We've seen third party PHP versions causing some config issues though, including the issue you're describing.

What I'd suggest is to go to the URL in Comment #15 above, and try the solution mentioned there.

Let us know if that does the trick!

I executed virtualmin modify-web --mode mod_php --all-domains and got one site working again -- the site whose /etc/apache2/sites-available/*.bak I had restored (resulting in the 503 error reported above).

However, now all sites resolve to that site alone.

I do have deb.sury.org in my /etc/apt/sources.list.d/php.list file so that's probably it.

Although I don't have the spurious SetHandler suggested at that link:

I'm still a bit mystified by the fact that some of my sites worked prior to the execution of the "fix" and then they all went south -- and could not be made to work again even after restoring the backup files in /etc/apache2/available-sites

The issue you're seeing now seems different from the initial PHP problem... it now sounds like you're seeing the issue described here:

https://www.virtualmin.com/documentation/web/troubleshooting#toc-the-wro...

Try the troubleshooting steps mentioned there, and see if that helps with your issue.