PHP：创建可扩展的CMS系统 [英] PHP: Creating Extensible CMS System
问题描述
我已经从客户那里得到了一个新的任务，它基本上是为演员/歌手等创建了一个客户端将会出售的CMS。
它将基本上是一个包，并将与WordPress几乎类似的工具，你只是交给谁购买，但当然这不会是一个博客平台。它将允许开发人员：
- 添加插件/小部件
- 添加模板/主题
我以为 观察员Patten 可能很有用，但我不确定。您可以建议如何创建这样灵活/可扩展的CMS：
- 添加插件的能力（例如WordPress）
- 添加主题/模板的能力（例如WordPress）
- 设计模式
- 什么不是（不确定 - 打开建议）
感谢您的想法和帮助。
观察者的罚款，但你将不得不考虑超越基本模式。规范的Observer / Subject模式只将Subject对象发送给Observer，没有其他的，甚至不是 它被通知。
最初，解决方案似乎也包括通知观察员的原因，但是最终可能会通知观察者不关心某些通知。更好的解决方案可能要求观察员也要求他们想收到的通知列表。
但这也是一个问题。为了使观察者实际上将自己附加到主题，必须实例化。每一次。即使他们永远不需要。
所以，我们很快就达到了一个规范的PHP插件实现：hooks。钩子使用与观察者/主体相同的概念，但实施方式在一个非常重要的方面是不同的：实际的观察者没有被实例化以观察主体。相反，受试者向各种中央存储库发送通知。此存储库配置有所有安装和激活的插件（Observers）的列表，并包含每个插件想要接收的所有事件的列表。每个插件，只有当事件发生时，通常通过静态方法通知，而不是通过创建插件的实例并通知它。 call_user_func_array ，一个好的自动加载器使这个非常简单。
因此，您可以为所有插件创建一个简单的界面来实现。您需要的方法包括但不限于：
- 提取插件数据的东西，例如名称，作者，官方网站，版本等人力资源信息。
- 返回插件想要订阅的事件的方法。
- 安装方法对于插件需要做的事情，例如操纵数据库。
- 卸载方法也可以方便。
- 可以接收事件通知并返回任何数据的（可能是静态的）方法。
根据你插入的距离概念，你最终可以使用具有用户可配置选项的插件。您可能需要考虑到这一点。这条路就是疯狂和配置系统。
为了使插件生效，您将需要在所有地方放置钩子，而经常与最终用户合作，在需要的地方添加新的钩子。
小部件可以轻松地以类似的方式工作，因为在页面呈现之前调用的插件。 / p>
主题/模板，哦，我的。你可能有两个很大的选择。
- Smarty或类似的模板引擎。或者你自己的不是PHP模板引擎。
- PHP模板
由您的最终用户驱动。 Smarty是非常有限的，但如果你想确保只有批准的代码在模板中运行，这可能是一个可行的选择。此外，允许在应用程序本身中编辑Smarty模板并不安全。
另一方面，Wordpress模板的工作原理之一是，纯PHP。他们可以调用Wordpress API中暴露的任何方法，甚至自己有趣的逻辑。如果您期望您的最终用户具有技术上的技能，或至少在技术上胜任，那么PHP模板就是要走的路。另一方面，如果恶意用户进入管理员位置，允许在应用程序内编辑PHP模板可以打开巨大的潜在安全漏洞。您可能想要将编辑限制为文件系统。
虽然这涵盖了HTML创建，您也应该考虑CSS。您的最终用户能否直接操作CSS？他们会想吗？如果您的默认模板包含足够的语义类，那么如果他们知道他们在做什么，他们可能会做很多的设计，而不是很多的努力。另一方面，您的最终用户可能不知道什么是CSS，所以他们可能想要，哦，说，颜色选择器和预构建的颜色方案，以及配色方案选择器，以及其他这样令人讨厌的事情来构建。现在最好想想这些恐怖。
杂项。
如果没有草稿和发布状态的概念，则CMS不会完整。我没有任何建议，除了这个第一个代码。如果您的客户或最终用户希望进行任何形式的历史归档，管理审批机制，或任何其他除草稿/发布任何内容，但只是简单的状态字段，您都需要知道。 （我被这个人吓坏了，我们设计了一个简单的发布/未发布的模型的整个系统，当我们意识到它不起作用时，通过规范构建和相关的原型代码得到约9/10我们必须做一些远远超过实际满足客户需求的事情，重建粗略的计划是迄今为止遇到的最大的单次汇总。）
你会使用ORM吗？如果没有，请务必使用适当的数据库接口库。 PDO，或者可能来自PEAR或者Zend_Db的东西。您将不可避免地有一个客户将坚持代码在Oracle或MSSQL上运行。或SQLite。告诉他们可以完成（有些努力）会很好的。插件作者也会感谢你的理智。不要自己滚动。
（再次，与你的代表级别，我希望你已经熟悉了我所说的一切，我做的是分散自己的注意力同时思考我自己的一套编码问题...）
I have been given a new task from the client which is basically creating a CMS for actors/singers and the like that client will be selling out to them.
It will basically be a package and would work out-of-box pretty much similar to WordPress, you just hand over to whoever buys it but of course this is not going to be a blogging platform. It will allow developers to:
- Add plugins/widgets
- Add templates/themes
I thought Observer Patten may be useful but I am not that sure about it. What you guys could suggest to create such flexible/extensible CMS in terms of:
- Ability to add plugins (for example like WordPress)
- Ability to add themes/templates (for example like WordPress)
- Design Pattern
- What Not (Not sure - open to suggestions)
Thanks for your ideas and help.
Observer's fine, but you're going to have to consider going beyond the basic pattern. The canonical Observer/Subject pattern only sends the Subject object to the Observer, nothing else, not even why it's being notified.
Initially, the solution might seem like also including the reason for the notification to the Observer, but then you might end up notifying Observers that don't care about certain notifications. A better solution might be requiring Observers to also ask for a list of notifications they'd like to receive.
But that also presents a problem. In order for the Observers to actually attach themselves to Subjects, they have to be instantiated. Every single time. Even if they'd never be needed. That's silly.
So, we've quickly reached one of the canonical PHP implementations of plugins: "hooks". Hooks use the same concept as Observer/Subject, but the implementation is different in a very important way: the actual Observers aren't instantiated in order to Observe Subjects. Instead, Subjects send a notification to some variety of central repository. This repository is configured with a list of all installed and activated plugins (Observers), and contains a list of all of the events that each plugin wants to receive. Each plugin and notified only when the event takes place, often through a static method rather than by creating an instance of the plugin and notifying it. call_user_func_array and a good autoloader makes this incredibly trivial.
You can therefore create a simple Interface for all plugins to implement. Methods that you'll need include but are not limited to:
- Something to fetch data about the plugin, such as it's name, author, official website, version, etc. Human-consumable information.
- A method returning the events that the plugin wants to subscribe to.
- An installation method, for things the plugin needs to do in order to install itself, such as manipulating the database.
- An uninstallation method might be handy as well.
- The (probably static) method that will receive event notifications and return whatever data is needed.
Depending on how far you take the plugin concept, you could end up with plugins that have user configurable options. You might need to take that into account. Down that road lies madness and configuration systems.
In order to make plugins effective, you're going to need to place hooks everywhere, and frequently work with end-users to add new hooks where they are needed.
Widgets can easily work in a similar way, as plugins that get called prior to page rendering.
Themes/templates, oh my. You probably have two big options.
- Smarty, or a similar template engine. Or your own not-PHP template engine.
- PHP templates.
This decision will be driven by your end users. Smarty is incredibly limiting, but if you want to make sure that only approved code runs in a template, it might be a viable option. Furthermore, it's not unsafe to allow editing of Smarty templates right in the application itself.
On the other hand, one of the reason Wordpress templates work so well is that they're pure PHP. They can call any method exposed in the Wordpress API, and even do their own interesting logic. If you expect your end users to be technically minded, or at least technically competent, then PHP templates are the way to go. On the other hand, allowing editing of PHP templates within the application can open up a huge potential security hole if a malicious user gets into the admin bits. You probably want to restrict editing to the filesystem.
While this covers HTML creation, you should also take CSS into consideration. Will your end-users be able to manipulate CSS directly? Will they want to? If your default templates include enough semantic classes, they can probably do a great deal of styling with not a lot of effort, if they know what they're doing. On the other hand, your end-users might not know what CSS is, so they might want, oh, say, color pickers and pre-built color schemes, and a color scheme chooser, and other such annoying things to build. It's probably best to think about those horrors now.
Miscellaneous things.
No CMS would be complete without the concept of drafts and publish states. I don't have any advice for you here, other than code this first. If your customer or the end-users want any sort of historical archiving, managerial approval mechanism, or anything else that makes draft/published anything but a simple state field, you need to know very soon. (I've been bitten horribly by this one. We'd designed the entire system around a simple published/not-published model, and got about 9/10ths through spec building and related prototype code when we realized it wouldn't work and we'd have to do something far, far more complex to actually meet customer requirements. Rebuilding the rough plan was the single largest time-sink we encountered so far.)
Will you use an ORM? If not, be sure to use a proper database interface library. PDO, or maybe something from PEAR, or maybe Zend_Db. You'll inevitably have a customer that will insist that the code runs on Oracle or MSSQL. Or SQLite. It'll be nice to tell them it can be done (with some effort). Plugin authors will thank you for the sanity as well. Don't roll your own.
(Then again, with your rep level, I expect that you're already familiar with pretty much everything I've said. Ah, the things I do to distract myself while thinking about my own set of coding problems...)
这篇关于PHP：创建可扩展的CMS系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
