如何:轻松将WordPress安装从开发迁移到生产?


199

我在一个盒子上进行开发,然后在另一个盒子上进行生产。现在,我只是转储数据库,然后查找URL更改的替换项。然后复制文件并导入新的SQL。

有更好的方法吗?


2
对于新手的要求。1年后,我仍在使用@MikeSchinkel插件。我将他安装了几次安装后没有问题,他得到了0.7。mikeschinkel.com/downloads/wp-migrate-webhosts-0.7.zip
Ryan Gibbons

这是我发布的无插件脚本,极大地帮助了我的过程。philipdowner.com/2012/01/…–
菲利普·唐纳


6
今天,有一个名为Duplicator的插件:wordpress.org/extend/plugins/duplicator从字面上看,这是一个三步过程,就像一个魅力。已经多次使用它来将网站从测试环境部署到实时环境。
马赛厄斯

Answers:


122

@ Insanity5902:从第一天开始使用WordPress以来,将WordPress网站从一个盒子部署到另一个盒子就成了PITA。(实话实说,在我开始使用WordPress之前,这是Drupal的PITA了2年,所以问题肯定不仅仅限于WordPress。)

令我感到困扰的是,每当我需要移动一个站点时,我都不得不花费很多重复的精力,这使我无法像我期望的那样频繁地部署和测试。因此,大约4到6个月前,我开始致力于解决Webhost迁移问题的插件,并在WP Tavern论坛上提到了自己的想法

很好的发展到今天,我已经使它工作了很多,我方便地将其称为“ WP Migrate Webhosts”。鉴于您的问题,即使该插件仍处于测试阶段(甚至可能是alpha测试版),但我认为我已经准备好让人们开始喜欢它。

设想的用例是:

  1. 首先,开发人员负责通过FTP上传所有更改的主题和插件文件,
  2. 然后将开发MySQL数据库完整上传到测试服务器,最后
  3. 然后运行该插件,将所有引用从先前的域迁移到新域。(我的插件并没有试图解决新的数据库字段或使用实时数据表的合并; THAT是一个更大的问题是我不知道如何解决。)

您可以从我的网站下载该插件,然后解压缩到您的插件目录中(如果您不知道如何执行此操作,那么此插件不适合您,因为它需要知道他们在做什么的人才能使用。)将此插件保持在线状态,直到我将其发布到WordPress.org,之后再在那里查找。

