☰

使用 CMS 时出现“无法启动会话：已由 PHP 启动”错误

tag-icon • tag-icon php apache-2.4 wordpress cms symfony
使用 CMS 时出现“无法启动会话：已由 PHP 启动”错误

我安装了一个名为 Prestashop 的 CMS：它在特定域下运行，并在 Apache 上使用特定的 VirtualHost 配置，在具有其他 PHP 应用程序（Wordpress）的服务器上运行。

当我尝试以管理员用户身份登录时，收到以下错误（这是 Apache 错误日志）：

[Wed Jan 18 00:09:16.059190 2017] [:error] [pid 31253] [client xx.xx.xx.xx:63129] PHP Fatal error: Uncaught exception 'RuntimeException' with message 'Failed to start the session: already started by PHP.' in /opt/wp/apps/prestashop/app/cache/prod/classes.php:108\nStack trace:\n#0 /opt/wp/apps/prestashop/app/cache/prod/classes.php(483): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()\n#1 /opt/wp/apps/prestashop/vendor/symfony/symfony/src/Symfony/Component/Security/Csrf/TokenStorage/SessionTokenStorage.php(90): Symfony\Component\HttpFoundation\Session\Session->start()\n#2 /opt/wp/apps/prestashop/vendor/symfony/symfony/src/Symfony/Component/Security/Csrf/CsrfTokenManager.php(54): Symfony\Component\Security\Csrf\TokenStorage\SessionTokenStorage->hasToken('ANONYMOUS_USER')\n#3 /opt/wp/apps/prestashop/app/cache/prod/classes.php(8196): Symfony\Component\Security\Csrf\CsrfTokenManager->getToken('ANONYMOUS_USER')\n#4 /opt/wp/apps/prestashop/classes/Link.php(722): PrestaShopBundle\Service\Routing\Router->generate('admin_product_c...')\n#5 /opt/wordpre in /opt/wp/apps/prestashop/app/bootstrap.php.cache on line 3216, referer: http://www.xxxxx.xx/adminXXX/index.php?controller=AdminLogin&token=181fa270d47386a8d523bdea6213932c&redirect=AdminDashboard'

该错误是由 Prestashop 的稳定版本检索到的，因此我认为它不能依赖于代码问题。是不是 WordPress 首先打开一个会话，然后 Symfony（Prestashop）发现该会话已经打开？主域实际上是由 WP 提供服务的。我还尝试为 Prestashop VirtualHost 定义一个特定路径：https://stackoverflow.com/questions/18262878/how-to-prevent-php-sessions-being-shared-between-different-apache-vhosts 不幸的是，它不起作用。

PHP 会话 auto_start 参数在 php.ini 中设置为 0。

我不知道该如何解决这个问题。这取决于 Apache 或 PHP 配置吗？

多谢。

答案1

在 session_start 命令之前，您的 PHP 之外有一些字符。最有可能是结束标记后的空格 ?>

这就是为什么结束标签不应该位于文件末尾的原因，这已在 PSR2 标准中编纂。

确保使用正确的 FTP 设置上传所有文件，并检查是否有任何意外更改。最坏的情况是，在错误消息之前的所有文件中放入 var_dump(headers_sent().__FILE_d);。

相关内容