PHP 7.4 Issues/Updates
I am getting lot of Server error log about JPEG support is missing from GD.
-
cPanel should update PHP Version 7.4.5 immediately because 7.4.2 do not have GD JPEG Support? 0 -
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.
0 -
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 0 -
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! 0 -
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? [CODE=bash] # /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 Brockman0 -
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) 0 -
Currently I show this in WHM EasyApache 4 How will we know when the new version which supports GD JPEG becomes available? 0 -
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 ... ;)0 -
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?[root@na ~]# service memcached status Redirecting to /bin/systemctl status memcached.service Unit memcached.service could not be found. [root@na ~]#0 -
Currently I show this in WHM EasyApache 4 How will we know when the new version which supports GD JPEG becomes available?
Follow here: cPanel Newsroom | cPanel, Inc.0 -
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. 0 -
So cron jobs for the user should be entered as one of the following: [QUOTE] 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:
[myuser@server 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:
[root@server public_html]# cat test.php
- 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 php /home/myuser/public_html/test.php From (Cron Daemon) on 2020-04-17 15:06 Details Content-type: text/html; charset=UTF-8 Current PHP version: 7.4.2
0 -
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...0 -
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!0 -
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:
[lauren@server bin]$ which phpalias php='/opt/cpanel/ea-php55/root/usr/bin/php'
- IF an alias is present in the user's .bashrc file they'll get output like the following:
- Log in via SSH as root and run the following:
- 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
Where this fix in
0 -
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 published0 -
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? 0 -
Hello, Yes it will indeed change to 7.4.5-X.X.X.cpanel (I don't know what the cPanel specific revision numbers will be yet) 0 -
Thank you. So when the 7.4.5-X.X.X.cpanel is released, we need to wait until EasyApache 4 automatically updates itself? 0 -
Thank you. So when the 7.4.5-X.X.X.cpanel is released, we need to wait until EasyApache 4 automatically updates itself?
Nope, you can immediately update once the packages are available on the EA4 repo, I'll let you know how as soon as I get word that the repo is updated.0 -
I see lots of fixes leading up to php 7.4.5. I'm testing Wordpress sites on 7.4.2 and can't find any errors but am hesitant to switch important sites over until later versions are available. 0 -
With the exception of the GD issue which should be resolved with the update today. I'm unaware of any other issues with PHP 7.4 - can you elaborate on: I see lots of fixes leading up to php 7.4.5
What other issues have you seen?0 -
APCu is disabled as default so you can enable APCu Support by adding "apc.enabled_cli=1" -bash-4.2# ea-php74-pecl install APCu -bash-4.2# ea-php74 --ri apcu apcu APCu Support => Disabled <== Version => 5.1.18 APCu Debugging => Enabled ==Add "apc.enabled_cli=1"== -bash-4.2# grep apc /opt/cpanel/ea-php74/root/etc/php.d/zzzzzzz-pecl.ini extension="apcu.so" apc.enable_cli=1 -bash-4.2# ea-php74 --ri apcu apcu APCu Support => Enabled Version => 5.1.18 APCu Debugging => Enabled MMAP Support => Enabled MMAP File Mask => Serialization Support => php Build Date => Apr 22 2020 10:27:17 Directive => Local Value => Master Value apc.enabled => On => On apc.shm_segments => 1 => 1 apc.shm_size => 256M => 256M apc.entries_hint => 4096 => 4096 apc.gc_ttl => 3600 => 3600 apc.ttl => 7200 => 7200 apc.smart => 0 => 0 apc.mmap_file_mask => no value => no value apc.enable_cli => On => On apc.slam_defense => On => On apc.preload_path => no value => no value apc.coredump_unmap => Off => Off apc.use_request_time => On => On apc.serializer => php => php -bash-4.2# ea-php74 apcu.php string(3) "BAR" string(3) "BAR"0 -
Hey Guys, I want to get ahead of this before EA4 is updated today. I've just been told that the GD fix did not make it into today's build. But I've been promised it will be added first thing tomorrow. So I'll update here when EA4 is released and I will update again when the fix for GD is released tomorrow. I'm sorry for the delay, they just weren't able to get it resolved in time and the importance of updating the rest took precedence. 0 -
Problem continues on PHP v7.4.5 0 -
This morning I checked EasyApache 4 and i see this: What is confusing to me is that it appears to be installed already. Does this mean that when EasyApache 4 auto upgrades it will install the latest version of PHP? I assume the new version of PHP74 which will be released today will have a version number like 7.4.5-1.1.2. 0
Please sign in to leave a comment.
Comments
53 comments