我在一家为制药行业做网站的公司工作，我们经常需要获得法律批准，然后才能实时推动任何更改。所以，我想将我们的很多工作迁移到 CMS 环境，特别是 wordpress，但我们需要有一个暂存环境的能力。是否可以不发布页面，而是将其发布到有人可以通过链接作为站点浏览的登台环境。所以基本上有2个站点，一个staging 一个live？
问问题
1901 次
6 回答
3
Generally speaking other "answers" here are correct, there are alternatives to WordPress that have better built-in support for staging environments and build migrations. However the suggested alternatives aren't exactly equal substitutes to the WordPress platform, so I think it's best to answer the question at hand instead.
WordPress does not natively support hosting the same site from two different hosts. The core relies on absolute URLs stored inside the database and are used in just about every aspect of the core logic. This results in a number of superfluous bugs like the 500 or so related to SSL access because they try to dynamically alter all http:// schemes to https:// on the fly.
As a result when you host on dev.example.com and migrate to staging.example.com and again to www.example.com you have to do very careful search & replace manipulations on the database export each time you switch hosts. And this causes additional problems when you find out that many popular WordPress plugins serialize the URL into values in the database. So when you search & replace dev.example.com with staging.example.com the serialized data which contained the character length of the original value no longer deserializes with the new longer format. Some core contributors believe the solution to this later problem is to only ever setup staging sites with the same number of characters as the production account...
In a similar vein they also suggest swapping host mappings and only ever using the production.com URL on all hosting environments. Depending on your particular use-case requirements this is probably not a valid solution if you need to provide access to off-site clients, tech-illiterate users (versus tech-literate users of course.)
But WordPress itself has a number of great features otherwise and is a very adaptive and powerful rapid development platform. As a result you can extend the core framework to do much of what you need from it. When I was presented with this situation, I had to develop a solution that was viable for all circumstances. Traditionally this problem is solved with root-relative URLs, they work in cross-hosting environments, and they don't suffer from scheme changes, port changes or subdomain swapping practices that are common with staging migrations.
With this plugin: http://wordpress.org/extend/plugins/root-relative-urls/
(biased? yes, I wrote this plugin.) you get root-relative URLs where it's important and dynamic hosts where root-relative URLs don't work (like rss feeds.) All that remains from migrating the site to different hosts is to move the wp-config.php file outside of the www root (one level up is supported natively by WordPress.) so you can maintain different copies on different servers. Or alternatively you can use basic if-statements to distinguish hosts by server name and define key WordPress constants based on the server. In the end your content, code & data will transition seamlessly.
As a note of concern, the referenced plugins require setting write access to the wp-config.php file, a very bad practice from a security perspective for production or publicly accessible servers. Perhaps you can comfortably implement this in a restricted staging environment but then you'd need to disable and remove the plugin in production transitions.
Long story short, yes you can host WordPress in multiple host environments. The long-touted solutions are very case-specific and option-restricted because of the core architecture. But the framework is flexible enough to overcome the core deficit. This core design decision will probably change at some point in the future given the amount of effort the core developers continually spend on overcoming the cascading issues. But there are also devout defenders of the absolute URL religion that will keep the practice in place for the time being. Maybe a different platform that supports server migrations natively (pick just about any of them because most do) would be a better option for you now.
于 2011-11-09T04:40:51.060 回答
2
有可能：查看这个Github Gist以查看有关如何使用 wp-config.php 文件切换环境的示例。此外，请查看 wordpress.stackexchange 以了解有关此问题的其他一些问题，这些问题可以让您更深入地了解您应该考虑的内容。
于 2011-07-26T22:35:05.187 回答
1
Greg，一个更好的带有暂存环境的 CMS 将是 Silverstripe (silverstripe.org)。此 cms 允许您浏览整个临时站点。
于 2011-07-26T21:36:26.937 回答
1
我认为您可以尝试使用一些插件。例如（在官方 wordpress 插件 repo 上快速搜索）wp-deploy或Dev and Staging Environment Plugin（可能已过时）。
或者作为替代方案，您可以尝试使用不同的 wp-config.php 文件 - 一个用于生产环境，一个用于开发环境，并通过检查请求的 url 来切换它们。
于 2011-07-27T10:01:21.813 回答
0
如果您需要使用 WP，并且只需要发布从登台到实时站点的一个或多个页面，为什么不在需要发布的页面上实现一种标签（由实时站点访问者看到）？简单地调整您的模板以显示带标签或不带标签的页面，您就完成了！然后，您可以只使用一个站点并在其上维护公开可用和未批准的页面。
您还可以维护站点（阶段）的本地副本，并有一些脚本将其（全部）上传到您的主机 - 易于自动化任务。在这种情况下，您可能需要考虑将整个站点呈现为 HTML 页面并将此 HTML 上传（简单 rsync）到托管 - 实时站点将很难被破坏，因为那里没有动态脚本！
但也许你真的不应该选择WP？有很多 CMS 支持 write-approve-publish 方案。
于 2011-07-27T09:37:02.383 回答
0
借助此插件，您只需单击两次即可创建 WordPress 暂存环境：https ://de.wordpress.org/plugins/wp-staging/
披露：我是这个插件的作者。所以问我任何关于它的事情。
于 2015-08-21T13:44:59.163 回答