Bug #85298
closed
Check for broken extensions complains about system-extensions
0%
Description
Check for broken extensions complains about system-extensions
complained about lowlevel, fluid, and some others, see attached png file
tested on version 9.3
---
Edit:
In the browser-console I can track this:
1) typo3/install.php?install[controller]=upgrade is called but produces an error
2) The debug-message of the script is:
Fatal error: Uncaught TypeError: Argument 1 passed to TYPO3\CMS\Core\Error\DebugExceptionHandler::flattenArgs() must be of the type array, null given, called in typo3\sysext\core\Classes\Error\DebugExceptionHandler.php on line 397 and defined in typo3\sysext\core\Classes\Error\DebugExceptionHandler.php on line 513
Don't know if it's helping much, as it's already about "DebugExceptionHandler" ...
Files
Updated by Georg Ringer over 6 years ago
- Status changed from New to Needs Feedback
Hm I can't reproduce that with latest master, can you check there as well?
Updated by David Bruchmann over 6 years ago
I can do it from gihub without composer?
Have installed the tgz-package on windows
Updated by David Bruchmann over 6 years ago
Can't reproduce it anymore after more or less randomly clicked on some buttons to update some things and after adjusting some access rights on file-level.
Nevertheless I did the updates before already too, it just will be hard to reproduce perhaps.
I never updated the version @Georg, it's still the official distribution, just now I get in core-updater shown `TYPO3_DISABLE_CORE_UPDATER=1` that was before not.
Disabled This feature is disabled in this installation. The environment variable was set TYPO3_DISABLE_CORE_UPDATER=1. This system isn't a released TYPO3 version. This action can only be used with a linked typo3_src.
Don't know where this variable is set, but it's probably not related to my report.
Updated by David Bruchmann over 6 years ago
After having had some extension related database-updates the strange test-results showed up again.
Updated by David Bruchmann over 6 years ago
Having updated the core to most recent version of github I get now the same complaint about extension opendocs.
Updated by Nicole Cordes about 6 years ago
I had the very same problem today with current master and my dev-master installation. I had to check for broken extensions multiple time to finally get success messages at the end.
Updated by Christian Kuhn about 6 years ago
weird. any insight on what could be the reason for that?
Updated by Renzo Bauen over 5 years ago
Nicole Cordes wrote:
I had the very same problem today with current master and my dev-master installation. I had to check for broken extensions multiple time to finally get success messages at the end.
Same to me: TYPO3 V 9.5.7, i updated from 6.2 all the way up to 9.5.7 and finaliy got the same problem. On each click to "Check extensions" it reports an other ext failed. After 10 to 15 clicks, i finaly get the everything OK feedback.
In the systemprotocoll it reports me the following core error for each click:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: Argument 1 passed to TYPO3\CMS\Core\Utility\ArrayUtility::setValueByPath() must be of the type array, integer given, called in /var/www/dev/typo3_src-9.5.7/typo3/sysext/core/Classes/Configuration/ConfigurationManager.php on line 245 | TypeError thrown in file /var/www/dev/typo3_src-9.5.7/typo3/sysext/core/Classes/Utility/ArrayUtility.php in line 271. Requested URL: http://csbp.cpdev.int/typo3/install.php?install[controller]=upgrade&install[context]=backend
Updated by Susanne Moog over 4 years ago
- Status changed from Needs Feedback to Closed
Tried to reproduce it today with various v10 and 9 installations and failed to do so.
I then had a look at the code to try to figure out what might be happening and don't see (in current code) a reason for your errors.
From the error message `Argument 1 passed to TYPO3\CMS\Core\Utility\ArrayUtility::setValueByPath() must be of the type array` and the stack trace the content of the LocalConfiguration.php file at this point in time seems to be an integer (that file is required with PHP "require" function without any processing and handed to setValueByPath).
As there is currently no clear steps to reproduce and I failed to reproduce it on various systems I'm going to close the issue now. Additionally, one of the things I could imagine that this is related to filesystem/locking where it might be that the recent changes in querying the ext_localconf etc in that action might have fixed the issue, too.