7.10 upgrade "Composer autoloader not found"

English Language - Forum šŸ“¦ Install & Upgrade Help
33

Hmmm. Well at least some modules were definitely installed as deps based on the install docs and installer checks when running install from zip. The ones currently installed are:

  • json
  • xml
  • mbstring
  • zip
  • curl
  • gd
  • mysql
  • imap

So maybe although I installed composer it is not finding the installed modules (maybe looking in a different PHP version or something strange).

root@suitecrm:/opt/apps/suitecrm# ls -1 /etc/php/7.2/mods-available/
calendar.ini
ctype.ini
curl.ini
dom.ini
exif.ini
fileinfo.ini
ftp.ini
gd.ini
gettext.ini
iconv.ini
imap.ini
json.ini
mbstring.ini
mysqli.ini
mysqlnd.ini
opcache.ini
pdo.ini
pdo_mysql.ini
phar.ini
posix.ini
readline.ini
shmop.ini
simplexml.ini
sockets.ini
sysvmsg.ini
sysvsem.ini
sysvshm.ini
tokenizer.ini
wddx.ini
xml.ini
xmlreader.ini
xmlwriter.ini
xsl.ini
zip.ini

FWIW there is only one version of php installed on this machine (7.2).

root@suitecrm:/opt/apps/suitecrm# ls -1 /etc/php/
7.2

But maybe it is just the intl module that is missing and causing the problem? I triple checked module requirements when doing the original install and the installer didnā€™t complain in its checks (complained about other missing modules which I added later).

So it sounds like installing the composer package is a requirement for running command line updater?

I was just following the docs which said to run the robo scriptā€¦but that generated an error which started this issueā€¦

Could not find autoloader. Run ā€˜composer installā€™

And running composer install manually is also a requirement for command line updater?

And it sounds like you are saying composer install is not working because composer is not finding the intl php module?

Just want to make sure I understand you before I go down that rabbit hole. Thanks.

34

So, even if you have only one PHP version, you probably have two PHP ā€œenginesā€: web server and command-line (CLI).

What youā€™re seeing is consistent with missing PHP modules on the CLI side only (which is what composer uses, but not what the SuiteCRM app uses).

Typing php -i from the command-line gives you the report for CLI, check your modules there.

Downloading from inside the app, in Admin / Diagnostics / phpinfo, gives you the ā€œotherā€ PHP, web server.

35

Running php -i shows the same php modules as the web side shows. Indeed I think this is just about the missing intl module you pointed out which is not documented as required on the install page, upgrade page or checked as a required module by the SuiteCRM installer.

So I installed the intl module package (single ubuntu package apparently installs module for both CLI and web side) and tried again.

