Announcement

Collapse
No announcement yet.

EA4 and PHP Selector problem

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • EA4 and PHP Selector problem

    Hi I just converted a server from EA3 to EA4 and now cpanel has written the following to all my users htaccess files...

    # php -- BEGIN cPanel-generated handler, do not edit
    # Set the “ea-php56†package as the default “PHP†programming language.
    <IfModule mime_module>
    AddType application/x-httpd-ea-php56___lsphp .php .php5 .phtml
    </IfModule>
    # php -- END cPanel-generated handler, do not edit

    All users were previously using PHP Selector.
    I only have one native version installed ea-php56 which is the default version on the server.

    Your documentation says that if I select the default version for the users in WHMs MultiPHP Manager, the CloudLinux PHP Selector will take control of the version. But this doesnt appear to be happening. From what I can tell - selecting this version has forced the cpanel PHP manager to add the above handler to all my users htaccess files.

    How can I fix this?

  • #2
    It looks like something in WHMs MultiPHP Manage might not be setup right. Make sure each account is set to use the WHM system default php version. I have all my accounts set to "Inherit"

    Comment


    • #3
      Hello,

      Ryan is right, please make sure that all accounts are set to "inherit".

      If you still face any issue, please feel free to submit a ticket to our helpdesk: https:/cloudlinux.zendesk.com

      Comment


      • #4
        Today I had the same problem.
        Without changing anything he added:

        # php -- BEGIN cPanel-generated handler, do not edit
        # Legen Sie das Paket „ea-php56“ als Standardprogrammiersprache „PHP“ fest.
        #<IfModule mime_module>
        AddType application/x-httpd-ea-php56 .php .php5 .phtml
        #</IfModule>
        # php -- END cPanel-generated handler, do not edit

        to one project to the main .htaccess file.

        All accounts are on "inherit".

        So I commit it out.

        But when will it appear next?

        It is strange. :-(

        Comment


        • #5
          It definitely looks like multiPHP seems like it feels its in charge. One thing you can try is to toggle an account away from inherit and back to see if that fixes it. I had a situation once where I needed to do that.

          Other than that, be sure your accounts are setup right with selectorctl http://docs.cloudlinux.com/index.html?selectorctl.html

          Comment


          • #6
            Hello, Sebastian.

            Please submit a ticket to https://cloudlinux.zendesk.com, our techs will check the issue in place.

            Comment


            • #7
              We have the same issue here. It could be fully resolved with Ryans suggestion of setting the useraccounts to inherit (and the system default php version to whatever you need).
              It´s just strange that these changes were made out of nowhere, so we had no chance to be prepared.
              This seems to be a CPanel issue with Multi-PHP, not Cloudlinux.

              Comment


              • #8
                Hello,

                Could you please specify, what was done before this issue appears?
                So far we were not able to reproduce this bug on our test server.

                Comment


                • #9
                  I really have no clue. I was installing engintron nginx caching before that happens, but had to disable it due to unforseeable issues caused by this type of setup. But I can`t imagine that this can cause such errors.
                  .
                  btw, it has not been resolved fully by the above method, as part of the users had their PHP version been "reset" in PHP Selector to PHP 4.4 with (no selectable extensions). After that, setting their version to 7.1 for example, does not set the default extensions as defined in LVE managers selector setup. But extensions could be selected/deselected manually and this seems to work.

                  Comment


                  • #10
                    It sounds really strange. If you still have users affected by this issue, please submit a support ticket:

                    We would like to check this problem in place.

                    Comment


                    • #11
                      Not anymore, we forcefully set all affected users to php7.1 with a standard set of extensions by selectorctl. (Just to reduce the amount of new support tickets)
                      There is still one user left who looks good, but php files are served as cleartext (source). There is appearently no reason for that, so if I can´t find the cause, I come back with a ticket :-)

                      Comment


                      • #12
                        Yes, sure.
                        Do not hesitate to contact us if you have any further questions or concerns.

                        Comment

                        Working...
                        X