PHP：创建可扩展的CMS系统 [英] PHP: Creating Extensible CMS System
问题描述
我从客户那里得到了一个新的任务，基本上是为演员/歌手等创建一个CMS，客户将向他们出售。
它基本上是一个包，并将开箱即用，类似于WordPress，你只是移交给谁买的人，但当然不会是一个博客平台。它将允许开发人员：
- 添加插件/小部件
- 添加模板/主题
我认为 观察者Patten 可能有用，但我不确定。你可以建议用以下方式创建这种灵活/可扩展的CMS：
- 能够添加插件（例如WordPress） li>
- 可添加主题/模板（例如WordPress）
- 设计模式
- - 打开建议）
感谢您的想法和帮助。
观察者很好，但你必须考虑超越基本模式。规范的观察者/主体模式只将主体对象发送给观察者，没有别的，甚至为什么它被通知。
解决方案似乎也包括通知观察者的原因，但是然后你可能最终通知观察者不关心某些通知。更好的解决方案可能是要求观察者也要求他们想要接收的通知列表。
但这也提出了一个问题。为了让观察者实际上将自己附加到主体，它们必须被实例化。每一次。即使他们永远不需要。这是 。
因此，我们很快就达到了一个规范的PHP插件实现：hooks。钩子使用与Observer / Subject相同的概念，但实现方式的不同在一个非常重要的方式：实际Observers不实例化为了观察主题。相反，主体向各种中央存储库发送通知。此存储库配置有所有安装和激活的插件（Observers）的列表，并包含每个插件要接收的所有事件的列表。每个插件并且只在事件发生时通知，通常通过静态方法，而不是通过创建插件的实例并通知它。 call_user_func_array 和一个良好的自动加载器使这令人难以置信的微不足道。 因此您可以创建一个简单的接口， 。您需要的方法包括但不限于：
- 用于获取插件的数据的东西，例如名称，作者，
- 一个返回插件想要订阅的事件的方法。
- 安装方法
- 卸载方法也很方便。
- >
取决于插件的插入位置概念，您可能最终得到具有用户可配置选项的插件。你可能需要考虑到这一点。这条路在于疯狂和配置系统。
为了使插件生效，你需要在所有地方放置挂钩 经常与最终用户一起工作，在需要的地方添加新的挂钩。
窗口小部件可以以类似的方式工作，就像在页面呈现之前调用的插件一样。 / p>
主题/模板，哦，我。您可能有两个大选项。
- Smarty或类似的模板引擎。或您自己的非PHP模板引擎。
- PHP模板。
由您的最终用户驱动。 Smarty是令人难以置信的限制，但如果你想确保只有批准的代码在模板中运行，它可能是一个可行的选择。此外，允许在应用程序本身中编辑Smarty模板并非不安全。
另一方面，WordPress模板工作原理之一是，重纯PHP。他们可以调用任何暴露在Wordpress API中的方法，甚至做自己感兴趣的逻辑。如果你期望你的最终用户是技术上的，或至少在技术上胜任，那么PHP模板是要走的路。另一方面，允许在应用程序中编辑PHP模板可以打开巨大的潜在安全漏洞，如果恶意用户进入管理位。您可能希望限制对文件系统的编辑。
虽然这包括HTML创建，但您也应该考虑CSS。您的最终用户能够直接操纵CSS吗？他们想要吗？如果你的默认模板包含足够的语义类，他们可能做很多样式，而不是很多的努力，如果他们知道他们在做什么。另一方面，你的最终用户可能不知道CSS是什么，所以他们可能想，噢，说，颜色选择器和预构建的配色方案，一个配色方案选择器和其他这样恼人的事情建设。
$ b
其他的东西。
$ b b
如果没有草稿和发布状态的概念，CMS就不会完成。我在这里没有任何建议，除了先编码这。如果你的客户或最终用户想要任何历史归档，管理批准机制，或任何其他草案/发布任何东西，但一个简单的状态字段，你需要很快知道。 （我已经被这个可怕的，我们设计了一个简单的发布/未发布的模型的整个系统，并通过规范构建和相关的原型代码约9/10，当我们意识到它不会工作，我们必须做一些远远更复杂的工作，以实际满足客户的要求。重建粗略计划是迄今为止我们遇到的最大的一个时间点。）
你会使用ORM吗？如果没有，请确保使用正确的数据库接口库。 PDO，或者可能是来自PEAR的东西，或者可能是Zend_Db。您将不可避免地有一个客户坚持代码在Oracle或MSSQL上运行。或SQLite。这将是很高兴告诉他们可以做（用一些努力）。插件作者也会感谢你的理智。 不要自己滚动。
（再一次，你的rep水平，我希望你已经熟悉了我所说的几乎所有的东西。而思考我自己的一组编码问题...）
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屋！