要使用它,你采取不同的方法在您的wp-config.php正常通过注释掉四(4)规定DB_NAMEDB_USERDB_PASSWORDDB_HOST,而是注册了主机管理的默认值,然后登记有关每个虚拟主机提供商本身的信息。这就是该部分的wp-config.php样子(请注意,第一部分注释掉了不需要的代码,还请注意,我在本地计算机上使用不可路由的.dev顶级域设置了hosts文件,从而使日常开发变得更加容易。在Mac上,VirtualHostX轻而易举地做到了:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
//define('DB_NAME', 'wp30');

/** MySQL database username */
//define('DB_USER', 'wp30_anon');

/** MySQL database password */
//define('DB_PASSWORD', '12345');

/** MySQL hostname */
//define('DB_HOST', '127.0.0.1:3306');

require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/wp-webhosts.php');
register_webhost_defaults(array(
 'database'  => 'example_db',
 'user'      => 'example_user',
 'password'  => '12345',
 'host'      => 'localhost',
 'sitepath'  => '',        // '' if WordPress is installed in the root
));
register_webhost('dev',array(
 'name'      => 'Example Local Development',
 'host'      => '127.0.0.1:3306',
 'domain'    => 'example.dev',
 'rootdir'   => '/Users/mikeschinkel/Sites/example/trunk',
));
register_webhost('test',array(
 'name'      => 'Example Test Server',
 'rootdir'   => '/home/example/public_html/test',
 'domain'    => 'test.example.com',
));
register_webhost('stage',array(
 'name'      => 'Example Staging Server',
 'rootdir'   => '/home/example/public_html/stage',
 'domain'    => 'stage.example.com',
));
register_webhost('live',array(
 'name'      => 'Example Live Site',
 'rootdir'   => '/home/example/public_html/',
 'password'  => '%asd59kar12*fr',
 'domain'    => 'www.example.com',
));
require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/set-webhost.php');

希望这是(主要)自我解释。我试图使代码尽可能整洁,但是不幸的是,它要求require_once()在webhost注册代码块前后添加这两行密码,因为在调用之前,我没有办法“ 钩住 ” WordPress wp-config.php

更新wp-config.php完之后,您可以简单地使用URL快捷方式wp-migrate-webhosts进入管理屏幕,如下所示:

http://example.com/wp-migrate-webhosts

以上将带您到管理员屏幕等,其具有描述文本的公平位,并允许您迁移以下FROM选择域从(迁移后的任何一个单一的点击其他网站托管域的注意:这个例子说明会DOWN从测试/台/ Live服务器到当地发展,但放心,它可以迁移TO它恰好位于任何域,这也意味着该插件将是伟大采取现有的直播现场,并迅速得到一个地方的发展环境中工作!):

在此处输入图片说明

如果不清楚,在这种情况下,“ 迁移 ”是指将当前数据库中的所有引用更新为适合当前定义的Web主机(并且通过检查嗅探到当前 ” )。$_SERVER['SERVER_NAME']

该插件最酷的地方是它实现了一些基本的迁移,但是任何人都可以钩住它并执行自己的迁移。例如,如果添加一个库插件,该插件在数据库中存储了图像的完整路径,则可以挂钩该migrate_webhosts操作,该操作将作为元数据数组分别 ” Webhost和“ ” Webhost 传递给您,使用SQL或任何适用的WordPress API函数在数据库中执行您需要执行的任何操作来进行迁移。是的,我们每个人都可以在没有插件的情况下执行此操作,但是如果没有插件,我发现编写所有所需的代码比付出的努力多。使用该插件,可以更轻松地编写这些微小的钩子并加以使用。

您可能还会发现我在未测试的情况下迁移失败,也许您可​​以帮助我改善插件?任何想要的人都可以通过我的gmail帐户给我发送电子邮件(我的别名为“ mikeschinkel”。)

此外,插件可以接受,除了它承认像那些用户定义的虚拟主机提供商的元数据databaseuserpasswordhostdomain等一个很好的例子可能是googlemaps_apikey在那里你可以存储为每个域,你的谷歌地图的插件需要不同的API密钥正确操作(在使用Google Maps插件的人当中,尚未将应用程序部署到实时服务器并忘记将代码更改为正确的API密钥吗?老实说,... :)使用此插件,googlemaps_apikeyregister_webhost()数组中的一个元素和一个小的自定义migrate_webhosts钩子,可以有效消除这一点!

就是这样。我在WordPress Answer's Exchange上启动此插件,因为@ Insanity5902的问题触发了它。让我知道是否有帮助,如果合适的话,请在这里;如果没有帮助,请通过电子邮件。

PS:如果您决定使用此标记,请记住它是alpha / beta,这意味着它将更改,因此,如果您想立即使用它,请准备进行一些小手术,然后在被许多人殴打后使用已发行的版本。

PPS我的目标是什么?我很高兴看到它迁移到WordPress核心,以便每个人都可以使用它。但是,在此之前甚至甚至可以考虑,很多人必须对使用它感兴趣,以确保它实际上解决了它可能带来的更多问题。因此,如果您喜欢这个主意,那么请务必使用它,并帮助我获得发展动力,最终将其希望地纳入WordPress核心。


好的解决方案尽管我有两个问题,但还是有几个问题:1)您是否仍然需要定义WP_SITEURL才能进入管理区域?2)该工具仅针对管理员用户显示吗?(不确定“工具”部分是否针对非管理员显示)
Ryan Gibbons,2010年

@ Insanity5902,您好:1)无需设置WP_SITEURL,插件即可为您完成。您实际上是在为网络主机“注册”一个“域”和“ sitepath”时进行设置的。在正常的WordPress操作中,需要在代码或数据库中设置WP_SITEURL,以确保没有人伪造URL并进行恶意操作,因为$ _SERVER ['SERVER_NAME']中的值意外。WP Migrate Websites插件基于$ _SERVER ['SERVER_NAME']间接设置WP_SITEURL,但是只有当当前域与您在wp-config.php文件中定义的域之一匹配时,它才会这样做。
MikeSchinkel 2010年

