Fresh install of 8.6 doesn't work anymore (8.5 still worked)

Hi,

I’ve already done quite a few installations and they worked often well - just this time it’s a bit odd.
(Ubuntu Server 22.04, Apache 2.4, 8.1, php-fpm, Maria DB 10.6.16)

Sticking to the guides:

and even checking:

I see an issue in the precheck:

If I go to the https://domain.com/api/graphql I see a 500 error.

In the php / apache error log I can see:

[Wed Apr 17 19:27:53.025899 2024] [proxy_fcgi:error] [pid 1012537] [client 178.18.245.110:40982] AH01071: Got error 'PHP message: PHP Deprecated:  Return type of Symfony\\Component\\HttpFoundation\\Session\\Attribute\\AttributeBag::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/domain.com/service.domain.com/vendor/symfony/http-foundation/Session/Attribute/AttributeBag.php on line 134PHP message: PHP Deprecated:  Return type of Symfony\\Component\\HttpFoundation\\Session\\Attribute\\AttributeBag::count() should either be compatible with Countable::count(): int, or the #[\\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/domain.com/service.domain.com/vendor/symfony/http-foundation/Session/Attribute/AttributeBag.php on line 144PHP message: PHP Deprecated:  Return type of Symfony\\Component\\HttpFoundation\\Session\\Session::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/domain.com/service.domain.com/vendor/symfony/http-foundation/Session/Session.php on line 131PHP message: PHP Deprecated:  Return type of Symfony\\Component\\HttpFoundation\\Session\\Session::count() should either be compatible with Countable::count(): int, or the #[\\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/domain.com/service.domain.com/vendor/symfony/http-foundation/Session/Session.php on line 141'

I tried around with

  • file / directory permissions
  • re-downloading everything
  • setting different options in php.ini
  • rechecked all rewrite details (module, vhost instructions, .htaccess)
  • sudo -u www-data bin/console cache:clear

And finally tried in the .env qa instead of prod.

Then, it suddenly worked.

If I go to the https://domain.com/api/graphql I see now a page with

Symfony Exception
Invalid CSRF token etc.

Installation went through, everything seems to be fine - but I don’t dare to switch my installation back to prod now.

What’s the difference between qa and prod?
What could be the problem with my installation / environment?

I’m seeing a very similar issue, same behavior. The web console consistently throws getting a 502 response from one API call to api/graphql in particular (appMetadata)
I’ve gone through all of the permissions thoroughly, and am still stuck.

did you find anything in the .htaccess or vhost that you had to change that you can share that might be worth a try?

+1 for me. I had a working 8.3.1 and upgraded to 8.6.0 and getting 500 error on api/graphql
Also my root director crm.mywebsite.com no longer works, just shows the file system. I can login at: crm.mywebsite.com/public/ but I just get a blank home page. I tried navigating to /#/amdinistration to see if I could R& R or something. Nothing seems to work. I get a 500 error on index.php too.

I’m also getting this in php log: Uncaught TypeError: fwrite(): Argument #1 ($stream) must be of type resource, bool given in /home/technokr/public_html/crm.mywebsite.com/public/legacy/modules/SugarFeed/SugarFeed.php:203

Hey all a second file permission reset AFTER the -finalize command seems to have done the trick to fix this issue for me!

1 Like

Hey @pstevens,

PHP access to write to files will vary so much depending on your setup (user, group, etc) that is always best to always reset permissions before and after each step.

I always do something like the following :

from:

Thanks @anthony.oak.castro there is one more step I did to make it work.

After - finalize:

./bin/console cache:clear

Then one final permission reset. This seems to have fixed it for me.

Just one other issue I’m struggling with. I have the istallation in:

crm.mywebsite.com

However, after the upgrade it’s only accessible at:

crm.mywebsite.com/public/

The root no longer serves up and the root jus shows the file system. I’m going to add an .htaccess to hide this, but I’m wondering if I should add a redirect to /public/ ?

Hey @pstevens,

Thanks! Its strange… I thought the suitecrm:app:upgrade-finalize cleared the symfony cache, at least its what it mentions on the output… and it seems to be doing so on

  • core/backend/Install/Service/Upgrade/Steps/FinalizeClearSymfonyCache.php

Public folder issue

Regarding the public folder, yeah on Suite 8 you need to change your vhost to point to public. On the docs they say:

From Webserver Setup Guide | 4. Configuring URL re-writes

Update your vhost configuration to add the following:

<VirtualHost *:80>

    DocumentRoot /<path-to-suite>/public
    <Directory /<path-to-suite>/public>
        AllowOverride All
        Order Allow,Deny
        Allow from All
    </Directory>

</VirtualHost>

thanks @anthony.oak.castro , actually I found it easier to add the .htaccess file rather than mess with virual hosts, and for anyone who is on shared hosting, they won’t have access to this, so here is the .htaccess solution:

RewriteEngine On
RewriteRule ^$ /public/ [L,R=301]
Require all granted

This solved all my problems!

2 Likes