Unable to determine TYPO3_MODE
Fails with 4.18.0 and 4.18.1 on TYPO3 CMS 6.1.7.
Problem is that typo3conf/ext/phpmyadmin/modsub/index.php?phpMyAdmin=... is called directly and that no TYPO3_MODE is defined at that point (no init.php executed etc.).
Updated by Peter Enzenberger over 5 years ago
Problem found again in typo3 v7.6.2 and phpMyAdmin v5.1.5.
Error - Unable to determine TYPO3_MODE
It worked the first time.
And it does work after LogOut/Login from typo3-Backend.
It will output the Error message if you LogOut from phpMyAdmin in its header.
Clearing all the Cookies for phpMyAdmin etc will solve this problem.
Updated by GAYA La Nouvelle Agence over 5 years ago
On our side, we've noticed that the error can appears ou disappears after adding / enabling / removing / disabling other extensions. It could be due to extension loading order.
I don't think this is linked but we run a TYPO3 7.6 in composer mode.
Updated by Christian Wibbing over 5 years ago
When I access the backend module the cookie is set in phpmyadmin/Vendor/phpMyAdmin-184.108.40.206-all-languages/index.php with an additional path:
Set-Cookie: tx_phpmyadmin=6fv....d01; path=/typo3conf/ext/phpmyadmin/Vendor/phpMyAdmin-220.127.116.11-all-languages/; HttpOnly
I think the configuration from stock phpMyAdmin (session.inc.php) overwrites the path. After the first time it works, you have two cookies but with the same data. Only after your Typo3 session times out and you log in again without closing the browser window (which would delete all session cookies) I have problems. The config.inc.php in phpMyAdmin sees the old cookie, and not the one recently set from BeModule/index.php.
Also I noticed that Chrome Developer Tools do not show the cookie with the wrong path in "Resources" (iframe issue?), so the see the second cookie you have to use the network tab.
Updated by Matthias Philipp over 5 years ago
I think this gets in the right direction Christian.
I can confirm that I had this problem after a T3 session timeout and without closing the browser. After closing the browser and a new login session it worked. Just loging out and in again using the same browser window did not help.
Updated by Matthias Philipp over 5 years ago
I looked at the cookies at the moment of the failure, and there are two cookies with different content.
The one from phpMyAdmin is filled with data, the one ftom tx_phpmyadmin is empty.
During a working session both cookies are equal.
The problem does not happen every time during auto logout. I left two browser open tonight, in one of them PMA worked fine after entering the pw this morning.
The other one failed to relogin: pw ok, but invalid token error from T3 after that; manually reloading the /typo3/index.php makes BE usable again, but Fails at the PMA module.
Updated by Kurt Ludikovsky over 5 years ago
- File _Screen_Shot_2016-07-20_145244b.jpg _Screen_Shot_2016-07-20_145244b.jpg added
- File _Screen_Shot_2016-07-20_145248b.jpg _Screen_Shot_2016-07-20_145248b.jpg added
- File _Screen_Shot_2016-07-20_150102b.jpg _Screen_Shot_2016-07-20_150102b.jpg added
- File _Screen_Shot_2016-07-20_151639b.jpg _Screen_Shot_2016-07-20_151639b.jpg added
The same problem here with 7.6.9 (and PHP 5.x/Apache)
What happend and how to resolve it.
1) failure situation (browser used Vivaldi (Chrome based))
a) I left T3 with phpMaAdmin open in the backend.
When I returned next day, I was automatically logged out.
Relogged in with the click into the PW field an accepted the proposed PW.
Login worked, but at phpMyAdmin I got the shown failure.
b) Logout and re-login did not change the situation.
c) Checked the cookies in the developer tool
(see Vivaldi developer Cookies)
deleted the phpmy....-cookies
Reloaded the page - no change.
d) Logout and re-login brought also no change
Deleted all cookies via the developer tool.
Logout and re-login brought again no change
2) Login with Opera browser
phpMyAdmin Worked as expected
Checked cookies and found that there are pma....-cookies.
(see Opera Cookies)
3) returned to Vivaldi
checked cookies in the settings area, where pma...-cookies where set
(see Vivaldi settings cookies)
deleted all cookies for the domain and reloaded page and re-loggedin
Cookies are set as expected (see Vivaldi developer cookies after reload)
I have no idea how all of this really works, but it seems to me that there is an issue with the lifespan/visability of the cookies.
I experienced this "overnight" issue already several times. Usually a logout/re-login solved the problem.
"Overnight" because as far as I observed this only happens over night, not during a daily automatic logout.
Updated by Clemens Riccabona about 5 years ago
Had the same after rollout yesterday. But only on one single domain/installation, out of about 20.
TYPO3 Version 6.2
Tried a lot, including caches in typo3temp removing, uninstalling and installing again of the extension and some more.
also no errors are logged (but note, the installation was in production mode, which means: log_level=3)
Solution to me was:
1. Logout TYPO3.
2. Remove all cookies for the subdomain where I log in from (via webdeveloper toolbar in Firefox 48 on Linux) -> these were 16 cookies all together.
3. Login again: pada -> worx like a charm ...
Updated by Peter Enzenberger about 5 years ago
Had the issue again with new typo3 7.6.10 and phpmyadmin 5.1.7
Logout from phpMyAdmin will log you out from typo3 BE, too.
Further on you will get the "Unable to determine TYPO3_MODE" from phpMyAdmin in typo3.
This resolves the problem:
+ log out from typo3 BE
+ clear all cookies (with phpMyAdmin in its names) from the (sub)domain in use
+ login to BE again
+ might take a second click on phpMyAdmin to work fine
Basically the same as the tip Clemens Riccabona above.
Updated by Nico R almost 5 years ago
- TYPO3 Version changed from 6.2 to 7
Can confirm with Typo3 7.6.x and phpMyAdmin 5.1.7. Exactly the same story: Logging out of BE, clearing all cookies from the domain of the Typo3 installation, then logging back in helps for the time being, but the error eventually occurs again.
Updated by Loek Hilgersom almost 4 years ago
I also run into this issue occassionally. The workarounds work sometimes, sometimes not...
Now I had it consistantly on my dev-environment I did some debugging. Still don't understand 100% but at least I can see where the error is shown:
1. BeModule/index.php is called, TYPO3_MODE is set (value 'BE') and all seems fine
2. $GLOBALS['SOBE']->main() is called and near the end it does a redirect to $redirectUri, which then is http://domain.com/typo3conf/ext/phpmyadmin/Vendor/phpMyAdmin-18.104.22.168-all-languages/index.php?lang=en&db=dbname
3. After the redirect, the constants have lost their value (of course)
4. Then execution comes to AuthenticationSignon->auth()
5. There PMA_sendHeaderLocation($GLOBALS['cfg']['Server']['SignonURL']) gets called, and comes back (not sure if that is intended at this point!)
6. Finally, this function exits the execution with a call to 'exit()', after which BeModule/index.php is called again (why?) but now the TYPO3 constants are not set anymore and the error is shown.
Not completely solved but hopefully this will shed some light on this issue.
BTW: the issue occurs when using Chromium now, with Firefox I have no problem (atm.)