2.)我提到的URL快捷方式实际上将重定向到管理控制台,因此仅适用于登录管理员的人员。我还没有针对仅内置管理员的特定检查。我从未在插件中添加任何功能,但需要全面研究未来几周的工作方式,以便在下个月进行工作。但是,该插件不是破坏性的。它只能迁移到当前域,并且该过程是可重复的,因此即使非管理员进入该域也不会对其造成任何伤害,至少我无法想象。
MikeSchinkel

1
/ wp-migrate-webhosts产生404,/ wp-admin产生“建立数据库连接时出错”
Steve

5
那么,此插件的状态如何?它看起来很吸引人,但我希望它成熟且经过严格审查。这篇文章是我能找到的唯一信息。
凯文C.

35

如果可能的话,我将WP_HOMEWP_SITEURLwp-config.php。这与数据库转储和导入结合在一起,是我所熟悉的所有解决方案中最简单的一种。

http://codex.wordpress.org/Changing_The_Site_URL#Edit_wp-config.php


1
什么时候不能设置这些?这听起来比更改数据库中的内容简单一些。
jfklein 2011年

2
@jfklein我几乎一直在使用WordPress网络,该网络与这些常量不兼容。
Annika Backstrom的

1
做同样的事情。遗憾的是,并非所有主题都对此表示欢迎。即ThemeID中的“ Repsonsive Theme”。在转储/所有表中搜索“ localhost ”(或任何您选择的本地名称),尤其是wp_options并进行搜索和替换通常是不可避免的。
Frank Nocke

@FranKee我创建了一个插件wordpress.org/plugins/pitta-migration,该插件使用常量更新wp_options表,该表应涵盖大多数主题和插件
icc97 2015年

@ icc97:可爱。会看的。PS:好的标题图片,描绘了情况。
Frank Nocke

27

我最喜欢的黑客 /etc/hosts在您的机器上添加一个设置,使生产域指向您的开发箱。要部署到生产环境,您将所有文件同步并推送数据库。

这种策略的风险是显而易见的。您可能会将开发环境与生产环境混淆。

不过,这仍然是一个简单的解决方法。


5
是! 我很高兴我不是唯一想到这一点的人!dev和prod之间的任何差异都是不好的。完全消除这种差异远比尝试解决差异要好得多。而且此设置完全不需要任何工作。如果需要,甚至可以在具有修改后的主机文件的虚拟机上进行测试。
亚历山大·伯德

2
我非常喜欢这种方法,但是如何处理数据库推/拉?
Nenotlep 2015年

至于将开发人员与产品混淆的风险,我使用了一个Chrome插件来显示网页的IP地址。您会知道自己在当地时间127.0.0.1
kosinix '16

9

几个月前迁移到WP时,我想要类似的东西,所以我写了一个非常简单的shell脚本,该脚本在ssh上使用rsync和mysqldump:

http://snarfed.org/sync_wordpress

它不是复杂的或基于Web的,但我对此感到满意。


8

WP Engine是一项新服务,提供“一键式登台”:

WPEngine具有称为“登台”的独有功能。它的工作方式如下:在对博客进行可怕的更改之前,请单击“快照”按钮。我们会完整复制您的博客,并将其设置在单独的安全区域中。您可以随心所欲玩;什么都没有。只有当您准备好将其发布时,您才可以触摸您的主站点。

看起来这是一种非常容易的方法,可以快速地从开发过渡到生产,尤其是对于已经上线的站点。


3
确实,这是一个非常不错的选择,对许多人来说将是很棒的选择!当然,这不适用于嵌入式URL,也不适用于本地开发人员,因此他们可以将IDE与调试器一起使用。现在,如果WPEngine也可以创建一个可以合并本地部署的交互,那么它的确是真正的东西(Technosailor,您在听吗?)
MikeSchinkel 2010年

同意,那将是一个奇妙的补充。
特拉维斯·诺斯卡特

快照功能仅从生产复制到暂存,而不是相反。这对测试更改非常有用,但对部署到生产中则无济于事。
山姆

2
@sam实际上,他们最近才开始推出从暂存到生产的复制功能。wpengine.com/2013/04/user-portal-v2-and-staging-to-production
Travis Northcutt

7

复制器插件: 这是我一直在努力的插件。它目前处于测试阶段,但可以完成大多数网站的工作。现在,它针对较小的WordPress安装。 http://wordpress.org/extend/plugins/duplicator/

