PHP 7.4 Issues/Updates

[Nirjonadda]

I am getting lot of Server error log about JPEG support is missing from GD.

 

[Nirjonadda]

cPanel should update PHP Version 7.4.5 immediately because 7.4.2 do not have GD JPEG Support?

 

[cool_recep]

cPanel should update PHP Version 7.4.5 immediately because 7.4.2 do not have GD JPEG Support?

Really?

I'm having the same issue:

The following errors occurred while verifying that your server still meets the minimum requirements:

• The required PHP extension GD was found, but JPEG support is missing. Please ask your host to add support for JPEG images.

Reverted back to PHP 7.3. Double facepalm!

 

[Kent Brockman]

Hey guys. Today, I tested the newly added PHP 7.4.2 and found some issues:

1) Pear addon APCu can be installed but it is not being even detected by php applications. It does works perfectly on PHP 7.3. So, some misconfiguration may be happenning on PHP 7.4 because the module is being installed, yet it's undetected. May it be an incompatibility issue perhaps? You tell me.

2) On EA4, when you add the modules for memcache and memcached, php apps detect it, but cannot be used and an error is obtained regarding
object cache: localhost:11211.

3) When you try to uninstall memcache and memcached fron EA4, it will automatically force to entirely uninstall the parent PHP versions to which the selected memcache/memcached items belong. That force you to reinstall PHP and all its modules again, only if you figure out your PHP vanished. Facepalm!

Hope you can reproduce it and fix it soon.
Let me know your findings please.
Best regards

 

[cPDan]

Thank you @Kent Brockman for bringing that to our attention!

Looking into 1 and 3 now.

Item 2 is because the memcached daemon is not running and for security reasons we don’t want to enable it by default.

To make the memcache[d] extension usable you will need to install `memcached` and start the daemon (the package does not start it by default for the same reasons we don’t).

Thanks!

 

[cPDan]

1) Pear addon APCu can be installed but it is not being even detected by php applications. It does works perfectly on PHP 7.3. So, some misconfiguration may be happenning on PHP 7.4 because the module is being installed, yet it's undetected. May it be an incompatibility issue perhaps? You tell me.

Seems to be configured ok (see below) can you give further details on what is not working, perhaps a code example?

# /opt/cpanel/ea-php74/root/usr/bin/pecl install APCu
…
Extension apcu enabled in php.ini
# grep -i apcu /opt/cpanel/ea-php74/root/etc/php.d/*
/opt/cpanel/ea-php74/root/etc/php.d/zzzzzzz-pecl.ini:extension="apcu.so"

Thanks @Kent Brockman

 

[webmastergreg]

Hi,
same for me
several eShops broken because of dynamic resizing missing jpeg in GD.

So reverted back to 7.3.16 too (7.3.17 is already available)

 

[AndyX]

Currently I show this in WHM EasyApache 4



How will we know when the new version which supports GD JPEG becomes available?

 

[Nirjonadda]

How will we know when the new version which supports GD JPEG becomes available?

cPanel should be release PHP Version 7.4.5 immediately. I think this will be release in today ...

 

[Nirjonadda]

Item 2 is because the memcached daemon is not running and for security reasons we don’t want to enable it by default.

To make the memcache[d] extension usable you will need to install `memcached` and start the daemon (the package does not start it by default for the same reasons we don’t).

How to enable memcached daemon? Also how to automatically start memcache and memcached with Server Reboot?

[[email protected] ~]# service memcached status
Redirecting to /bin/systemctl status memcached.service
Unit memcached.service could not be found.
[[email protected] ~]#

 

[cool_recep]

Currently I show this in WHM EasyApache 4

View attachment 64753

How will we know when the new version which supports GD JPEG becomes available?

Follow here: cPanel Newsroom | cPanel, Inc.

 

[cPanelLauren]

As I noted in the thread here: SOLVED - PHP 7.4 when?

Just to get ahead of things as well I want to note that there will be an update from PHP for 7.4 tomorrow which we should be pushing next week on Wednesday

We're planning to update Wednesday which will include the fix for JPEG support. There is an open case for this as well ZC-6605 - I'll update this thread Wednesday confirmation.

 

[Kent Brockman]

Another issue I found today:

When you set PHP 7.4 as the default version in WHM's MultiPHP Manager, the cronjobs executing commands starting with the simple "php [path]" won't work as they used to do with previous PHP versions. I know the full php74 path can be used, but that it's not fully recommended cause end users are not always aware of their own cronjobs nor even about PHP changes and deprecations. So calling "php" directly MUST work. In fact, it actually works out of the box with PHP 7.3 and lower. But with PHP 7.4 it's simply not working.


Now to the good news...

