Thanks for the prompt reply
I have already tries it before and went ahead again to amend the vhost to:
#
<VirtualHost *:80>
DocumentRoot /var/www/html/suitecrm8/public
<Directory /var/www/html/suitecrm8/public>
AllowOverride All
Order Allow,Deny
Allow from All
and of course restarted httpd. The result is still the same. It really puzzles me why the application does not fully launch with the menu bar and the possibility to logout. I also tried to change the vhost to listen on port 90 but the result is still the same
Kind regards
Harvey
When I run in the browser: phpinfo.php I note that all php-fpm is active. Below are all fastcgi directives:
Directive, Local Value, Master Value
cgi.discard_path: Off,Off
cgi.fix_pathinfo: On, On
cgi.force_redirect: On, On
|cgi.nph: Off, Off
cgi.redirect_status_env: no value, no value
cgi.rfc2616_headers: Off, Off
fastcgi.error_header: no value, no value
fastcgi.logging: On, On
fpm.config: no value.no value
On another note, I do apologise for some delay in my response. I am a 71 years old Australian and your message was received at 23:08 my time.
When I run in the browser: phpinfo.php I note that all php-fpm is active. Below are all fastcgi directives:
Directive, Local Value, Master Value
cgi.discard_path: Off,Off
cgi.fix_pathinfo: On, On
cgi.force_redirect: On, On
|cgi.nph: Off, Off
cgi.redirect_status_env: no value, no value
cgi.rfc2616_headers: Off, Off
fastcgi.error_header: no value, no value
fastcgi.logging: On, On
fpm.config: no value.no value
On another note, I do apologise for some delay in my response. I am a 71 years old Australian and your message was received at 23:08 my time.
Hi Clemente
Below is the vhost per recommendation in symphony for Apache/2.4.52. The problem still persist.
#
<VirtualHost *:80>
ServerName suitecrm8.local
ServerAlias ServerAlias www.suitecrm8.local
# Uncomment the following line to force Apache to pass the Authorization
# header to PHP: required for "basic_auth" under PHP-FPM and FastCGI
#
SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
# For Apache 2.4.9 or higher
# Using SetHandler avoids issues with using ProxyPassMatch in combination
# with mod_rewrite or mod_autoindex
<FilesMatch \.php$>
# SetHandler proxy:fcgi://127.0.0.1:9000
# for Unix sockets, Apache 2.4.10 or higher
SetHandler proxy:unix://usr/sbin/php-fpm|fcgi://dummy
</FilesMatch>
# If you use Apache version below 2.4.9 you must consider update or use this instead
# ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/var/www/project/public/$1
# If you run your Symfony application on a subpath of your document root, the
# regular expression must be changed accordingly:
# ProxyPassMatch ^/path-to-app/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/var/www/project/public/$1
DocumentRoot /var/www/html/suitecrm8/public
<Directory /var/www/html/suitecrm8/public>
# enable the .htaccess rewrites
AllowOverride All
Require all granted
</Directory>
# uncomment the following lines if you install assets as symlinks
or run into problems when compiling LESS/Sass/CoffeeScript assets
The configurations that you’ve sent seem ok. I’m probably missing something.
Maybe we could try a different approach. Are you familiar with using docker? Among other things, docker images streamline and make the server setup easier.
The following post by @jont_titmus has a link to a github repo with a docker setup for SuiteCRM 8, which Jon prepared and had the kindness of sharing with us.
I think this may help overcome the server setup issues.
Hope this helps, and again apologies for the delay
Unfortunately also the docker installation was unsuccessful. Below are the final part of the installation process:
Creating suitecrm_mysql_crm_1 … error
ERROR: for suitecrm_mysql_crm_1 Cannot start service mysql_crm: driver failed programming external connectivity on endpoint suitecrm_mysql_crm_1 (a1b06a29a82490565c0fac0d5d5a2e90cedeceb2608c1176281bdd204e20159c): Error starting userland prCreating suitecrm_suitecrm_1 … error
WARNING: Host is already in use by another container
ERROR: for suitecrm_suitecrm_1 Cannot start service suitecrm: driver failed programming external connectivity on endpoint suitecrm_suitecrm_1 (8b9d2740ceea06f8241d92d026de8635e1e98ced85c1129d8fbc504e2db78dcd): Error starting userland proxy: listen tcp4 0.0.0.0:80: bind: address already in use
ERROR: for mysql_crm Cannot start service mysql_crm: driver failed programming external connectivity on endpoint suitecrm_mysql_crm_1 (a1b06a29a82490565c0fac0d5d5a2e90cedeceb2608c1176281bdd204e20159c): Error starting userland proxy: listen tcp4 0.0.0.0:3306: bind: address already in use
ERROR: for suitecrm Cannot start service suitecrm: driver failed programming external connectivity on endpoint suitecrm_suitecrm_1 (8b9d2740ceea06f8241d92d026de8635e1e98ced85c1129d8fbc504e2db78dcd): Error starting userland proxy: listen tcp4 0.0.0.0:80: bind: address already in use
ERROR: Encountered errors while bringing up the project.
Regards
The above means that you would have to access suitecrm and the db ports defined above instead of the regular ones.
ex: https://localhost:8080
Please note that the port is only for usage from the host to docker. Between docker services you can use the default ones.
So you would use the following db configurations when setting up suitecrm:
dbhost: mysql_crm
dbport: 3306 (or just leave blank)
If you are able to successfully setup and use SuiteCRM with the above you could try to disable your host apache and mysql ( if they are not being used for anything else) and they set the ports on docker-compose.yml back to the default
I believe that I was able to trace the failure to launch SuiteCRM 8 on my Fedora 35 desktop to missing java scrips in the directory /var/www/html/SuiteCRM/public/legacy/cache/include/javascript. Could you please zip the content of that javascrips directory in a working SuiteCRM 8 desktop on Ubuntu or any other desktop where it works for you and email me that zip file.
I have already done all that but still a lot of scripts may be missing in the build under Fedora 35. I say that because I did the following:
firstly run as root the CLI command from within the SuiteCRM folder the command: ./bin/console suitecrm:app:install and responded to all the prompts.
When I launched via the browser in complained that all the directories /public/legacy should have the 755 permission. Once I changed the permission and re-checked all the complaints cleared except the complain that /public/legacy/cache/include/javascript/ is not yet with 755 permission. I had a look at the content of that directory and noted that quite a lot of scripts and subdirectories were added. Surprisingly not all of them had the 755 permission.
I then run on the folder only the command chmod -R 755 but it did not clear the complaint. Finally I run the command chmod -R u=rwx,g=rwx,o=rwx and it cleared the fault, however checking again the content of the javascript directory all its content vanished. The program did not launch at all.
All my efforts to reproduce the content of that directory in the same process failed.
When running the install via the browser it generates in that directory some 12 java script files but significantly less than what I saw earlier on.
For this reason I asked if I can get the content of the folder from a properly running system, may be on Ubuntu. I am pretty sure that adding this content to the /javascripts directory may resolve the issue.
Kind regards
Harvey
Hi Clemente
I believe I may have identified the problem that causes the Menu not to show after first login.
I checked all the installed file after performing browser installation and noted the it produces call to the following line: HTML/SUITECRM/PUBLIC/LEGACY/CACHE/SMARTY/TEMPLATES_C/%%0D^0D7^0D7245FD%%MYSUGAR.TPL.PHP
Obviously there is no line like that in the installation. I tried to reproduce the entire listing bu failed. I am pasting the snapshot that I saved into a text file:
yes, that is an auto-generated file. So it is likely that it differs between instances.
Small question, what is the user that apache runs under? www-data? apache?
For me this is still strange. At the moment I don’t see another reason for the cache folder to properly generated other than permissions. I’ll try to see if there is anything else.
PS: I’m sorry but in the next couple of days / week I’ll take longer to reply.
Dear Clemente
Thanks for the reply and the attached ZIP file.
I checked the content of the ZIP file and found that the same files were generated in my deployment on Fedora 35.
In my system apache runs under apache. I read again the webpage of Symphony that you directed me earlier on. Consequently I revised vhost. Below is the revised vhost in my httpd.conf:
#
<VirtualHost *:80>
ServerName SuiteCRM.local
ServerAlias www.SuiteCRM.local
DocumentRoot /var/www/html/SuiteCRM/public
DirectoryIndex /index.php
<Directory /var/www/SuiteCRM/public>
AllowOverride All
Order Allow,Deny
Allow from All
FallbackResource /index.php
</Directory>
# uncomment the following lines if you install assets as symlinks
# or run into problems when compiling LESS/Sass/CoffeeScript assets
<Directory /var/www/html/SuiteCRM>
Options FollowSymlinks
</Directory>
ErrorLog /var/log/suitecrm_error.log
CustomLog /var/log/suitecrm_access.log combined
Hi Clemente
On further investigation, could you please check the file /SuiteCRM/public/legacy/include/javascript/yui/built/menu/menu.js
I read the following text included in lines 256-272:
There is an inconsistency between Firefox for Mac OS X and
Firefox Windows & Linux regarding the triggering of the
display of the browser’s context menu and the subsequent
firing of the “click” event. In Firefox for Windows & Linux,
when the user triggers the display of the browser’s context
menu the “click” event also fires for the document object,
even though the “click” event did not fire for the element
that was the original target of the “contextmenu” event.
This is unique to Firefox on Windows & Linux. For all
other A-Grade browsers, including Firefox for Mac OS X, the
“click” event doesn’t fire for the document object.
This bug in Firefox for Windows affects Menu, as Menu
instances listen for events at the document level and
dispatches Custom Events of the same name. Therefore users
of Menu will get an unwanted firing of the "click"
custom event. The following line fixes this bug.
May be in the case of my Fedora 35 and vhost configuration it does not fix the bug and therefore the menu does not appear.
Kind regards
Harvey