PrestaShop从1.6升级到1.7+版本后，管理员后台（BO）侧边栏链接可能出现异常，点击后重定向到仪表盘或显示“访问被拒绝”，即使URL显示正确。此问题通常源于数据库中`ps_access`和`ps_authorization_role`表的数据迁移不完整或错误。本文将提供详细的诊断与修复步骤，帮助用户恢复后台正常导航。
1. 问题现象与诊断
当您将PrestaShop从1.6版本升级到1.7或更高版本（例如1.7.8.2），并可能同时升级了PHP版本（例如到7.3），可能会遇到以下后台导航问题：
链接重定向： 点击后台侧边栏的某些链接（例如“商店参数” youjiankuohaophpcn “常规”）时，页面虽然URL显示为目标控制器的地址（例如/index.php/configure/shop/preferences/index.php），但实际内容却加载了仪表盘页面，URL中可能错误地包含controller=AdminDashboard参数。访问被拒绝： 部分页面可能会显示“访问被拒绝”的提示，但有时仍然可以部分使用。缓存清理无效： 尝试清理PrestaShop缓存（包括删除/var/cache/目录下的文件）后，问题依然存在。这些现象强烈暗示问题并非简单的缓存或文件权限错误，而是与PrestaShop 1.7版本引入的权限管理机制相关。
2. 根本原因分析：数据库权限表异常
根据经验，此类问题通常是由于数据库中负责管理员工访问权限和授权角色的表在升级过程中未能正确迁移或创建引起的。PrestaShop 1.7引入了更细粒度的权限控制，特别是增加了ps_authorization_role表。
关键涉及的数据库表包括：
ps_access: 此表在PrestaShop 1.6和1.7中都存在，用于存储员工配置文件（id_profile）与后台标签页（id_tab）之间的访问权限关系。ps_authorization_role: 此表是PrestaShop 1.7版本引入的新表，用于定义不同的授权角色（例如“超级管理员”、“翻译员”等）及其对应的权限标识符（slug）。在1.7中，权限管理更加依赖于这些角色。如果这些表中的记录在升级后缺失、不完整或与PrestaShop 1.7的预期结构不符，就会导致系统无法正确识别管理员的权限，从而出现导航错误或访问限制。
3. 解决方案：检查与修复数据库权限表
解决此问题的核心是检查并修正ps_access和ps_authorization_role表中的数据。
3.1 步骤一：对比数据库表结构与内容
首先，您需要一个干净的、全新安装的同版本PrestaShop 1.7数据库作为参考。然后，使用数据库管理工具（如phpMyAdmin）对比您的升级后数据库与参考数据库中的ps_access和ps_authorization_role表。
备份数据库： 在进行任何数据库修改之前，务必完整备份您的PrestaShop数据库。检查ps_access表：比较两个数据库中此表的结构和主要字段。检查您的管理员用户（通常id_profile为1或2）是否拥有所有必要的id_tab访问权限。您可以使用以下SQL查询来查看您的管理员配置文件对应的访问权限：SELECt pa.*, pt.class_name, pt.module, pt.parent_idFROM ps_access paLEFT JOIN ps_tab pt ON pa.id_tab = pt.id_tabWHERe pa.id_profile = (您的管理员配置文件ID，通常为1);登录后复制
将(您的管理员配置文件ID)替换为您的实际管理员配置文件ID。
智谱AI开放平台 智谱AI大模型开放平台-新一代国产自主通用AI开放平台
85 查看详情 
检查ps_authorization_role表：这是1.7特有的表，确保它存在且包含PrestaShop 1.7默认的授权角色记录。例如，它应该包含像ROLE_SUPERADMIN、ROLE_EMPLOYEE等slug值。使用以下SQL查询查看此表内容：SELECt * FROM ps_authorization_role;登录后复制与干净安装的数据库进行对比，查看是否有缺失的id_authorization_role或slug记录。
3.2 步骤二：创建新的超级管理员员工
这是一个重要的诊断步骤，可以帮助判断问题是普遍性的还是特定于现有管理员配置的。
在您的PrestaShop后台（如果可以登录并访问员工管理页面），尝试创建一个全新的员工。为该新员工分配“超级管理员”（SuperAdmin）权限。使用新创建的超级管理员账户登录后台。测试所有之前出现问题的侧边栏链接。如果新超级管理员可以正常访问所有页面： 这表明问题可能出在您原有管理员账户的ps_access或相关权限配置上。您可以考虑将原有管理员账户的权限与新账户进行对比和修正，或者直接使用新账户。如果新超级管理员仍然遇到相同问题： 这强烈指示ps_authorization_role表存在普遍性问题，或ps_access表中所有管理员配置都存在系统性缺陷。3.3 步骤三：修正缺失的数据库记录（谨慎操作）
根据对比结果，您可能需要手动插入或更新缺失的数据库记录。此操作需要高度谨慎，建议在熟悉SQL操作或专业人士指导下进行。
从干净的PrestaShop 1.7数据库中获取数据：
对于ps_authorization_role表，您可以从一个干净的PrestaShop 1.7安装中导出其所有记录（通常是几条）。对于ps_access表，如果您的管理员配置文件缺失大量权限，您可以考虑从干净安装中导出id_profile=1（超级管理员）的所有ps_access记录，并将其导入到您的数据库中，但请确保id_profile与您的管理员账户匹配。执行SQL插入或更新：
示例（ps_authorization_role表）： 如果您发现ps_authorization_role表缺失关键记录，您可能需要手动插入。-- 示例：插入一个缺失的超级管理员角色，请根据干净数据库的实际值调整INSERT INTO `ps_authorization_role` (`id_authorization_role`, `slug`) VALUES(1, 'ROLE_SUPERADMIN'),(2, 'ROLE_EMPLOYEE'),(3, 'ROLE_TRANSLATOR');-- 请注意：id_authorization_role是自增的，通常不需要手动指定，除非您需要修复特定的ID。-- 更安全的做法是只插入缺失的slug。登录后复制示例（ps_access表）： 如果您的管理员账户缺失特定tab的访问权限，您可以插入这些权限。
-- 示例：为管理员配置文件ID为1的用户授予对某个tab（例如id_tab=X）的访问权限INSERT INTO `ps_access` (`id_profile`, `id_tab`, `view`, `add`, `edit`, `delete`) VALUES(1, (缺失的tab ID), 1, 1, 1, 1);登录后复制
请确保(缺失的tab ID)是您需要授予权限的实际后台标签页ID。您可以通过ps_tab表找到对应的id_tab。
再次清理缓存： 在进行任何数据库修改后，务必再次清理PrestaShop缓存和浏览器缓存，以确保系统加载最新的配置。
4. 注意事项与总结
数据库备份至关重要： 在对数据库进行任何修改之前，请务必进行完整备份。谨慎操作SQL： 手动修改数据库需要对SQL有一定了解。如果不确定，请寻求专业人士的帮助。对比参考： 始终使用一个干净的、同版本的PrestaShop 1.7安装作为数据库结构和内容的参考。版本兼容性： 确保您的PHP版本与PrestaShop 1.7.x版本兼容。虽然本问题主要与数据库有关，但PHP版本不兼容也可能导致其他未知问题。文件权限： 尽管本问题不直接是文件权限问题，但为了系统正常运行，请确保PrestaShop文件和目录的权限设置正确（通常是755用于目录，644用于文件）。通过仔细检查并修正ps_access和ps_authorization_role表中的数据，您应该能够解决PrestaShop 1.7升级后后台侧边栏链接重定向到仪表盘的问题，恢复正常的管理操作。
以上就是PrestaShop 1.7 后台侧边栏链接重定向到仪表盘的解决方案的详细内容，更多请关注php中文网其它相关文章！