root@suitecrm:/opt/apps/suitecrm# php ./vendor/bin/robo upgrade:suite /tmp/SuiteCRM-Upgrade-7.11.x-to-7.11.20.zip ./upgrade.log . mattp
Could not find autoloader. Run 'composer install'.root@suitecrm:/opt/apps/suitecrm# ^C
root@suitecrm:/opt/apps/suitecrm# sudo -u www-data composer install
Cannot create cache directory /var/www/.composer/cache/repo/https---repo.packagist.org/, or directory is not writable. Proceeding without cache
Cannot create cache directory /var/www/.composer/cache/files/, or directory is not writable. Proceeding without cache
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.
Package facebook/webdriver is abandoned, you should avoid using it. Use php-webdriver/webdriver instead.
Package flow/jsonpath is abandoned, you should avoid using it. Use softcreatr/jsonpath instead.
Package fzaninotto/faker is abandoned, you should avoid using it. No replacement was suggested.
Package guzzlehttp/ringphp is abandoned, you should avoid using it. No replacement was suggested.
Package guzzlehttp/streams is abandoned, you should avoid using it. No replacement was suggested.
Package leafo/scssphp is abandoned, you should avoid using it. Use scssphp/scssphp instead.
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.
Package phpunit/phpunit-mock-objects is abandoned, you should avoid using it. No replacement was suggested.
Generating optimized autoload files
Deprecation Notice: Class Zend_Validate_Barcode_IntelligentMail located in ./vendor/zf1/zend-validate/library/Zend/Validate/Barcode/Intelligentmail.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in /usr/share/php/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class Zend_Gdata_Analytics_Goal located in ./vendor/zf1/zend-gdata/library/Zend/Gdata/Analytics/Extension/Goal.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in /usr/share/php/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class Flow\JSONPath\Test\JSONPathBenchmarks located in ./vendor/flow/jsonpath/tests/JSONPathBenchmarks.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in /usr/share/php/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class Flow\JSONPath\Test\JSONPathTest located in ./vendor/flow/jsonpath/tests/JSONPathTest.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in /usr/share/php/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class Flow\JSONPath\Test\JSONPathTestClass located in ./vendor/flow/jsonpath/tests/JSONPathTest.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in /usr/share/php/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class Flow\JSONPath\Test\JSONPathLexerTest located in ./vendor/flow/jsonpath/tests/JSONPathLexerTest.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in /usr/share/php/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class Flow\JSONPath\Test\JSONPathArrayAccessTest located in ./vendor/flow/jsonpath/tests/JSONPathArrayAccessTest.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in /usr/share/php/Composer/Autoload/ClassMapGenerator.php:201
Carbon 1 is deprecated, see how to migrate to Carbon 2.
https://carbon.nesbot.com/docs/#api-carbon-2
    You can run './vendor/bin/upgrade-carbon' to get help in updating carbon and other frameworks and libraries that depend on it.
