[SOLVED] Several typo3 CLI calls are failing

Hi all,

TYPO3 12.4,
upgraded in sequence started at 7.6 long ago :slight_smile:
not composer based install, “old school” = curl-ing current typo3 src gz, unpack, and change symbolic link to typo3_src.
Everything working as expected, all “green” in Backend.

But I detected after removing some stuff I don’t need anymore that I’ve some orphaned records, shown in Backend System->DB Check->Database Relations.

ChatGPT mentions some Backend web based cleanup commands, can’t find, maybe AI fantasy :wink:

But found the docs about “lowlevel” extension: Command line — Low Level 12.4 documentation and there the option cleanup:orphanrecords.

Following this doc I can see that the CLI util itself works, but not as expected:

Testing 1st itself shows:

vserver:/srv/www/htdocs/typo3root/typo3_src/typo3/sysext/core/bin # ./typo3 
TYPO3 CMS 12.4.27 (Application Context: Production) - PHP 8.2.28

Usage:
  command [options] [arguments]

Options:
  -h, --help            Display help for the given command. When no command is given display help for the list command
  -q, --quiet           Do not output any message
  -V, --version         Display this application version
      --ansi|--no-ansi  Force (or disable --no-ansi) ANSI output
  -n, --no-interaction  Do not ask any interactive question
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Available commands:
  list                   Lists commands
  help                   Displays help for a command
  dumpautoload           [extensionmanager:extension:dumpclassloadinginformation|extension:dumpclassloadinginformation] Updates class loading information in non-composer mode.
  setup                  Setup TYPO3 via CLI.
 backend
  backend:user:create    Create a backend user
  backend:lock           Lock the TYPO3 Backend
  backend:resetpassword  Trigger a password reset for a backend user
  backend:unlock         Unlock the TYPO3 Backend
 cache
  cache:warmup           Cache warmup for all, system or, if implemented, frontend caches.
  cache:flush            Cache clearing for all, system or frontend caches.
 extension
  extension:list         Shows the list of extensions available to the system
  extension:setup        Set up extensions
 language
  language:update        Update the language files of all activated extensions
 mailer
  mailer:spool:send      [swiftmailer:spool:send] Sends emails from the spool
 messenger
  messenger:consume      Consume messages
 referenceindex
  referenceindex:update  Update the reference index of TYPO3
 site
  site:list              Shows the list of sites available to the system
  site:show              Shows the configuration of the specified site
 upgrade
  upgrade:run            Run upgrade wizard. Without arguments all available wiz

But nearly anything else, “meaningful”, fails or is incomplete:

./typo3 extension:list shows just a small subset of all extensions. FYI not that many, small private site.

./typo3 site:list shows “no sites”, although there are 2.

The desired clean orphan records fails completely:

vserver:/srv/www/htdocs/typo3root/typo3_src/typo3/sysext/core/bin # ./typo3 cleanup:orphanrecords -vv --dry-run

Uncaught TYPO3 Exception Too few arguments to function TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserFactory::__construct(), 0 passed in /srv/www/typo3_src-12.4.27/typo3/sysext/core/Classes/Utility/GeneralUtility.php on line 2985 and exactly 2 expected
thrown in file /srv/www/typo3_src-12.4.27/typo3/sysext/core/Classes/DataHandling/SoftReference/SoftReferenceParserFactory.php
in line 33

Searching here in forum I’ve found this at 1st seeming similar post: Error updating extensions for typo3 v 13.1.1
Similar, as exactly the same error message I’m getting, but if I do what @kentingey asked, typo3 referenceindex:update, I’m NOT getting the “Too few arguments” error but:

vserver:/srv/www/htdocs/typo3root/typo3_src/typo3/sysext/core/bin # ./typo3 referenceindex:update

In ConnectionPool.php line 143:
                                                                              
  The requested database connection named "Default" has not been configured.  
                                                                              

referenceindex:update [-c|--check]

And also when following @mabolek 's hint for cache:flush I’m getting the “database connection not configured” error above.

Which is NOT the case in general, as of course my Database connection “Default” is configured and unchanged since ~2015/16, settings are correctly defined in typo3conf/system/settings.php. As said, in Backend everything is working… would be difficult without a valid DB connection :smiley: In Backend, I can delete / flush etc. all caches, and did this before and while trying the CLI as described.

Any hints why the CLI does not “recognize” the DB Connection, and producing the Too few arguments errors?

Hi @michaelof!

Welcome to talk.typo3.org and thank you for the in-depth description of your issue.

I haven’t been running CLI commands on TYPO3 sites in Classic mode for a while, but my first suggestion would be to try to run the scripts from the TYPO3 root folder. As far as I can see, you are changing directory and running the script within ...typo3_src/typo3/sysext/core/bin.

Try changing directory to (what looks like) the root directory with cd /srv/www/htdocs/typo3root and running it with typo3_src/typo3/sysext/core/bin/typo3.

PS! I can very warmly recommend migrating your site to Composer. :slightly_smiling_face:

Hi @mabolek thanks for the welcome and thank you very much for helping!!!

With the help of chatGPT “we”'ve been already in the path anchor discussion, and I’ve tried more or less ALL paths, absolute and relative EXCEPT the you are suggesting :smiley:

Follwing your hint I’m getting now a different error:

vserver:/srv/www/htdocs/typo3root # ./typo3_src/typo3/sysext/core/bin/typo3 referenceindex:update 