资源: 可在以下位置找到该插件的其他资源:http : //lifeinthegrid.com/duplicator/

社区: 请让我们知道您的成功或可能遇到的任何问题!为了更轻松地管理各个线程,请将问题发布到WordPress.org插件论坛。请不要将插件中的任何日志记录数据发布到在线论坛中。日志数据可以提交到我们的支持站点。


6

您可能会看看iThemes的产品BackUpBuddy。我只用了两次,每次都挂了一两个钩,但总的来说看起来很有希望。


5

我亲自处理与我在Github上的项目,被称为这一问题Autopress。我还没有一个完美的解决方案,但是我已经接近了,特别是wpengine的wpstage插件。


刚刚签出您的脚本。真好 据我了解,它会在服务器上安装新的WP。这里的问题是如何从开发过渡到生产。能帮上忙吗?
2010年

17
是这个吗?github.com/vluther/Autopress我建议在您的答案中创建链接,以便人们可以单击右键!
artlung 2010年

4
@麦克李:是的,你可以投票。看,我赞成artlung的评论。在评论的左侧悬停时查找向上箭头。
MikeSchinkel 2010年

我正在研究一种将所有内容保持在版本控制中的方法,然后将其从开发推进到生产。对于一些站点,我已经能够做到这一点而没有任何问题,但是仍然需要进行一些调整。
维德·路德

1
不知道是否这样,但是有一个WP Engine插件,用于跨主机迁移网站。它称为快照直接链接)。
joelhaus 2011年

5

这看起来很有希望。我们正在研究一些脚本来处理某些数据的迁移,例如wp-options,更改db中的路径,通过媒体进行复制。

我的问题是,在线站点在不断发展,而另一个站点正在开发中。我们工作的一个站点每天有20条帖子,每天有3,000多个评论。太多数据无法通过phpmyadmin或通过命令行进行移动。同样,由于某种原因,移动数据总是会导致UTF问题。

而且,现在看来菜单选项存储在数据库中了,我还要处理更多的事情。

我将所有代码都检入到SVN中,并通过FTP从服务器(Beanstalk)部署代码。但是,这不会为我更改数据库或激活新插件。

我现在的计划是在开发过程中创建清单文件,以对实时站点进行所有更改。

例如,文件将具有人类可读的行

它包括激活插件,wp选项移动,图像移动,页面移动。然后,我的插件将检测清单文件,并对登台站点进行所有更改。

一旦测试完并确定我拥有了所有东西,就可以确定它可以在生产中使用。

这个插件仍然只是一个主意,但是我为它编写了一些代码。

另外,如果只想更改数据库中的URL,则可以使用以下SQL。

只需$old$用旧域名和$new$新域名替换

update wp_postmeta set meta_value = replace(meta_value, '$old$' , '$new$') ;
update wp_posts set post_content = replace(post_content, '$old$' , '$new$') ;
update wp_options set option_value = replace(option_value, '$old$' , '$new$') ;

2
请注意,我的sql调用可能会破坏您的序列化数据。s:14:blogs.prod.com的长度编码为14。运行代码后,我们现在的s:14:dev.prod.com已损坏。应该在s:12:dev.prod.com上谨慎使用。
安德鲁(Andrew)2010年


3

