t3ext-ig_ldap_sso_auth
t3ext-ig_ldap_sso_auth copied to clipboard
xperseguers
Error when importing users with the scheduler
Hi,
I'm using Typo3 10.4.28 and ig_ldap_sso_auth 3.7.0. Importing users using the backend module works fine as expected with my current configuration. However, if I try to import users using the scheduler task, I get the following error:
Call to undefined method Doctrine\DBAL\Driver\Mysqli\MysqliStatement::fetchFirstColumn()
in /var/www/html/sdesw/intranetdrp.qc/typo3conf/ext/ig_ldap_sso_auth/Classes/Domain/Repository/Typo3UserRepository.php line 280
The fetchFirstColumn method is also used at line 334 if users are to be deleted instead of disabled.
I'm trying to find an equivalent method that would still return the uids that will be disabled/deleted.
Check, if you are you using the same PHP version for the CLI and the apache module. Using different versions can result in different symfony packages in composer.
I checked my server and I seem to have only one PHP version installed (7.4.29)
I replaced the fetchFirstColumn() call in Typo3UserRepository with fetchAll(\PDO::FETCH_COLUMN). It seems to return an equivalent result. I still don't understand why fetchFirstColumn() si not found though.
Can you check in your root composer.lock that you have this?
{
"name": "doctrine/dbal",
"version": "2.13.9",
"source": {
"type": "git",
"url": "https://github.com/doctrine/dbal.git",
"reference": "c480849ca3ad6706a39c970cdfe6888fa8a058b8"
},
"dist": {
"type": "zip",
"url": "https://api.github.com/repos/doctrine/dbal/zipball/c480849ca3ad6706a39c970cdfe6888fa8a058b8",
"reference": "c480849ca3ad6706a39c970cdfe6888fa8a058b8",
"shasum": ""
},
"require": {
"doctrine/cache": "^1.0|^2.0",
"doctrine/deprecations": "^0.5.3|^1",
"doctrine/event-manager": "^1.0",
"ext-pdo": "*",
"php": "^7.1 || ^8"
},
"require-dev": {
"doctrine/coding-standard": "9.0.0",
"jetbrains/phpstorm-stubs": "2021.1",
"phpstan/phpstan": "1.4.6",
"phpunit/phpunit": "^7.5.20|^8.5|9.5.16",
"psalm/plugin-phpunit": "0.16.1",
"squizlabs/php_codesniffer": "3.6.2",
"symfony/cache": "^4.4",
"symfony/console": "^2.0.5|^3.0|^4.0|^5.0",
"vimeo/psalm": "4.22.0"
},
"suggest": {
"symfony/console": "For helpful console commands such as SQL execution and import of files."
},
"bin": [
"bin/doctrine-dbal"
],
"type": "library",
"autoload": {
"psr-4": {
"Doctrine\\DBAL\\": "lib/Doctrine/DBAL"
}
},
"notification-url": "https://packagist.org/downloads/",
"license": [
"MIT"
],
"authors": [
{
"name": "Guilherme Blanco",
"email": "[email protected]"
},
{
"name": "Roman Borschel",
"email": "[email protected]"
},
{
"name": "Benjamin Eberlei",
"email": "[email protected]"
},
{
"name": "Jonathan Wage",
"email": "[email protected]"
}
],
"description": "Powerful PHP database abstraction layer (DBAL) with many features for database schema introspection and management.",
"homepage": "https://www.doctrine-project.org/projects/dbal.html",
"keywords": [
"abstraction",
"database",
"db2",
"dbal",
"mariadb",
"mssql",
"mysql",
"oci8",
"oracle",
"pdo",
"pgsql",
"postgresql",
"queryobject",
"sasql",
"sql",
"sqlanywhere",
"sqlite",
"sqlserver",
"sqlsrv"
],
"support": {
"issues": "https://github.com/doctrine/dbal/issues",
"source": "https://github.com/doctrine/dbal/tree/2.13.9"
},
"funding": [
{
"url": "https://www.doctrine-project.org/sponsorship.html",
"type": "custom"
},
{
"url": "https://www.patreon.com/phpdoctrine",
"type": "patreon"
},
{
"url": "https://tidelift.com/funding/github/packagist/doctrine%2Fdbal",
"type": "tidelift"
}
],
"time": "2022-05-02T20:28:55+00:00"
},
This is what I have for a typical TYPO3 v10 installation.
No, I have "version": "2.10.4", for doctrine/dbal, this would probably explain my problem...
you should probably check if you have some extension that forces another version of dbal?
I checked my extensions and no other extension requires dbal. I also checked the composer.lock file on the TYPO3 Github https://github.com/TYPO3/typo3/blob/v10.4.28/composer.lock and it seems to refer dbal 2.10.4 as well.
Since the import of the users is working in the backend module but not with the scheduler task, I would still guess, that the website is using a different setup than the CLI. Just doublechecking:
The php -v in the shell gives you the same PHP version like the one, which you get, when calling the phpinfo() in a PHP file on the webserver?
In this thread on Stackoverflow is a similar problem described. Maybe that helps?
Thanks for the advice, I checked again using the php -v command in the shell and looking at the phpinfo from the Typo3 admin tools and I still get the same result (7.4.29).
It seems that the functions using fetchFirstColumn in Typo3UserRepository (disableForConfiguration and deleteForConfiguration) are only called in the context of the scheduler task, I did not see them being called when using the backend module.
Same issue here: DBAL 2.10.4... Scheduler not working-- were you able to solve this issue? I do not want to manually update composer installation - running 10.4.32 here...
I ended up patching the extension: I changed the fetchFirstColumn(); calls to fetchAll(\PDO::FETCH_COLUMN); in Typo3UserRepository. When we update this site to a newer Typo3 version I will try using the vanilla extension again.
@jmethot88 thank you very much - so I also patched this thing... maybe wenn we switch to PHP 8.X on this servern and Typo3 V11 for this website it will work again - I have another issue which I cannot solve.. maybe this is stuck to PHP 7.2 - have a look at open issues ;-)
I've the feeling it's not related to PHP v8 but using that old PHP v7.2 as I'd say it works fine with PHP v7.4. If so, I'm not really planning to fix things for PHP v7.2 but would instead raise the lower version supported to PHP v7.4. Both of them are outdated now but PHP v7.4 is well supported by older TYPO3 versions and I'm still using it a lot in production, however I'm not using PHP 7.2 or 7.3 at all anymore.
Same issue here. PHP 7.4.33 in TYPO3 and cli TYPO3 10.4.36 ig_ldap_sso_auth Version 3.7.1
@baggyownz Can you please check if you have the corresponding method fetchFirstColumn in
vendor/doctrine/dbal/lib/Doctrine/DBAL/ForwardCompatibility/Result.php
In TYPO3 v10, it's supposed to be at line 218.
I just tested running the scheduler task via:
./vendor/bin/typo3cms scheduler:run
(using PHP 7.4.21) and this just works fine, no crash.
The folder ForwardCompatibility does not exists in my installation. I download the core sources via wget. But in TYPO3 11 the folder ForwardCompatibility exists, but not in TYPO3 10.
Are you using composer? Because I really have it locally, in TYPO3 v10, with the DBAL that comes with TYPO3 v10 installed via composer.