ddev
TYPO3 example?
I get in scheduler-log.txt
Uncaught TYPO3 Exception mysqli::real_connect(): Argument #1 ($hostname) must be of type ?string, false given thrown in file /var/www/html/vendor/doctrine/dbal/src/Driver/Mysqli/Driver.php in line 44
Tried with putting the context in it but still the same error
* * * * * cd /var/www/html && IS_DDEV_PROJECT=true TYPO3_CONTEXT=Development/DDEV vendor/bin/typo3 scheduler:run -vv | tee -a /var/www/html/scheduler-log.txt
Runs okay when executed from terminal manually.
The example in the README doesn't work adequately? https://github.com/ddev/ddev-cron#typo3-scheduler
Just checked another project, this is working fine:
* * * * * cd /var/www/html && IS_DDEV_PROJECT=true bin/typo3 scheduler:run -vv | tee -a /var/www/html/var/log/scheduler-log.txt
Cron runs without invoking a profile or anything, so that's a typical problem with it. There are examples all over the internet with people dealing with missing environment variables that they expect to be set, etc.
Ah, I note that some projects have moved typo3 from vendor/bin to /var/www/html/bin
I followed the Typo3 quickstart guide and tried the following command (take from the cron example) inside the web container:
$ IS_DDEV_PROJECT=true vendor/bin/typo3 scheduler:run -vv
In Application.php line 674:
[Symfony\Component\Console\Exception\NamespaceNotFoundException]
There are no commands defined in the "scheduler" namespace.
I found out that some additional information is needed to make it work with Solr. This is an example of my typo3.cron config:
* * * * * cd /var/www/html && TYPO3_CONTEXT=Development/DDEV DB_NAME=db DB_USER=db DB_PASSWORD=db DB_HOST=db SOLR_CORE_HOST=domain.ddev.site SOLR_CORE_PATH=core_nl SOLR_CORE_PORT=0000 SOLR_HOST_READ=domain.ddev.site SOLR_PATH_READ=/ IS_DDEV_PROJECT=true vendor/bin/typo3 scheduler:run -vv >> /var/www/html/scheduler-log.txt 2>&1
This works for me too, thanks. Perhaps the issue is indeed that the db variables etc. often are being read out via .env variables.
As @rfay said, cron run in its own little bubble, and does not inherit many of the typical user settings. This can lead to some long string passing through many ENV settings. The SOLR example above requires atleast 5 for its own settings in additional to the database.
We're happy to consider a PR. However, it would be unwise to start documenting every framework and addon permutation.
Perhaps a remark when using ENV variables for DB and other services like SOLR would be helpful in the documentation. I guess that would apply for more frameworks. Thanks for your work