我使用subversion的export命令安装WordPress文件(http://core.svn.wordpress.org/tags//)以及存储库中的所有插件(http://plugins.svn.wordpress.org//tags) //),然后只需压缩主题和自定义插件并正常安装即可。一旦所有这些都启动并且没有内容,我将导出测试数据库,并搜索/替换URL和文件路径(为媒体存储)并导入到空数据库中,然后只需在wp-config中切换数据库信息.php。通常需要我大约10-20分钟。


3

通常我登录到phpMyadmin上载数据库,然后将wp_options> siteurl和wp_options> home的内容编辑到期望的域。如果您需要更新帖子和页面内容中的URL,则可以在上传之前搜索/替换URL和.SQL文件上的媒体/上传路径。这是一项快速的工作。


3

尽管这里不乏好的解决方案,但本着共享的精神,我认为我应该将bash部署脚本添加到堆中:https : //github.com/jplew/SyncDB

SyncDB是bash部署脚本,旨在使繁琐的工作不再同步Wordpress网站的本地和远程版本。它允许在本地环境(例如MAMP)中工作的开发人员使用单个终端命令将更改快速“推”或“拉”入生产服务器或从其生产服务器中拉出。

该脚本与Mark Jaquith的WP-Skeleton一起很好地工作,并利用mysqldumpgitrsync通过两个简单的步骤来同步整个站点(数据库,代码和媒体):

./syncdb
git push hub master

3

我一直在使用http://wordpress.org/plugins/wp-clone-by-wp-academy/。效果很好!

只需3个步骤:

  1. 在两个站点上安装插件。
  2. 使用该插件在旧站点上生成备份。
  3. 取得它提供的备份URL,然后将其插入新站点上的插件页面,单击go,您的迁移将在几秒钟内完成!

它会自动调整所有URL(包括序列化字符串替换),因此不会丢失小部件配置等风险。

我唯一遇到的问题是某些数据库较大(约300MB)的网站,这些网站导入网站备份时导致PHP脚本执行超时。


3

截至2017年,这是我发现处理WordPress数据库从开发到生产的转移的两种最佳方法。

WP迁移数据库Pro / WP同步数据库

https://wordpress.org/plugins/wp-migrate-db/

这些WordPress插件可让您在WordPress安装之间推送,提取和同步数据库表。由于许多原因,这比查找/替换要好得多,因为它有:

  • 将数据库导出为MySQL数据转储(非常类似于phpMyAdmin)
  • 查找并替换URL和文件路径
  • 处理序列化数据
  • 允许您将其作为SQL文件保存到计算机中

我很喜欢自己做的工作,因此我建议您支持Brad Touesnard先生,并购买真实物品的许可证副本。WP Sync DB是复制品,因此始终落后于支持。使用此插件,过程非常简单:

  1. 在本地主机和生产环境上安装/激活插件
  2. 配置从本地主机/开发服务器到生产服务器的推送传输
  3. 填写要转移哪些表的规则,并定义要执行的查找和替换规则
  4. 而已!

数据库搜索和通过InterconnectIT替换WordPress数据库

https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

这个免费工具不是插件,而是安装在WordPress生产安装的根目录中。这不像WP Migrate DB Pro那样好,因为它需要一些手动步骤,但是仍然是一个始终有效的好选择。使用这种方法时,过程如下所示:

  1. 备份您的本地数据库,这是绝对必要的,因为我们将很快重新导入它
  2. 将脚本添加到安装根目录中的文件夹中
  3. 在数据库上运行查找并替换
  4. 导出数据库并将其保存在生产环境中
  5. 从步骤1重新导入备份以还原本地主机
  6. 连接到生产数据库并进行备份(在执行这些操作之前一如既往)
  7. 导入我们从步骤4开始执行查找/替换例程之后进行的导出

您可以使用更快的方法,但是这会导致生产站点停机,我认为这是不可接受的。这就是为什么我们称其为生产,对吗?


1

因为我在IIS中运行站点(我也运行asp.net,所以我需要Windows),所以我使用Msft中的WebPI安装新实例,然后复制模板并使用导入/导出来传输数据。

它并不完美,但是整个过程不到一个小时。

显然,拥有一键式解决方案会很好,但这是我发现最简单的方法。




1

当您问这个问题时,可能还没有解决这个问题,但是我已经使用了一个名为Blogvault的服务了几个月,它已经做到了这一点。我可能已经完成了50多次迁移(跨域,子域和Web主机),这并非一帆风顺,而且根本不需要时间。

它是一项付费服务​​(每个域/月),但不算多。


1

RAMP是Crowd Favorite提供的一个新的内容部署插件,看起来非常漂亮。不过,它的价格是250美元,所以我还没有尝试过。但是,可能只需要为自己节省时间就可以收回成本,所以我正在考虑。

与提到的大多数其他方法相比,它的最大好处是,它可以智能地合并帖子,注释等。这不仅是导入mysqldump,还更像是数据库的源代码控制。例如,在部署帖子时,如果产品中尚不存在标签,则还将部署该帖子的标签。


RAMP用于内容部署,而不是代码部署,但是我同意,它看起来很棒。他们现在有一个RAMP设置演示,因此您可以尝试这些功能。
Emzo 2012年

问题是关于内容部署,而不是代码部署,我从说“ RAMP是一个新的内容部署插件...” 开始回答我
Ian Dunn 2012年

1

让我放弃我的最爱之一:-)