WordPress sites running on PHP 7.4, shown a memory footprint 10-15% lower than when running on PHP 7.3 and a speedup of almost 20%. Also, most of the tested sites demonstrated that if it can run with PHP 7.2 and 7.3, it shouldn't have big issues with 7.4. So, I want it working to its full potential cause it will greatly improve websites performance and also free-up memory in all the servers.

 

[cPanelLauren]

So cron jobs for the user should be entered as one of the following:

PHP command examples:
General example:/usr/local/bin/php /home/$USER/public_html/path/to/cron/script

Domain-specific example:/usr/local/bin/ea-php99 /home/$USER/domain_path/path/to/cron/scriptIn the above example, replace “ea-php99” with the PHP version assigned to the domain you wish to use. Look in the MultiPHP Manager for the actual PHP version assigned to a domain.

This is noted in the Add New Cron Job interface

But just to be sure this functions by default the way you're expecting I did the following to test:

• I set the system default in WHM's MultiPHP Manager to use PHP 7.4
• I added my test account, which by default inherited the System PHP Version
• Logged in via shell as my new user to confirm that my new account shows using the correct PHP version when calling PHP by itself:

  [[email protected] bin]$ php -v
  PHP 7.4.2 (cgi-fcgi) (built: Apr 14 2020 23:35:11)
  Copyright (c) The PHP Group
  Zend Engine v3.4.0, Copyright (c) Zend Technologies

• Created a test PHP script which outputs the php information:

  [[email protected] public_html]# cat test.php
  <?php
  echo 'Current PHP version: ' . phpversion();
  ?>

  • It's rough I know, but get's the job done
• Added a cron Job in cPanel>>Advanced>>CronJobs that runs my script:

  *    *    *    *    *    php /home/myuser/public_html/test.php

• Checked my email after the cron ran and confirmed the output:

  Cron <[email protected]> php /home/myuser/public_html/test.php
  From (Cron Daemon) <[email protected]> on 2020-04-17 15:06
  Details
  Content-type: text/html; charset=UTF-8
  
  Current PHP version: 7.4.2

No other modifications were necessary.

 

[Kent Brockman]

So cron jobs for the user should be entered as one of the following:
......
No other modifications were necessary.

Interesting. Now I wonder why it didn't worked on my test server. I tested it with WordPress cronjobs, WHMCS cronjobs, and with another php script which also requires cronjobs. None of them were executed...

 

[cPDan]

3) When you try to uninstall memcache and memcached fron EA4, it will automatically force to entirely uninstall the parent PHP versions to which the selected memcache/memcached items belong. That force you to reinstall PHP and all its modules again, only if you figure out your PHP vanished. Facepalm!

Quick update on that: this will be fixed in 88.

The good news is that it isn’t a `Requires` related problem and thus doesn’t happen via CLI if both are erased. It also does not happen when removing memcache or memcached (just both of them).

Appreciate the report!

 

[Nirjonadda]

Quick update on that: this will be fixed in 88.

Where this fix in 88 Change Log? Also when v88 will be CURRENT release Tier?

 

[cPanelLauren]

Interesting. Now I wonder why it didn't worked on my test server. I tested it with WordPress cronjobs, WHMCS cronjobs, and with another php script which also requires cronjobs. None of them were executed...

I'm not sure I can give you an answer as to why without further investigation. Can you provide the answers/output of the following for me?

• Is this on multiple accounts or just select accounts?
• Can you confirm you have the default PHP version set to PHP 7.4? You can do this with:

  /usr/local/cpanel/bin/rebuild_phpconf --current

  • That command will also provide some information about the configuration you're using such as the php handler
    
• Is anything noted in .bashrc for the accounts this occurs on? This will become apparent by one of the following methods:
  • Log in via SSH as root and run the following: cat /home/$user/.bashrc
  • Log in via SSH as the cPanel user and run the following: which php
    • IF an alias is present in the user's .bashrc file they'll get output like the following:

      [[email protected] bin]$ which phpalias php='/opt/cpanel/ea-php55/root/usr/bin/php'

• What is the output of the following when logged in as the user?

  php --version

• Do you have the php-cli package added? What's the output of the following:

  rpm -qa |grep php-cli

@Nirjonadda

Where this fix in 88 Change Log?

The fix isn't in the changelog yet. It will be when it's added to the build.

Also when v88 will be CURRENT release Tier?

There's no date that can be provided for that as of right now but I believe we're looking at a few weeks

 

[cPDan]

Quick update on that: this will be fixed in 88.

The good news is that it isn’t a `Requires` related problem and thus doesn’t happen via CLI if both are erased. It also does not happen when removing memcache or memcached (just both of them).

Appreciate the report!

Correction, it is a `Requires` related problem. We’ll post details here once the corrected URLs are published

 

[AndyX]

Looking forward to the PHP 7.4 update.

Currently I see this in EasyApache 4



When the update occurs, will the 7.4.2.1.1.1.cpanel number change?