当前位置: 首页>>网站问题>>正文


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

webfans 网站问题 , , , , 去评论

问题描述

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

有更好的方法吗?

最佳解决方案

@Insanity5902:从一个盒子到另一个盒子的WordPress网站的部署从第一天起我就开始使用WordPress了。 (Truth-be-told在我开始使用WordPress之前,它是一个带Drupal的PITA 2年,所以问题当然不仅限于WordPress。)

让我感到困扰的是,每当我需要移动一个网站时,我就不得不经常花费大量的精力,这使我无法像我希望的那样经常进行部署。所以大约4-6个月前我开始研究一个插件来解决webhost迁移问题和I mentioned my ideas on the WP Tavern forum

快进到今天,我几乎让它工作,我很方便地称它为“WP Migrate Webhosts”。即使插件仍然是非常多的beta(可能甚至是alpha),但我认为我已经准备好让人们开始敲打它了。

设想的use-case是:

  1. 首先,开发人员通过FTP处理上传所有更改的主题和插件文件,

  2. 然后将开发MySQL数据库完整地上传到测试服务器

  3. 然后运行插件以将先前域中的任何引用迁移到新域。 (我的插件不会尝试解决新数据库字段或表与实时数据的合并;这是一个更大的问题,我不知道如何解决。)

您可以从我的网站上获取download the plugin并解压缩到您的插件目录中(如果您不知道如何执行此操作,那么此插件不适合您,因为它需要有人知道他们在做什么才能使用它。)我会保留这个插件在线,直到我发布到WordPress.org,之后你应该在那里寻找它。

