After WHM migration, WordPress website downloads PHP files instead of parsing

[idearius]

Hello,

After migrating a third-party account from inmotion using WHM with an account username and password, the website doesn't load; instead it asks to download a randomly named PHP file that contains the WordPress file that should have been parsed.

I've read and tried many possible solutions:
- deleting or renaming the .htaccess file,
- deleting a PHP declaration inside of the .htaccess (that was not there in this case),
- deleting/moving certain WordPress plugins that demand too much resources or use cache,
- increasing memory assigned to PHP (memory_limit is at 128 MB),
- checking file permissions,
- checking database health and permissions.

I use Firefox. I've had more success viewing the site with Internet Explorer (I read it doesn't care what the file type is, it just renders what it sees) but many times it happens with IE as well... like right now.

The thing is that the download vs parse problem happens most of the time, kind of randomly, but not all of the time.

That could point to memory problems, but this is a brand new server. It has only two other WordPress sites, both really lean, on one account, and an also lean web app used by just a handful of users, on another account.

Disk usage is at 26%.
Memory usage right now is:

              total        used        free      shared  buff/cache   available
Mem:        1011376      705672       71852        5704      233852      140428
Swap:       2096444      287876     1808568
Total:      3107820      993548     1880420

Yesterday night I had it working for a few hours when I increased the memory assigned to PHP, but now it is failing again.

Any help will be much appreciated.

 

[Infopro]

Have you looked at your logs for clues to the issue?
Is it just one WP site or are all failing to load similarly at the same times?

 

[idearius]

The other two (at another domain and account) work just fine. They were transferred in the same way, but from another host.

Could you point me to the right logs??

By the way, I also tried deleting the account and recreating it from a full cPanel backup, and increasing the PHP memory to 256M, but nothing changed.

 

[cPanelMichael]

Could you point me to the right logs??

Hello,

Look for a file named "error_log" within the document root of the website (e.g. /home/$username/public_html/). It should include the PHP errors from the script installed in that directory as long as PHP error logging isn't disabled.

Thank you.

 

[idearius]

Thanks.

The error_log file dates from June. It is one of the files I moved to a temporary folder so as to delete it in the near future, and no new error_log was created.

At WHM Home > Service Configuration > PHP Configuration Editor > log_errors is On. The display_errors value is On, though. I guess I should turn that off.

I checked the Apache logs and -curiously- most bot requests return 200 and 304 status.

Any ideas?

 

[Infopro]

By the way, I also tried deleting the account and recreating it from a full cPanel backup

With the other sites on the same server working fine as you mention, I think we can assume its down to this site.

You might want to check that site a bit closer. Is it up to date? Do you have addons installed that are up to date and safe to use? Too many addons? Configuration of an addon incorrect? There's lots of things this could be.

If you don't have root access to the server you might contact your Hosting Provider and ask him for some details from the server logs. If you've got root access, check this log for clues when the site goes down:
/usr/local/apache/logs/error_log

If it was me;

- deleting/moving certain WordPress plugins that demand too much resources or use cache,

I'd disable every single plugin, addon and custom style and start from there.

 

[idearius]

I do agree that it must be something limited to that website.

Yesterday, when I did get into the WordPress admin, I updated everything, removed iThemes Security (manually cleaning up the .htaccess afterwards), installed Wordfence and made a scan just in case. No cache plugins were installed.

Today I did check the Apache logs and most search engine requests returned 200 and 304 status... I was expecting 404 errors.

Will check again just in case. If you have any other idea, please share it.

Thanks.

 

[idearius]

Problem solved, thanks to one of your partners here.

There was an additional .htaccess file at the /home directory -below the /public_html directory- that I never saw was there. It had this incompatible declaration:

# Use PHP55 as default
AddHandler application/x-httpd-php55 .php

The only thing I can think of that could explain how it got to work sometimes, is that (even after about 12+ hours) the DNS changes were not fully propagated and what I entered was the website at the old server instead of at the new one.

Thanks to everyone involved.

 

[Infopro]

Thanks for updating this thread.

 

[rodrigoorrego]

Problem solved, thanks to one of your partners here.

