Skip to main content

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.

Comments

15 comments

Date Votes
  • 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?
    0
  • 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.
    0
  • 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.
    0
  • 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?
    0
  • 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.
    0
  • 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.
    0
  • 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.
    0
  • Infopro
    Thanks for updating this thread. :)
    0
  • 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! :)
    0
  • 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.
    0
  • 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
    0
  • 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.
    0
  • 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
    0
  • idearius
    No problem at all. Due to your name I just (wrongly) assumed Spanish was your mother tongue :oops: Good to know a new .htaccess file is back at /public_html. Cheers.
    0
  • rodrigoorrego
    No problem at all. Due to your name I just (wrongly) assumed Spanish was your mother tongue :oops: 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! :)
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post