要使用它,您可以在wp-config.php中采用不同的方法,通过注释掉四个(4)定义DB_NAMEDB_USERDB_PASSWORDDB_HOST,然后注册webhosts的默认值,然后注册有关每个webhost本身的信息。以下是wp-config.php的部分内容(注意第一部分是不需要的代码注释掉,并注意我在本地机器上使用non-routable .dev顶级域设置我的主机文件,以使day-to-day开发更容易。在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');

希望这(大部分)是自我解释的。我试图尽可能地使代码干净但不幸的是它需要在webhost注册代码块之前和之后的那两条神秘的require_once()行,因为在调用wp-config.php之前我无法使用”hook” WordPress。

更新wp-config.php后,您只需使用URL快捷方式wp-migrate-webhosts即可进入管理界面,如下所示:

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

上面将带您进入如下所示的管理屏幕,该屏幕具有相当多的描述文本,并允许您在选择要迁移的域之后通过单击从任何其他webhost域迁移(注意:此示例显示了从测试/阶段/现场服务器到本地开发,但请放心,它可以迁移到碰巧所在的任何域。这也意味着该插件非常适合使用现有的实时站点并快速启动本地开发环境! ):

development,deployment,production,staging,wordpress

如果不清楚,在此上下文中”migration”意味着更新当前数据库中的所有引用以适合当前定义的webhost(并且通过检查$_SERVER['SERVER_NAME']来嗅探”current”。)

这个插件有什么好处,它实现了一些基本的迁移,但任何人都可以挂钩并执行自己的迁移。例如,如果您添加一个库存插件,其中存储了数据库中图像的完整路径,您可以挂钩migrate_webhosts操作,该操作将作为元数据数组传递给”from” webhost和”to” webhost,您将被允许执行任何操作您需要使用SQL或任何适用的WordPress API函数在数据库中执行迁移。是的,我们任何人都可以在没有插件的情况下做到这一点,但是如果没有插件,我发现编写所需的所有代码都需要付出更多的努力。使用该插件,可以更轻松地编写这些小钩子并将其完成。

您可能还发现我的迁移在边情况下失败,我没有测试过,也许您可​​以帮我改进插件?任何想要通过我的Gmail帐户给我发电子邮件的人(我的别名是”mikeschinkel.”)

此外,插件可以接受user-define虚拟主机提供商的元数据,除了它承认像databaseuserpasswordhostdomain等一个完美的例子的那些可能是googlemaps_apikey在那里你可以存储每个域的不同的API密钥,你的谷歌Map的插件需要正确运行(使用谷歌Map插件的人中谁没有将应用程序部署到实时服务器,忘记将代码更改为正确的API密钥?来吧,老实说…… :)有了这个插件,你的 register_webhost()阵列中的googlemaps_apikey元素和一个小的自定义migrate_webhosts挂钩你可以有效地消除这个问题!

那是关于它的。我在WordPress的答案交换中启动了这个插件,因为@ Insanity5902的问题引发了它。如果合适,请告诉我这是否有用,如果没有,请通过电子邮件告诉我。

附:如果您决定使用此功能,请记住它是alpha /beta,这意味着它会发生变化,因此如果您想现在使用它,请准备好进行一些小手术,然后在被许多人殴打后使用已发布的版本。

P.P.S.我的目标是什么?我很高兴看到这个迁移到WordPress核心,以便每个人都可以访问它。但在此之前,甚至可以考虑很多人都有兴趣使用它来确保它实际上解决了更多的问题,然后它可能会产生。因此,如果你喜欢这个想法,那么一定要使用它,并帮助我获得动力,最终有希望包含在WordPress核心中。

次佳解决方案

如果可能,我在wp-config.php中设置WP_HOMEWP_SITEURL。这与数据库转储和导入相结合,是我熟悉的所有解决方案中最简单的。

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

第三种解决方案

我最喜欢的黑客;在/etc/hosts中添加一个设置,使生产域指向您的计算机上的开发框。要部署到生产,您可以rsync所有文件并推送数据库。

这一战略的风险很明显;您可能会将开发环境与生产环境混淆。

它仍然很容易解决。

第四种方案

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

http://snarfed.org/sync_wordpress

它不复杂或基于网络,但我很高兴。

第五种方案

WP Engine是一项新服务,提供“One-Click分期”:

WPEngine has an exclusive feature called “staging.” Here’s how it works: Before you make a scary change to your blog, click the “snapshot” button. We make a complete copy of your blog and set it up in a separate, safe area. You can play with anything you want; nothing’s live. Only when you’re ready to make it live do you touch your main site.

看起来是一种非常简单的方法,可以快速从开发转移到生产,特别是对于已经存在的网站。

第六种方案

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

资源:可以在此处找到插件的其他资源:http://lifeinthegrid.com/duplicator/

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

第七种方案

您可以查看iThemes的产品,名为BackUpBuddy。我只使用了两次,每次都有一两个故障,但整体而言看起来很有希望。

第八种方案

我个人在Github的项目中解决了这个问题,名为Autopress。我还没有一个完美的解决方案,但我越来越近了,特别是wpengine人的wpstage插件。

第九种方案

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

我遇到的问题是,现场网站继续增长,而另一个正在开发中。我们工作的一个网站每天有20个帖子,每天有3,000多条评论。这是用phpmyadmin或命令行移动的太多数据。此外,由于某种原因,移动数据总是会导致UTF问题。

此外,现在看起来菜单选项存储在数据库中,我还有更多需要处理的问题。

我将所有代码检入SVN,并通过FTP从服务器(Beanstalk)部署代码。这不会对我进行DB更改或激活新插件。

我现在的计划是在开发时创建一个清单文件,以便对现场网站进行所有更改。

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

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

一旦我测试了并且确定我得到了所有东西,我可以肯定它可以用于生产。

这个插件仍然只是一个想法,但我有一些代码为它编写。

此外,如果要仅更改数据库中的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$') ;

第十种方案

两个具有类似目标的Google Summer of Code项目:

参考资料

本文由朵颐IT整理自网络, 文章地址: https://duoyit.com/article/3000.html,转载请务必附带本地址声明。