In ExceptionConverter.php line 101:
                                                                                                   
  An exception occurred in the driver: Access denied for user ''@'localhost' (using password: NO)  
                                                                                                   

In ConnectionFailed.php line 34:
                                                              
  Access denied for user ''@'localhost' (using password: NO)  
                                                              

In Driver.php line 44:
                                                              
  Access denied for user ''@'localhost' (using password: NO)  
                                                              

referenceindex:update [-c|--check]

which makes more than sense from a security perspective, not allowing anyone, even if he’s “root”, to perform TYPO3-internal tasks.

But it leads me to the next subsequent question: How, if possible, can I pass a Backend user and his pw, or establish a backend user session, as a context, if possible?

As -h says nothing about this, I’ve tried the “usual suspects” like -u / --user, -pw, all didn’t work.

So what happens here is that the TYPO3 CLI in your case cannot properly resolve the configuration (“settings.php” or “additional.php”).

This can happen if you are not inside the actual path line of the directory structure. You must be inside the structure that is referenced for your DOCUMENT_ROOT of the webserver. You must NOT be inside the actual source directory, but use the symlink directory.

Can you tell your exact directory setup? Where you have symlinked what, what your DOCUMENT_ROOT is set to? For my instance for example, it would be:

  /var/www/html/public/typo3_src/typo3/sysext/core/bin/typo3

and NOT:

  /var/www/html/typo3_src-13.4.0/typo3/sysext/core/bin/typo3

Note the extra public here, my DOCUMENT_ROOT is /var/www/html/public/ and typo3_src inside that directory is a symlink to ../typo3_src-13.4.0.

The errors stem from the fact that the DB credentials entered into the configuration file are not resolved in your case, thus they fallback to empty values. You could also specify all the credentials via ENV settings, but the proper way to deal with this would be to ensure the proper directory context to let TYPO3 properly detect the file.

BTW: If you maybe have a customized settings.php or additional.php that does credential loading depending on values not available in the CLI call, that could be an issue, too.

HTH!

1 Like

@ghi Also to you thank you very much for helping!

And… from today on you’re my TYPO3 HERO!

My DocumentRoot is /srv/www/htdocs/typo3root, set in an Apache’s VHOST definition by me. That folder also has been the “anchor” folder when I followed @mabolek’s hint above.

The symlinks you can see below, I’ve upgraded TYPO3 yesterday to the newest 12.4.30, to be sure not to waste anyone’s time by using an older version with a maybe relevant already fixed bug :slight_smile:

vserver:/srv/www/htdocs/typo3root # ls -l
insgesamt 52
drwxr-xr-x  7 wwwrun www   4096 14. Mai 15:44 fileadmin
-rw-r--r--  1 root   root 15092 21. Apr 2023  .htaccess
-rw-rw----  1 wwwrun www  13770 17. Mär 2020  .htaccess.10X
lrwxrwxrwx  1 wwwrun www     19 16. Dez 2016  index.php -> typo3_src/index.php
-rw-r--r--  1 wwwrun www    118 28. Sep 2020  robots.txt
lrwxrwxrwx  1 wwwrun www     15 16. Dez 2016  typo3 -> typo3_src/typo3
drwxr-xr-x  7 wwwrun www   4096 12. Mär 2024  typo3conf
lrwxrwxrwx  1 root   root    26 14. Mai 19:37 typo3_src -> /srv/www/typo3_src-12.4.30
drwxrws---  4 wwwrun www   4096 12. Mär 2024  typo3temp
drwxr-xr-x 14 wwwrun www   4096 17. Mär 2020  uploads

That was, as you can see on the time stamps, the suggested best practice, at least in the German book “Praxiswissen TYPO3 CMS 7 LTS”, which I’ve read with great fun in 2016 :slight_smile:

You mentioned

“You must NOT be inside the actual source directory, but use the symlink directory.”

And as you can see there are 2 symlinks:

  • One, from 2016, for typo3 -> typo3_src/typo3, so never changing.
  • And the one I was only thinking about, I’ve forgot the other one, was the always with a new release changing typo3_src -> /srv/www/typo3_src-12.4.30.

Means:

There are three possibilities to call the same typo3/sysext/core/bin/typo3 CLI utility, not only 2 as I thought before:

  1. /srv/www/typo3_src-12.4.30/typo3/sysext/core/bin/typo3: WRONG, canonical path, not the symbolic link
  2. /srv/www/htdocs/typo3root/typo3_src/typo3/sysext/core/bin/typo3: WRONG: symbolic link, but the wrong one :slight_smile:
  3. /srv/www/htdocs/typo3root/typo3/sysext/core/bin/typo3: CORRECT path for CLI!

With now knowing this, typo3 -h CLI show all missing before options. And can be used, none of the above errors aymore, THANKS!!!

Maybe of interest to all and to @mabolek as he mentioned it in his post: As long as your are, absolute or relative, wherever within the correct path (3), you call call the typo3 CLI utility as you want.
E.g. vserver:/srv/www/htdocs/typo3root/typo3/sysext/core # bin/typo3 referenceindex:update will work, vserver:/srv/www/htdocs/typo3root/typo3/sysext # core/bin/typo3 referenceindex:update either, etc.

Summary: Learned a lot! My errors above issue is [SOLVED].

P.S.: I’m now able to see that I’ve another, subsequent issue, but this is independent of the above, I’ll open a new topic :slight_smile:

1 Like

Awesome, that was a great group effort, and thanks to your detailed response, it will hopefully also help others in the future! :slight_smile: