Bug #85298
closed
Check for broken extensions complains about system-extensions
Added by David Bruchmann almost 6 years ago.
Updated about 4 years ago.
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
- Status changed from New to Needs Feedback
Hm I can't reproduce that with latest master, can you check there as well?
I can do it from gihub without composer?
Have installed the tgz-package on windows
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.
After having had some extension related database-updates the strange test-results showed up again.
Having updated the core to most recent version of github I get now the same complaint about extension opendocs.
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.
weird. any insight on what could be the reason for that?
- Description updated (diff)
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
- 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.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 