自我更新PHP+；MySQL应用程序？

现在，桌面应用程序的自我更新是相当标准的做法。在Mac电脑上，我书中使用的每一个非苹果程序都是一个即时的胜利。对于Windows开发人员。我还没有找到关于自我更新web应用程序的信息，希望您能提供帮助

我正在构建一个像Wordpress或Drupal一样安装的web应用程序——将其解压缩到一个目录中，点击一些安装页面，就可以开始了。为了具有广泛的服务器兼容性，我被要求使用PHP和MySQL——这是**MP吗？无论如何，它必须广泛跨平台。在上下文中，这基本上是一个面向小型企业的统一web消息传递应用程序。想想webmail，它不是另一个CMS平台

我想了解自我更新的web应用程序。首先，（1）这是个坏主意吗？从Wordpress 2.7开始，自动更新只需一个按钮，这似乎很简单，但我可以想象，这可能会在很多方面出错。另外，web文件可由web进程写入的想法难道不是一个安全漏洞吗

（2） 值得花时间开发吗？世界上可能有数以百万计的WP安装，因此WP团队花时间简化安装，在全世界节省数百万工时，这可能是值得的。我只能想象几千次安装我的软件——构建自我升级是否值得投入时间，或者我是否可以假设那些足够成熟、能够下载和安装web软件的用户可以通过升级清单

如果这不是一个安全灾难或浪费时间，那么（3）我正在寻找任何曾经这样做过的人的建议。您是否在数据库中保留版本表？如何管理数据库升级？在自更新web应用程序的上下文中，您使用什么方法回滚部分升级？使用ORM层是更容易还是更难？你是保留一个版本变更的增量，还是每次都把整个事情搞砸

---

我很感激你的想法。

坦白说，这确实取决于你的用户群。有很多PHP应用程序不会自动升级。他们的用户要么技术水平足以处理升级过程，要么就是不升级

我打算采取两个步骤：

1） 认真问问自己，你的用户可能真正需要什么。自我更新是否足以促进采用，从而证明额外工作的合理性？如果你确信答案是肯定的，就去做吧

既然你在这里问，我猜你还不知道。在这种情况下，我希望第2步：

2） 发布版本1.0，但不包含此功能。等待用户反馈。您的用户可能会立即要求更简单的升级过程，在这种情况下，您应该优先考虑它。或者，您可能会发现您的用户更关心一些其他功能

---

猜测用户想要什么而不询问他们是浪费大量开发时间在人们实际上并不需要的东西上的好方法。

我想你已经排除了这一点，但你可以将其作为一项服务来托管。（Think wordpress.com）

我认为你最好的选择是一个更新检查机制，当有更新时会提醒管理员

---

正如您所提到的，存在许多潜在的安全问题。由于这些原因，我建议不要这样做。相反，请尝试创建一个相当智能的升级脚本。

我建议您使用和打包应用程序。然后，用户可以通过标准接口（pear）升级应用程序。这不是完全自动的（除非用户在PEAR上运行某种自动化），但它是标准的，所以任何系统管理员都可以维护它。

< P> >我的2美分：我将考虑在CMS中自动更新应用程序作为安全漏洞，因此，如果您决定编写此功能，您应该考虑实现不同级别的这种行为：

• 自动更新
• 检查更新并通知
• 禁用

---

我最近一直在考虑数据库模式更改方面的问题。目前，我正在深入研究WordPress，看看他们是如何处理版本之间的数据库更改的。以下是我到目前为止的发现：

$wp\u db\u version

从

wp includes/version.php

加载。此变量对应于Subversion版本号，并在更改

wp admin/includes/schema.php

时更新。（可能是通过钩子？我不确定。）加载

wp admin/admin.php

时，从数据库读取名为

db_version

的WordPress选项。如果此数字不等于

$wp_db_version

，则加载

wp admin/upgrade.php

wp admin/includes/upgrade.php

包含一个名为

dbDelta（）

的函数

dbDelta（）

upgrade.php
然后运行名为
upgrade\u all（）
的函数，如果
$wp\u db\u version
小于目标值，该函数将运行特定的
upgrade\u NNN（）
函数。（即，如果数据库版本低于7499，将运行WordPress 2.5.0升级版的
upgrade_250（）
）。每个函数都运行自己的数据迁移和填充过程，其中一些过程在初始数据库设置脚本期间调用。很好地减少了重复代码

所以，这是一种方法。
是的，如果PHP在没有警告的情况下从互联网上的某个地方重写其文件，这将是一种安全功能。无法保证服务器正确连接到您的更新服务器（它可能会下载某些人编写的代码）