Session cache warning after upgrade to 9.1.0
After upgrading to t3adminer 9.1.0 I get warnings in the backend module:
Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /path/to/my/cms/typo3conf/ext/t3adminer/Resources/Public/Adminer/adminer.txt:1570) in /path/to/my/cms/typo3conf/ext/t3adminer/Resources/Public/Adminer/adminer.txt on line 72
TYPO3 Version 8.7.13
PHP Version 7.1.10
Could provide more info if needed.
Btw: Thanks for keeping this up-to-date!
#2 Updated by Markus Timtner about 2 years ago
A solution to this problem might be found here:
at the very top of your script, and
at the bottom of your script.
(This will turn output buffering on and your headers will be created after the page is buffered.)
I inserted this in typo3conf/ext/t3adminer/Resources/Public/Adminer/t3adminer.php and it seems to work, no error message anymore.
#3 Updated by Jigal van Hemert about 2 years ago
- Status changed from New to Needs Feedback
Thanks for reporting the issue.
I've just tested it in both TYPO3 8.7 and master branches on PHP 7.2.0. No such warning message visible.
Could you check the Adminer version that is displayed above the list of tables? In EXT:t3adminer 9.1.0 that is version 4.6.2
#5 Updated by Klaus Bossert about 2 years ago
- File Adminer-at-domainfactory.png added
I also made sure I see the recent version of Adminer, but the warning still remains (see attached screenshot).
It has to be mentioned here that this happens on shared webspace of the german provider domainfactory.
Applying the ob_*-fix is only a partial resolve for me, as only the first appearance of the message shown in the screenshot is surpressed, where the second one (and also the one appearing on top of the left column after selecting a specific table) keeps to be there.
#8 Updated by Jigal van Hemert almost 2 years ago
Also testing it in PHP 7.1.12 on TYPO3 8.7.16-dev didn't reproduce the issue.
In your screenshot was a rather important clue. Does your server have the php.ini setting "session.use_cookies" set to Off (0) ? The default setting is On (1) and that is the case on all the machines I've tested on. Perhaps that is the issue on your server?