WordPress管理员权限“提请审批”无法发布文章问题解决方法
之前Kaijia一个WordPress站点安装了一个神一般的插件（具体造成错误的代码怎是没空找就不点名了……）后突然之间所有的帐号均无法发布文章了，并且自动保存等功能也不可用。即使Kaijia使用管理员帐号登录发布文章仍然显示“提请审批”，并且无法显示状态、公开度信息，点击“提请审批”之后会弹出错误提示页面不存在。其他的功能，例如下载等，也无法添加。
正常情况编辑文章右栏（左侧）和Kaijia遇到的异常情况（右侧）比较
Kaijia很快排除了权限系统出错的可能性，因为Kaijia登录的是管理员帐号，管理员权限与权限系统平行，始终获得所有权限，使用诸如User Role Editor等插件调整权限系统均不会管理员权限造成影响。
于是Kaijia搜索了一下类似的情况，在WordPress的支持论坛中找到了一个相似问题的帖子，在此帖子中网友给出了很多可能的解决方法但Kaijia尝试了没有一个是有效的。因此Kaijia考虑问题可能并非WordPress造成，而是有更深层次的原因，例如PHP终止错误或者数据库损坏等。
在这个帖子的最后原作者发帖称问题是由于主键的自增消失了造成的（“SOLVED that is my problem “auto increment” on primary keys are gone”），于是Kaijia用phpMyAdmin检查了一下数据表，发现点开每张表时都收到了提示“Current selection does not contain a unique column. Grid edit, checkbox, Edit, Copy and Delete features are not available.”，换句话说所有WordPress数据表的主键被删除了！
在phpMyAdmin中正常情况下显示的WordPress表索引结构（上）和主键丢失后的表索引结构（下）
至此原因已经很明确了，那个神一般的插件在安装时重置了所有WordPress的表结构，删除了所有表的主键。因此解决方法便是重新为每张表增加主键。在恢复之前，由于数据表损坏一般情况下并不会注意到，此时表中肯定已经生成了很多ID为0（由于没有了自增）的数据，需要先删除这些数据。恢复有两种方法：手动新建主键；利用备份还原表结构。
前者需要在MySQL中手动增加主键（即增加自增AUTO_INCREMENT），一个WordPress论坛用户luk3thomas提供的参考代码如下：
|
1 2 3 4 5 6 7 8 9 10 |
ALTER TABLE `wp_commentmeta` CHANGE `meta_id` `meta_id` BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT; ALTER TABLE `wp_comments` CHANGE `comment_ID` `comment_ID` BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT; ALTER TABLE `wp_links` CHANGE `link_id` `link_id` BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT; ALTER TABLE `wp_options` CHANGE `option_id` `option_id` BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT; ALTER TABLE `wp_postmeta` CHANGE `meta_id` `meta_id` BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT; ALTER TABLE `wp_posts` CHANGE `ID` `ID` BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT; ALTER TABLE `wp_terms` CHANGE `term_id` `term_id` BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT; ALTER TABLE `wp_term_taxonomy` CHANGE `term_taxonomy_id` `term_taxonomy_id` BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT; ALTER TABLE `wp_usermeta` CHANGE `umeta_id` `umeta_id` BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT; ALTER TABLE `wp_users` CHANGE `ID` `ID` BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT; |
注意，这段参考代码仅修复WordPress原生表，插件生成的表还需要手动修复，因此比较麻烦。
Kaijia采用的是第二种方法，即利用备份还原表结构，步骤思路如下：
- 删除所有ID为0的数据；
- 首先备份现有数据库，备份时只备份数据不备份结构，在每个表前加上TRUNCATE语句（这里利用phpMyAdmin的导出功能比较便捷）；
- 删除所有的表；
- 还原早前的备份（这个备份必须是确认问题出现前的备份，但必须是升级到WordPress目前版本后的备份），还原后表结构就恢复了（此时的数据是旧的）；
- 再导入第一步中的备份，此时将会自动清空旧数据，仅留下表结构，并将新的数据导入进来。
按照以上步骤操作表结构就成功恢复了（Kaijia恢复的时候还出了一些小插曲写在此篇日志中，也希望大家恢复时注意）。这类情况再次说明实时备份的重要性，因为这种BumbleBee的坑爹翻版随时都会发生！
lol