// proven local<->live codefork (covers local network testing, i.e. from mobile devices):
$GLOBALS['is_local'] =  
    in_array( $_SERVER['REMOTE_ADDR'], array("127.0.0.1","::1")) || // simple localhost (IPv4 IPv6)
              $_SERVER['HTTP_HOST'] == 'local.workblog'          || // call by local name (adjust)
       substr($_SERVER["REMOTE_ADDR"],0,8) == '192.168.';           // (mobile) device in local network

$table_prefix  = NULL; // ensure scope

if ( $GLOBALS['is_local'] )  // LOCAL fork ------------------------
{
        ....
}
else  // STAGE/LIVE fork -------------------
{

...然后您从那里开始工作。DB_NAME,DB_USER ... table_prefix。就我个人而言,我在本地(以避免一些烦人的警告)上打开ALTERNATE_WP_CRON ,在两者(如果您不是开发人员)或仅直播(如果是)上都打开WP_DEBUG,那么另一个ini_set('display_errors', '0');直播应用也可以做得更好,最后,蚂蚁如上所述:WP_HOME和WP_SITEURL分别指向本地/实际网址。

差不多了,经典的WordPress上面什么也没有,“那就停止编辑!” 线...

192.168。部分可让您在本地网络中进行一些本地测试(即通过平板电脑或手机进行)

$ GLOBALS ['is_local']也可以在主题开发中派上用场,例如一些额外的调试输出等。


1
您可以使用WordPress Skeleton wp-config.php来设置WP_LOCAL_DEV常量以实现类似的效果
icc97 2015年

1

我已经使用了backupbuddy插件已有一段时间了。它使您可以备份数据库和所有文件,以zip格式下载或通过FTP直接发送到另一台服务器。它还会为您查找并替换URL。我通常大约需要5分钟才能完成整个过程。而且由于所有文件均已压缩,因此上载/下载过程更快。不,我不为他们工作,但是此插件确实使整个过程变得更加容易。




0

如果您尝试实现连续同步,建议您将rsync与自定义cron作业一起使用以重写任何url或特定于站点的数据。


0

遵循答案一段时间后,我创建了自己的小插件-Pitta Migration。原因是:

  1. 在这里尝试过的所有创意中,最简单的是WP_HOMEWP_SITEURL选项
  2. 然后,我用它们来设置两个匹配的wp_optionsURL-涵盖了插件/主题何时忽略这些URL
  3. 这使我对数据库中正在更改的内容有100%的信心
  4. 这也可以跨平台使用(所有这些bash脚本在Windows上都不能很好地播放)
  5. 很容易理解插件在做什么
  6. 除了这两个常量外,没有其他配置-将mysqldump和mysql导入本地数据库,插件会看到常量和表不同,并对其进行更新以匹配
  7. 没有文本搜索和替换
  8. 没有机会破坏您的数据库-我使用WordPress数据库对象进行两次更新,仅此而已
  9. 它可以很好地与WordPress Skeleton之类的东西配合使用,您可以在源代码管理中拥有所有内容并设置本地配置
  10. 我将其放在WordPress插件目录Github中,以便它是免费的,完全开源的,便于您分叉并易于安装
  11. 安装完成后,您可能会忘记它,它应该“正常工作”-它给您一些提示,说明数据库已被修改
  12. 它应该与任何备份/ FTP /还原过程一起使用

0

我认为,最简单的方法是手动传输。只需将wp-content文件夹和wp-config.php文件复制到新主机。从旧主机导出数据库,并将其导入新主机的新数据库。

在新主机数据库中,转到wp-option表,然后将站点URL和Blog URL从旧主机更改为新主机地址。例如从http:// localhost / wphttp://example.com

现在,在wp-config文件中,只需使用新的主机信息更改数据库和用户的信息即可。

现在登录到新的wp-admin并进入设置并保存永久链接。

大功告成 我认为这很简单,无需使用任何插件。

我尝试了不同类型的插件,所有这些都有很多问题。

所以我更喜欢这种简单的手动传输,我认为它更容易。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.