How to fix: «phpMyAdmin — Error Cannot start session without errors»?
I tried to fix by changing permissions of the /tmp (listed as sessions path in php.ini) to 755 , then tried 777 . I also tried changing user and group ownership with chown to www-data . ( www-data listed as user for php-fpm and Nginx). Tried multiple web browsers, deleting cookies, deleting all session files from server’s /tmp folder. PHP info shows sessions loaded. Not sure what else it could be, all other areas of the site load perfect and there’s nothing in error logs related. Is this something you are familiar with?
5 Answers 5
PHP «sessions» store variables so they can persist across multiple HTTP requests.
PHP sends your browser a single cookie that serves as a key. The key is used to retrieve the values from server-side storage.
By default, PHP uses files to store session data on the webserver (which in your case is actually your local PC). Your error indicates that your webserver can’t retrieve the file, so it can’t restore the variables, and phpMyAdmin can’t proceed.
This is likely due to filesystem permissions issues on your local PC.
Do following things
Try to open phpmyadmin in another browser. If it opens then it means it is related with your browser cache memory so try to delete cache and temp files of your browser then restart your wampsever.
Second thing, If the first one fails, try to delete session files of phpmyadmin which is located in C:/wamp/tmp. Do not delete the temp folder but the content inside the temp folder.
Restart your wampsever and it will work.
Php sessions configuration error
БлогNot. PHP: 12 причин, по которым не работают сессии
PHP: 12 причин, по которым не работают сессии
Хотя PHP последних версий стал работать с сессиями гораздо лучше, начинающие (а порой и опытные) программисты всё ещё нередко мучаются с ними, особенно если речь идёт об адаптации старого кода к новым версиям. В этой заметке я собрал самые распространённые причины, по которым могут не работать сессии (авторизация не выполняется, вход на сайт происходит только со второго раза и т.п.)
То есть, не вызывалась функция session_start. Самая банальная и самая частая причина. Вызов session_start должен выполняться на каждой странице, где используются данные из массива $_SESSION .
Лучше всего вызывать session_start сразу после открывающего тега
Я часто в запутанном коде из множества модулей делаю это в виде
if (!isset($_SESSION)) session_start ();
Есть смысл также запускать сессию только из модуля с функциями, подключаемыми к каждой странице сайта кодом вроде этого:
require_once ("functions.php"); 2. Сессия или её данные удаляются из кода раньше, чем должны использоваться.
В сложных многомодульных скриптах это вполне возможно, тем более, сделать это можно несколькими способами — через функцию session_destroy, «прямой» очисткой массива сессии кодом вида $_SESSION = array(); или $_SESSION = []; или unset($_SESSION[‘name’]) или просто unset($_SESSION); — в последнем случае, правда, сгенерируется предупреждение. «Прошерстите» код, чтобы убедиться, что этого не происходит.
3. Хранилище сессии недоступно для записи.
Выполните на хосте функцию phpinfo и проверьте значение session.save_path — это папка, куда сохраняется сессия.
Зайдите в неё и посмотрите, есть ли там свежие файлы с именами вроде sess_***** или *****.tmp . Если файлов нет — сессия не может сохраниться из-за отстутствия прав на доступ к папке. Установите их.
4. Данные сессии не записываются после отправки заголовка.
Если страница после выполнения кода редиректит на другую страницу при помощи функции header, может понадобиться добавить непосредственно после вызова header вызов функции session_write_close (или exit , die ), чтобы сессия могла корректно записать данные.
5. В браузере не включены Cookies.
Механизм куки-файлов необходим для работы сессий. Проверьте, что куки разрешены в браузере.
6. В коде или настройках сайта происходит редирект с одного домена на другой.
При редиректе сессия потеряется, даже если это редирект с site.com на www.site.com или наоборот.
7. Некорректная работа со временем в скрипте.
Скрипт имеет тысячу и один способ использовать время, отличающееся от серверного, в том числе, ставить время для куки и т.п.
А что если в момент создания кука оказывается уже просроченной?
Неплохо также в файле .htaccess настроить часовой пояс явно, скажем
SetEnv TZ Asia/Krasnoyarsk php_value date.timezone "Asia/Krasnoyarsk"
8. Устаревшие функции сессий.
Например, код всё ещё использует session_register, а она давно удалена из языка. Проверьте и другие функции сессий — нужно ли их все применять?
Мне сегодня помог п. 4 при «реанимации» работающего «со второго входа» сайтега.
Теперь причины более экзотические, которых, вроде бы, не должно быть, а они случаются.
9. На сайте нет файла favicon.ico или favicon.png
Некоторым бразуерам (Chrome) на некоторых серверах (nginx) это может помешать работе с сессиями, хотя понятных причин я назвать не могу.
10. У вас в файле кодировка UTF-8 с меткой BOM.
Избавьтесь от неё. Хотя, по идее, вы должны были увидеть раньше популярнейшее предупреждение (warning) «headers already sent» (см. по ссылке). Но бывает, что не усмотрел директивы отключения варнингов где-нибудь в недрах кода. Кстати, включите контроль всех ошибок при работе.
11. Лишние символы, например, пробелы после закрывающего тега PHP ?>
Что тут сказать? Избавьтесь от них.
Скорее всего, сессия просто стартует не там, где Вы думаете.
17.06.2021, 12:57 [4565 просмотров]