There was an additional .htaccess file at the /home directory -below the /public_html directory- that I never saw was there. It had this incompatible declaration:

# Use PHP55 as default
AddHandler application/x-httpd-php55 .php

The only thing I can think of that could explain how it got to work sometimes, is that (even after about 12+ hours) the DNS changes were not fully propagated and what I entered was the website at the old server instead of at the new one.

Thanks to everyone involved.

hello idearius,

what you did then? you edited or deleted the .htacess file from / ?

I'm having the same problem but I admit that i'm a newbie..

and thanks for your answers!

 

[ElviCities]

hello idearius,

what you did then? you edited or deleted the .htacess file from / ?

I'm having the same problem but I admit that i'm a newbie..

and thanks for your answers!

It would appear that the user removed the:

# Use PHP55 as default
AddHandler application/x-httpd-php55 .php

Line from their .htaccess

Generally, this addition to the .htaccess file is utilized in various "Multi PHP Version" or "PHPSelector" type addons (cloudlinux, other 3rd party plugins).

If it is declared in an .htaccess file where such a plugin is not utilized, it will prevent .php files from being handled/parsed correctly.

 

[rodrigoorrego]

I figured it out, thanks Elvicities for your answer and thanks Idearius and other people from this topic for the other answers! :D

if i could like more times the posts I would hahah!

the site is using prestashop, and with the .htaccess that the site were using we were unable to even load it.. but when I deleted both .htaccess from / and from public_html, I was able to access the prestashop panel and generate a new .htaccess from there!

it's working now! :D

 

[idearius]

It would appear that the user removed the:

# Use PHP55 as default
AddHandler application/x-httpd-php55 .php

Line from their .htaccess

Generally, this addition to the .htaccess file is utilized in various "Multi PHP Version" or "PHPSelector" type addons (cloudlinux, other 3rd party plugins).

If it is declared in an .htaccess file where such a plugin is not utilized, it will prevent .php files from being handled/parsed correctly.

Thanks, ElviCities. I actually renamed and later deleted that .htaccess file, but it could have worked by only deleting those lines.

I figured it out, thanks Elvicities for your answer and thanks Idearius and other people from this topic for the other answers! :D

if i could like more times the posts I would hahah!

the site is using prestashop, and with the .htaccess that the site were using we were unable to even load it.. but when I deleted both .htaccess from / and from public_html, I was able to access the prestashop panel and generate a new .htaccess from there!

it's working now! :D

Hola, Rodrigo. Disculpas por la demora. Me alegra que hayas resuelto el problema.

Cuidado con el archivo .htaccess en /public_html. Ese sí debería existir, no sólo porque prestashop podría haber agregado código que necesite, sino porque también allí debería haber algunas instrucciones para optimizar y asegurar tu sitio web.

Saludos.

 

[rodrigoorrego]

Thanks, ElviCities. I actually renamed and later deleted that .htaccess file, but it could have worked by only deleting those lines.



Hola, Rodrigo. Disculpas por la demora. Me alegra que hayas resuelto el problema.

Cuidado con el archivo .htaccess en /public_html. Ese sí debería existir, no sólo porque prestashop podría haber agregado código que necesite, sino porque también allí debería haber algunas instrucciones para optimizar y asegurar tu sitio web.

Saludos.

esta bien.. yo he eliminado el archivo .htaccess en /public_html para prestashop crear un nuevo archivo .htaccess

(prestashop tiene una herramienta en su panel de control que hace esto)

le pido perdón porque mi español no es perfecto jajajaja

 

[idearius]

No problem at all. Due to your name I just (wrongly) assumed Spanish was your mother tongue

Good to know a new .htaccess file is back at /public_html.

Cheers.

 

[rodrigoorrego]

No problem at all. Due to your name I just (wrongly) assumed Spanish was your mother tongue

Good to know a new .htaccess file is back at /public_html.

Cheers.

No problem, already happened before haha!

I'm from Brazil, my mother language is portuguese

I can also speak spanish, since I have relatives from Uruguay, but from daily use I believe my english turned better than my spanish hahaha

Thanks again for your answers!