0

This is a problem encountered apparently by a lot of users when installing from the Craft setup/install files from the Craft web site.

PHP Warning: Unsupported declare 'strict_types' in /var/craft/vendor/voku/portable-utf8/src/voku/helper/Bootup.php on li PHP Fatal error: Default value for parameters with a class type hint can only be NULL in /var/craft/vendor/voku/portablec/voku/helper/Bootup.php on line 27 Script @php craft setup/welcome handling the post-create-project-cmd event returned with error code 255

The following scenario yields this error:

  • A fresh install of craftcms

  • installed with composer

  • using these instructions: https://craftcms.com/docs/getting-started-tutorial/install/files.html#what-s-composer

  • On a bran new unused DigitalOcean Plesk/Centos7 machine

  • with php aliased to the Plesk php 7.4 folder

  • With CLI php -v verified as returning 7.4

  • With all the required php extensions

  • With the web server visited and phpver command verified as returning 7.4

  • with composer updated

    # composer depends danielstjules/stringy

    # voku/stringy 6.4.0 replaces danielstjules/stringy (~3.0)

Diagnosing it, Right, putting echo phpversion(); into Bootup.php and running from Bash returns 7.4.

But comment everything in Bootup.php out, put echo phpversion(); into it and run craft, and when it calls Bootup.php, it returns 5.4.16.

Why is this? Why does it run with a different php version when run from within the Craft script, and how is this fixed to run with 7.4?

0

Where did you define your aliases? If you haven't already, you could start by adding directives for both php and composer in your .bash_profile.

The file should contain something like (alter paths as appropriate):

# Include the location of the PHP 7.4 binary in your path
export PATH=/opt/plesk/php/7.4/bin:$PATH
# Ensure that any calls to composer are run with the PHP 7.4 binary
alias composer='/opt/plesk/php/7.4/bin/php /usr/lib64/plesk-9.0/composer.phar'

Log out/in (or source .bash_profile) and run php -v to check it's picking up the correct binary, then have another go.

  • Thanks. It turned out the issue was due to a shebang in the Craft files, which ultimately led to /usr/sbin/php. THe php there was php5. I solved it by renaming php and adding a symbolic link ln -s from php to php7.4. Does your solution solve this same problem? – samerivertwice Oct 26 '20 at 10:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.