34 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> rm -Rf vendor/elasticsearch/elasticsearch/tests/Elasticsearch/Tests
> mv vendor/google/apiclient-services/src/Google/Service/Calendar* vendor/google/apiclient-services/src/Google/
> rm -Rf vendor/google/apiclient-services/src/Google/Service/*
> mv vendor/google/apiclient-services/src/Google/Calendar* vendor/google/apiclient-services/src/Google/Service/
root@suitecrm:/opt/apps/suitecrm#
root@suitecrm:/opt/apps/suitecrm# sudo -u www-data php ./vendor/bin/robo upgrade:suite /tmp/SuiteCRM-Upgrade-7.11.x-to-7.11.20.zip ./upgrade.log . mattp
Could not find autoloader. Run 'composer install'.root@suitecrm:/opt/apps/suitecrm#
root@suitecrm:/opt/apps/suitecrm#

As you can see the error

Could not find autoloader. Run ā€˜composer installā€™

Is still there when trying to run the upgrade.

Running composer install now runs without error (because missing intl module is now installed).

However this doesnā€™t resolve the issue: Could not find autoloader. when trying to run the upgrade.

36

Strange. Do you have a autoload.php file in vendor directory? Is it readable, does it have proper ownership and permissions?

37

Yep.

root@suitecrm:/opt/apps/suitecrm# ls -lha ./vendor/autoload.php
-rw-rw---- 1 www-data www-data 178 Nov  5  2020 ./vendor/autoload.php
  • File is there
  • owner is www-data like the rest
  • perms are 660 like the rest of the files as I mentioned above.

Normally I donā€™t grant +x to php files as they just need to be read by webserver and not treated as stand-alone executables. Scripts can always be run by invoking php /path/to/read-but-not-execute-script.php.

However it is possible that the way your update process is constructed, it relies on specific php files having execute permissions (thatā€™s not the error message, but could be the underlying problem)? If so it would be great to have a list of SuiteCRM files that need execute permissions in the docs so we can keep the filesystem permissions as locked down as possible (ie not making every php file executable).

38

So the obvious thing here is just to look at the code.

This doesnā€™t appear to have anything to do with permissions but rather that ./vendor/bin/robo is not looking in the right place for autoload.php. I hadnā€™t modified these files so this is either a bug that no one else is running into (no one using command line upgrade?) or something weird about my OS/php install in terms of how __DIR__ is defined.

./vendor/bin/robo

ā€¦has at the top:

//  Non-phar autoloader paths
$candidates = [
    __DIR__.'/vendor/autoload.php',
    __DIR__.'/../../autoload.php',
];

I donā€™t know what phar isā€¦but since I am running robo from command line I guess it shouldnā€™t apply.

So a simple thing to do is check what __DIR__ is so I added echo '__DIR__: '.__DIR__; after the $candidates declaration and tried to run the robo upgrade againā€¦

root@suitecrm:/opt/apps/suitecrm# sudo -u www-data php ./vendor/bin/robo upgrade:suite /tmp/SuiteCRM-Upgrade-7.11.x-to-7.11.20.zip ./upgrade.log . mattp
__DIR__: /opt/apps/suitecrm/vendor/binCould not find autoloader. Run 'composer install'.root@suitecrm:/opt/apps/suitecrm#

The output: __DIR__: /opt/apps/suitecrm/vendor/bin
implies that the $candidates are resolving to:

  • /opt/apps/suitecrm/vendor/bin/vendor/autoload.php
  • /opt/apps/suitecrm/vendor/bin/../../autoload.php (/opt/apps/suitecrm/autoload.php after resolving /../../)

Neither of these paths are correct.

Updating $candidates to add the correct search path for autoload.php (the third entry)ā€¦

$candidates = [
    __DIR__.'/vendor/autoload.php',
    __DIR__.'/../../autoload.php',
    __DIR__.'/../autoload.php',
];

and running againā€¦

root@suitecrm:/opt/apps/suitecrm# sudo -u www-data php ./vendor/bin/robo upgrade:suite /tmp/SuiteCRM-Upgrade-7.11.x-to-7.11.20.zip ./upgrade.log . mattp
āžœ  Upgrade SuiteCRM
 [Exec] Running php modules/UpgradeWizard/silentUpgrade.php /tmp/SuiteCRM-Upgrade-7.11.x-to-7.11.20.zip ./upgrade.log . mattp

********************************************************************
***************This Upgrade process may take sometime***************
********************************************************************

PHP Notice:  Array to string conversion in /opt/apps/suitecrm/include/database/DBManager.php on line 887

...

********************************************************************
*************************** SUCCESS*********************************
********************************************************************
******** If your pre-upgrade Leads data is not showing  ************
******** Or you see errors in detailview subpanels  ****************
************* In order to resolve them  ****************************
******** Log into application as Administrator  ********************
******** Go to Admin panel  ****************************************
******** Run Repair -> Rebuild Relationships  **********************
********************************************************************
 [Exec] Done in 30.202s
āžœ  Upgrade Complete!
root@suitecrm:/opt/apps/suitecrm#

So is this a bug in robo? If so is no one else upgrading their SuiteCRM installs via command line in order to get security patches?

Or is this some artifact of my OS/install/config. As I mentioned earlier my install is pretty basic. Unzip. Set owner/group. Set folder perms, set file perms.

root@suitecrm:/opt/apps/suitecrm# uname -a
Linux suitecrm.<redacted> 5.4.0-74-generic #83-Ubuntu SMP Sat May 8 02:35:39 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
root@suitecrm:/opt/apps/suitecrm# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
root@suitecrm:/opt/apps/suitecrm#
39

EDIT: I missed a crucial negative in this first sentence wrong so I edited it :point_down:

I think youā€™re right, the PHP files DONā€™T need executable permission. But it is true that 99% of installations out there (including mine) have that bit set, thatā€™s how the recommended permissions are proposed. So there might be something unexpected, or less tested, happening here. A simple way to test it is to add those permissions and see if the operation succeeds.

Watch out for execute permissions on directories - those are needed to traverse the directory.

Something like this could help:

find /path/to/base/dir -type d -exec chmod 2750 {} +

40

I tend to be very cautious following install guides with blanket permissions. PHP files shouldnā€™t need execute bit unless you want to run them directly as a script using the shebang to specify the interpreter.

root@suitecrm:/opt/apps/suitecrm# head -n1 vendor/bin/robo
#!/usr/bin/env php

If you arenā€™t regularly running these as scripts (e.g. from CLI rather than webserver) then there is no need for that shortcut and you can just specify the interpreter and the execute bit isnā€™t needed on the php script (e.g. php /path/to/no-execute-script.php.

I would guess the only time you would need execute permissions would be if you had a php script you ran (e.g. robo) that was trying to execute another php script (not include) as a separate process by invoking the script name directly without specifying the php interpreter as the binary before the script path.

As I mentioned earlier, I generally use find to apply permissions because files and directories need different treatment. As you noted directories DO need execute permission for listing/traversal. Our SuiteCRM setup currently uses 660 on files and 2770 on directories and this works fine. By the way the reason for permissive group permissions and the setgid on directories is because we have SFTP users that are added to the group and need to be able to read/write/create files. Files created need to belong to same group so webserver can still read them and vice versa. Often we use a different group than www-data something like suitecrm-admins which will include any suitecrm SFTP users as well as the webserver user. On fully provisioned, no manual editing setups, then webserver user is the only one that needs any access.

I think we were posting at the same time. This turns out to have nothing to do with permissions and is a bug with path resolution for autoload.php in the robo script.

41

Just answering my own questions from earlier for anyone else with this problem.

  • installing composer package is not necessary if you like to keep unneeded packages off your production systems.
  • Running composer install is NOT necessary either, the error message is misleading. You just need to fix the paths in robo script so it can find autoload.php.
  • Installing the intl php module is apparently also not necessary. Yes it is needed if you want to run composer install but it is apparently not needed for install or upgrades of the system.
    • It is NOT listed on the recommended packages list in the install guide.
    • When you first install from zip, the installer php script also checks for missing modules and does not complain about missing intl php moduleā€¦so it is apparently not needed.
1 Like
42

I edited my post above, I meant to write that execute bit should NOT be needed, thatā€™s why I said ā€œI think youā€™re rightā€ :man_facepalming:

Anyway, remember that SuiteCRM does a lot of stuff from CLI: all the Scheduler Jobs, so thatā€™s Workflows, search indexing, notifications, email campaignsā€¦

Thanks for your notes on Composer, I also think that some of these error messages are red herrings, itā€™s supposed to work in a much easier way.

43

Okay. So far I havenā€™t seen any errorsā€¦depends on how they are being run whether they need the execute bit or not. If there was a list of X,Y,Z are CLI apps rather than included scripts and need +x permission because they are run directly as sub-processes without invoking the php binary firstā€¦that would be great. It doesnā€™t give me a good feeling to blanket execute permissions across all php files ā€œjust in caseā€.

In terms of the bug(s)ā€¦

sounds like the back/cancel button issue in the UI has been noted already.

What is the best way to report the path issue with robo so it can be fixed?

Any thoughts on why I seem to be the only one running into this? Some breaking change to how __DIR__ works in PHP7.2 on Ubuntu 20? Or just no one using the command line upgrader?

44

  1. The Docs site is like a wiki, it can be edited by everybody.

  2. Iā€™d say few people use the command-line upgrader. Still, there might be some additional condition underlying your problemā€¦

45

Okay. If I run into errors and figure out that specific php files do need executable permission I will update the docs. Until then, Iā€™ll stick with 660 on the php files since it seems to work fine.

Okay well there isnā€™t much room for interpretation of code. There are 2 search paths to autoload.php configured in robo and they both use __DIR__ to construct the paths. The paths constructed are both wrong. So either the configured paths in robo are wrong (bug) or something about how PHP defines __DIR__ has changed (also bug) or autoload.php is in the wrong location (also bug). I canā€™t imagine what other underlying condition could possibly have any influence on this problem since we are down to a couple lines of code that are quite easy to understand. Once I fix the path to autoload.php in robo the installer works fineā€¦so this is not a permissions issue.

Would be nice to get this fixed so I donā€™t have to patch robo every time I want to do a security update of SuiteCRM. I can open a pull request but it will be very naive because I donā€™t know any history or context about why those 2 paths are there in the first place and whether they are still relevant in any valid scenarios. The PR would either delete one /../ from the second search path or add a third search path as in the example I posted above. But as I said, no idea how this was intended to work, so given this is a small change and a bug rather than an enhancementā€¦probably better to report it and leave it with a maintainer that actually has the context on how this is supposed to work.

46

I canā€™t find these references, can you please point me to where youā€™re seeing them?

47

Sorry, I thought that was clear earlier. This is at the beginning of the ./vendor/bin/robo file that we are instructed to run for command line upgrade.

root@suitecrm:/opt/apps/suitecrm# tail -n +18 ./vendor/bin/robo | head -n 5
//  Non-phar autoloader paths
$candidates = [
    __DIR__.'/vendor/autoload.php',
    __DIR__.'/../../autoload.php',
];
root@suitecrm:/opt/apps/suitecrm#

In terms of where this lives in gitā€¦that I donā€™t know as I am not a PHP dev (donā€™t know build processes or toolchains) and from a quick search it appears the robo file is generated or at least is not part of the main SuiteCRM repo.

48

All the stuff under vendor directory is 3rd party, it is not stored in our git.

The basic process SalesAgility uses to build the upgrade packages is to grab our code from Github, then pull all that vendor code in with composer, and zips it along with a few additional scripts (if needed).

So Iā€™m not entirely sure why robo code would be expecting something that it canā€™t find in your installation (or perhaps in all SuiteCRM installations, but I donā€™t think that is the case). Unless our upgrade script changes working directory and confuses Robo?.. but that seems impossible, the problem is right at the beginning of Robo executionā€¦

49

Okay. I just searched ā€œphp roboā€ and found what looks like the repo you are using this from.

That project doesnā€™t provide autoload.php. Apparently autoload.php is generated by composer. I donā€™t know which composer on which project whether it is SuiteCRM or the robo project. Nevertheless it ends up in the wrong place. Either because the composer build puts it in the wrong place, or because it is put in the wrong place when SalesAgility zips up the vendor stuff.

root@suitecrm:/opt/apps/suitecrm# cat ./vendor/autoload.php
<?php

// autoload.php @generated by Composer

require_once __DIR__ . '/composer/autoload_real.php';

return ComposerAutoloaderInit2fc157eb6d5975feb720ea30cee02ec2::getLoader();

As I said this is the zip from you guys and I havenā€™t modified itā€¦so pretty sure command line upgrade is broken for everyone.

It is easy enough to check. The code isnā€™t doing much here. Just download a zip, extract it, check the vendors folder. Is autoload.php at ./vendors/autoload.php? If yes then the command line upgrade is broken for you too. Try running a command line upgrade on a zip (non-git) install following the docs.

The paths in the upstream robo repo I linked match what I see in my zip from you guys. So I guess autoload.php is being put in the wrong place by whatever composer builds it, or the vendor folder building process.

As you said you donā€™t think many people are using command line upgradeā€¦so perhaps this is just broken and no one noticed.

50

Okay, decided to run my own test.

You are right, there is no ./vendor/ folder in the normal install zip.

So this must have been created when I tried to first run the Upgrade in the UI upgrade wizard (which failed, was broken).

So I guess to reproduce this you have to go half-way through a UI upgrade (upload upgrade package and then bail) and then cancel and then check the vendors folder. I will need to do a fresh install to try to repo againā€¦but part of the reason I am confused in the followingā€¦

The command line upgrade instructions say to run ./vendor/bin/robo ...ā€¦ but as you pointed out, the vendor folder isnā€™t there on a new installā€¦so you canā€™t do a command line upgrade. It never occurred to me that the vendor folder might not be there on a fresh install since it was there when I was following the command line upgrade instructions the first time (after the UI upgrade failed).

Different question thenā€¦ is it possible to run a command line upgrade from a new install or only use the command line upgrade after you have done at least one UI upgrade? Once I understand this better I will happily update the docs to reflect the reality. Thanks!

51

The initial installer (full download) has a vendor directory, with autoload.php there.

Then the Upgrader zips are diffs, so they might have nothing in vendor, or they might have a lot of stuff (but never everything).

It is possible that you are getting an upgrade problem, because of some problem in the original installation you did, perhaps a long time agoā€¦

I donā€™t think I said thatā€¦ I said there was a vendor directory. And I just checked.

52

Sorry, I misunderstood you. I downloaded the zip, extracted it and saw there was no vendor directory.

Install Zip Download and Inspect 
root@suitecrm:/opt/apps/suitecrm# mkdir /tmp/SuiteCRM-Test
root@suitecrm:/opt/apps/suitecrm# wget -O /tmp/SuiteCRM-Test/SuiteCRM-v7.11.20.zip "https://github.com/salesagility/SuiteCRM/archive/refs/tags/v7.11.20.zip"
...
root@suitecrm:/opt/apps/suitecrm# pushd /tmp/SuiteCRM-Test/
root@suitecrm:/tmp/SuiteCRM-Test# unzip SuiteCRM-v7.11.20.zip
...
root@suitecrm:/tmp/SuiteCRM-Test# ls -1 SuiteCRM-7.11.20/
Api
campaign_tracker.php
composer.json
composer.lock
cron.php
crossdomain.xml
custom
data
deprecated.php
dictionary.php
download.php
emailmandelivery.php
export.php
files.md5
HandleAjaxCall.php
ical_server.php
include
index.php
install
install.php
json_server.php
jssource
lib
LICENSE.txt
log_file_restricted.html
maintenance.php
metadata
ModuleInstall
modules
pdf.php
phpcs.xml
php_version.php
README.md
RoboFile.php
robots.txt
run_job.php
service
soap
soap.php
SugarSecurity.php
sugar_version.json
sugar_version.php
suitecrm_version.php
themes
TreeData.php
upload
vcal_server.php
vCard.php
XTemplate
Zend
root@suitecrm:/tmp/SuiteCRM-Test#

Thank you for the explanation that the vendor folder is generated by running the installer, that gives me a more specific place to look in the source tree for this problem.

I have this problem on two different (independent boxes) that were both fresh installs from zip from 7.11.18 in the last months. One of them I had a bunch of UX/db problems with the installer (error messages not surfacing). The second one didnā€™t have any issues as I knew the issues from the first time around. Point is there wasnā€™t anything weird that happened during the install. I just realized it canā€™t related to the broken UI upgrade because the second box I didnā€™t try the UI upgradeā€¦I went straight for the command line updater and it had the same issue.

So I would be surprised if this was something weird about my installs as they are just extracted zips with the installer run. Nevertheless I guess I need to try and track the problem down in your installer or make a screencap repro or something if you canā€™t reproduce this on your end.

What I did see already searching the SuiteCRM repo for ā€œautoload.phpā€ is that there are quite a few references to that file being located at ./vendor/autoload.phpā€¦which is indeed where it is locatedā€¦but that doesnā€™t work with the autoload search paths in the third party robo script. So I suspect that the autoload.php is in the expected place from SuiteCRMā€™s point of view but there is some incompatibility with where SuiteCRM wants that file to be and where the third party robo script wants that to be.

Maybe you could look at one of your installs for comparison? Is autoload.php located in ./vendor/? If so does running a command line upgrade work for you? You donā€™t need to run an actual update (give a non-existent upgrade zip name) to see if robo finds autoload or errors out with the message about running composer install.

sudo -u <webserver-user> php ./vendor/bin/robo upgrade:suite /tmp/this-file-doesnt-exist.zip ./upgrade.log . <suitecrm-admin-user>

I understand if you donā€™t have time to try and repro on your end. In that case I will just try to track down the installer code.

But at this pointā€¦

  • I am pretty sure that ./vendor/autoload.php is in the place SuiteCRM expects it to be
    • due to multiple references to that location in the SuiteCRM git tree
  • I am very confident that robo is looking in the wrong paths to find ./vendor/autoload.php
    • robo git repo matches what I have on disk
    • fixing the paths in robo to point to where SuiteCRM has autoload.php resolves the issue

So the more interesting question is what else is going on (different) that causes me to experience this and others not. Perhapsā€¦

  • how robo is being run
    • e.g. I donā€™t know what ā€œpharā€ isā€¦but it results in a different search approach for autoload.php.
  • composer install related stuff
    • maybe people running composer end up generating an additional autoload.php somewhere that robo can find it?

Iā€™m assuming others use the command line upgrader and donā€™t experience this issue and that you canā€™t reproduce/verify this issue on your own suitecrm installs.