From the linked libgd issue, it appears this problem could be solved by adding 64-bit support, unless I'm totally misinterpreting things. It's something I've come across a few times, on images that don't appear at first to be that large.
@znaeff, thank you—I've applied the patch, and tested in various environments. Looks like it has fixed the issue.
@Mohd Sahzad: Where should this be added. I'm looking at the file, but it isn't exactly clear where to add the code. When I get confirmation of where to add it, I will create a patch, and post.
Also getting a similar issue on core 10.1.5, PHP 8.1, Cleantalk 9.2.7. In my case, it's showing up in the logs as:
Warning: Undefined array key "next_call" in Cleantalk\Common\Cron\Cron->checkTasks() (line 255 of /app/web/modules/contrib/cleantalk/lib/Cleantalk/Common/Cron/Cron.php)
Will look if the patches work here.
Agaric has an article on dealing with this issue—and I can vouch it works very well.
Essentially, any changes made to .bashrc, .bash_aliases, .bash_profile, .profile, etc. will have no effect on which PHP Drush uses. It requires a different approach to path to the PHP version you want it to run with. One way to set this up:
- Check with your hosting provider to find which versions of PHP are available, and their respective paths.
- On your shared hosting account root folder, create a /bin folder (
mkdir bin) - Create an alias to your desired version of PHP, like this example:
ln -s /usr/bin/[your_php_verison] ~/bin/php. Make sure this matches what your provider offers. - Test that the alias works by running:
bin/php -v - Add a path to your Drush site alias to link to this version of PHP in each environment like this example:
env-vars:
PATH: /home/[your account]/bin:/usr/bin:/bin
Once this is up, test it by running drush @alias st.
Hope this helps!
I ran into this issue myself on a few projects that use shared hosting. As others in this thread have related, it's most likely due to support of Wordpress, an assertion backed up by numerous blog posts and articles. It's also unnecessary, since anyone keeping a Wordpress site current would have no issues running on PHP8.x. It would be the same as if us Drupal practitioners were pushing hosts to run deprecated environments in order for us to keep obsolete sites up.
@diamondsea has a good workable solution, which should be able to be adapted to many situations. For host-specific needs, it's best reach out to tech support to find our their pathing to alternate PHP runtimes for the CLI.
Is further testing required, or is this good to go?
By examining files in the destination directory. It's also pretty apparent by the file size, itself.