将网站迁移到生产环境时，我使用了WP-DB-Backup插件对数据库进行快照。然后，我编辑了生成的.sql文件，以更新所有文件路径和URL引用以指向我们的生产站点。
创建数据库，网站并将所有文件复制到生产后站点，我从mysql命令提示符下运行.sql文件，将数据导入到新数据库中。
但是，当我转到生产站点时，会显示一些文本，其中一些没有。当我查看站点的窗口小部件部分时，某些窗口小部件区域中缺少文本窗口小部件。文本窗口小部件甚至在“非活动窗口小部件”区域中都不可见，它们根本就不存在。
我什至尝试使用BackWPup插件重复该过程，并注意到在转储数据库时SQL语法是不同的。
为什么我丢失文本小部件导入期间输入数据？
#1 楼
这是您的问题所在：然后我编辑了生成的.sql文件
以更新所有文件路径和URL引用以指向我们的
生产站点。
您不能那样做。 WordPress将许多选项存储为“序列化数据”，其中包含事物的字符串内容及其长度。因此，当您修改URL并更改长度时，序列化的数据将不再正确，PHP将拒绝它。
长期的问题是，基本上，您这样做是错误的。如果要设置将要迁移其数据的开发站点，那么它应该与生产站点具有完全相同的URL。您可以手动编辑HOSTS文件，以为该生产域（例如example.com）提供一个不同的IP地址（例如127.0.0.1），因此“生产” URL将成为您的开发站点。然后，您可以使用该生产URL创建数据和链接以及所有其他内容，并且在迁移数据时，无需更改任何内容。
短期内，请勿使用在SQL文件上进行简单的文本搜索/替换。正如您所发现的那样，它破坏了事情。
尽管我犹豫不决地建议它，但是有一种方法可以更改WordPress核心代码以处理这些破坏的序列化。您必须修改wp-includes / functions.php文件，并将maybe_unserialize（）函数更改为此：
function maybe_unserialize( $original ) {
if ( is_serialized( $original ) ) {
$fixed = preg_replace_callback(
'!(?<=^|;)s:(\d+)(?=:"(.*?)";(?:}|a:|s:|b:|i:|o:|N;))!s',
'serialize_fix_callback',
$original );
return @unserialize( $fixed );
}
return $original;
}
function serialize_fix_callback($match) { return 's:' . strlen($match[2]); }
这不是一个可行的长期解决方案。它仅应用于使您立即开始工作。从长远来看，您需要修复开发过程，这样一开始就不必进行此类URL调整。
评论
@Otto很好的答案。快速的问题，在MySql外部修改非序列化的blob /文本表（如wp_posts）会影响wp_post_meta或wp_options中的任何序列化数据吗？我在文本小部件上遇到了同样的问题，但是我没有碰过wp_options，而只是修改了wp_posts。
– Chris_O
2011-2-10在19:40
哇，我从来没有意识到这就是数据所发生的一切，但这完全有道理！非常感谢！
– Dillie-O
2011-02-10 20:52
某些人使用的另一种解决方法是使他们的开发系统的域名为“ example.dev”，而不是“ example.com”。这样，将字符串移至生产环境时，字符串的长度就不会改变。我更喜欢HOSTS文件方法。
–奥托
2011年2月11日在21:28
2016年，wordrepss仍将序列化数据保存在数据库中。最著名的最差代码奖不必再犹豫了。
– Ejaz
16 Mar 8 '16 at 11:56
谢谢！！！好点和伟大的hack。总的来说，我得到了这个技巧，可以返回所有数据，之后，只需再次更新现有设置，然后删除此代码即可正常工作。
–艾维安·斯特凡·斯蒂皮奇（Ivijan StefanStipić）
17年2月4日在9:13
#2 楼
为了解决此问题，我始终使用此处提供的WordPress序列化搜索和替换工具。它工作正常，没有任何问题。我已经在所有网站迁移要求上使用了很长时间。这确实解决了将开发数据库迁移到生产中的问题。https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
评论
是的，使用此脚本已有多年，强烈建议您使用
– davemac
13年4月4日在22:45
大多数时候为我工作。但是这周，当我使用v 3.0.0将http：// localhost / Me / site_name替换为http://site.dev（从一个本地主机到另一个本地主机）时，我确实失去了我的小部件和菜单位置。因此，也许这个问题也与字符串长度有关。
–rhand
2014年11月27日7:01
我一直在使用..但到目前为止从未遇到过这种情况。您可以下载此脚本的旧版本，然后重试一次。尝试用site.dev替换localhost / Me / site_name。
– Subharanjan
2014年11月27日10:17
网址已更改（现在是https而不是http）：interconnectit.com/products/…
– Koryonik
2015年9月18日在9:26
华丽的脚本。我将PHPMyAdmin的MySQL数据库从旧数据库复制到了新数据库-完全不更改URL，然后转到了新站点的新WP文件所在的文件夹（连同正确的wp-config.php一起，新的数据库凭据），添加了脚本，并完成了所有工作。序列化的数据沿正常的URL更新。简单快捷！强烈推荐。重要说明：使用脚本后，请不要忘记删除它，因为它可以访问您的数据库详细信息！
–花生
18年2月8日在1:19
#3 楼
奥托的答案很明确。我也很难发现这一点。但是，我设法使用http://spectacu.la/search-and-replace-for-wordpress-databases/
的一个很酷的脚本来解决此问题将您的wordpress迁移到新的URL /域名，请执行以下操作：
对现有wordpress进行数据库转储（例如，使用phpmyadmin）
将转储还原为-是，（无需修改）到您的新位置
将脚本从spectacu.la解压缩到您的wordpress主文件夹（它不是插件...）中。
通过指向新站点来运行脚本您的浏览器，例如http：//new-website.url/searchreplacedb.php
别忘了从新的wordpress主页中删除脚本
评论
我知道这有点旧，但是如果按原样还原转储，应该在哪里指定新的数据库名称？我至少应该在第二步中输入新的数据库名称吗？多谢告诉我这个消息
– andresmijares
2012年1月5日19:22
我不确定我是否完全理解您的问题。可以使用phpmyadmin之类的工具来还原数据库，您可以给它起一个新名称，也可以使用旧名称。我提到的脚本只是在数据库已还原后更改文本。
– Yooav Aner
2012年1月8日在16:45
嗨，Yoav，谢谢您的回答，我的意思是，当我导出数据库时，通常将数据库名称更改为新名称，并更改域链接。这样说，在第二步，您说没有任何修改就按原样还原转储，我只是想知道是不是从字面上看，否则我至少必须更改数据库名称。我知道这可能是一个虚假的问题，我有点迷茫，再次感谢您的回答
– andresmijares
2012年1月8日在18:19
我不知道您如何转储数据库，但是如果您使用phpmyadmin'export'工具，那么它与哪个数据库名称无关。您可以使用导出并将其导入回任何其他数据库。通常，关于项目要点2，我认为可以更改数据库名称。
– Yooav Aner
2012年1月9日15:09
#4 楼
在数据库导出文件上进行搜索和替换时，OP过于热情，最终导致某些序列化数据中“ wp_”的出现发生了变化。解决方案是通过在正则表达式中包含反引号，然后在导入后手动更新数据库中的其余键，来在搜索和替换过程中更加省事。如果要迁移和更改前缀，并且像更手动的方法一样，执行以下操作（这仅解决了OP的问题，并且不涉及更新站点URL）
备份并移动数据库导出
将SQL文件迁移到新环境（我的示例假定文件名为backup_YYYY-MM-DD.sql）
对SQL文件进行批量搜索和替换，以更改表名
/>以使用新的前缀（
导入SQL文件之前！）。
一种方法是使用Perl
像这样的内衬：perl -p -i.bak -e
“ s /`wp_ /`myprefix_ / g”
backup_YYYY-MM-DD.sql
将您的SQL数据导入数据库中
更新_options中包含硬编码前缀的所有键： /> option_name =
concat（'myprefix _'，substr（option_name，4））
其中option_name如'wp_％'
更新_user_meta
中包含硬编码的前缀：
更新myprefix_usermeta设置
meta_key =
其中meta_key如'wp_％'
#5 楼
我使用WP Migrate插件，巫婆替换了http和文件夹补丁。导入时遇到一个问题，但解决了将以下几行放在生成的sql的顶部： />
我也尝试使用@Yoav答复的“搜索并替换”工具（v2.1），但它仍然破坏了我的序列化数据。
评论
嗨，里卡多，欢迎来到WordPress答案！您在其中张贴的区域保留为原始问题的答案。即使您的问题与您相关，也应将其作为单独的问题发布。这样，您将有更多的机会得到答案。
– Chris_O
2012年7月11日在10:02
评论
我一直在做一些挖掘工作，我唯一想到的是小部件信息存储在wp_options表中，该表看起来以一种怪异的方式编码了一些数据。我还无法尝试使用其他主题来查看它是否与主题相关。