为您的下一个Web项目考虑eZ Publish CMS的9个理由

介绍 (Introduction)

With the recent refactoring of eZ Publish content management system as a full stack Symfony application it should be interesting for a broader PHP public to consider it as a content management solution. We at Netgen have been using it for almost a decade and would like to share our reasons why it is a good choice in certain cases.

随着最近eZ Publish内容管理系统作为完整的Symfony应用程序重构,对于广大PHP公众来说,将其视为内容管理解决方案应该是很有趣的。 Netgen我们已经使用了近十年,并希望分享我们在某些情况下为什么它是一个不错的选择的原因。

Before going deeper into the reasons why someone should consider eZ as a CMS solution, lets note a few disclaimers and audience filters:

在深入探讨将eZ视为CMS解决方案的原因之前,请注意一些免责声明和受众过滤器:

  • if the development team is really small or the project is just a simple web site then there is no good incentive to consider eZ. There are lots of other solutions that are easier to learn.

    如果开发团队很小,或者该项目只是一个简单的网站,则没有很好的动机考虑使用eZ。 还有许多其他更容易学习的解决方案。

  • if your web project doesn’t need content management or that part of the project is very simple, there is no good incentive to consider eZ either.

    如果您的Web项目不需要内容管理,或者项目的那部分非常简单,那么也没有很好的动机考虑使用eZ。

This post is about reasons why you should consider eZ, it’s not about praising it is an ultimate solution. It has its share of problems, like the following ones:

这篇文章是关于您应该考虑eZ的原因,而不是赞美它是最终的解决方案。 它有很多问题,例如以下问题:

  • Currently eZ is shipped as dual stack (version 5.* with new and legacy code) and this could be an obstacle to less experienced teams. Recently I discussed on our blog about the hybrid approach we are currently taking and in short: it’s not simple. But its a temporary situation which causes some bad side effects like confusing dual documentation, etc. Installation could also be troublesome like Sitepoint’s editor Bruno discovered recently. But by the end of the year eZ should release a developer preview version with the new stack only. Next year the first stable version could hit the streets (named : eZ Publish 6 or eZ Platform).

    当前,eZ以双栈形式(带有新代码和旧代码的5. *版本)提供,这可能是经验不足的团队的障碍。 最近,我在博客上讨论了当前正在采用的混合方法 ,总之:这并不简单。 但是它是一种临时情况,会导致一些不良影响,例如混淆双重文档等。 安装也可能很麻烦,例如Sitepoint的编辑器Bruno最近发现的。 但是eZ应该在今年年底之前发布带有新堆栈的开发人员预览版。 明年,第一个稳定版本可能面世(名为:eZ Publish 6或eZ Platform)。

  • Historically, it always had a steep learning curve. This might be the number one reason why eZ didn’t get more traction over the years. With the new stack implemented as a Symfony application this could change. Putting aside the transition situation, where some features are not yet implemented on the new stack (hence falling back to legacy), the new stack should be easier to learn as the development practices are more common (especially to Symfony developers) and less specific only to eZ.

    从历史上看,它总是有一个陡峭的学习曲线。 这可能是多年来eZ没有获得更多关注的第一原因。 通过将新堆栈实现为Symfony应用程序,这可能会改变。 撇开过渡情况,即某些功能尚未在新堆栈上实现(因此又回落为旧版),由于开发实践更为普遍(特别是对于Symfony开发人员)且仅不太具体,因此新堆栈应更易于学习。到eZ。

  • The Community is not very big. Some prefer 10000 active developers behind a product, but this is not the case here. Actually, the community is quite active for its size and it consists of people from companies and larger teams that use eZ. And given the fact that Symfony is now the underlying PHP framework, the community could get larger very soon.

    社区不是很大。 有些人更喜欢10000名活跃的开发人员来支持产品,但事实并非如此。 实际上,社区的规模非常活跃,由来自使用eZ的公司和较大团队的人员组成。 考虑到Symfony现在是基础PHP框架,社区很快就会扩大。

If you are not completely repelled by the problems, lets focus on the good side: reasons why I think PHP developers should consider eZ Publish’s new stack for their next content oriented web project.

如果您还没有完全摆脱问题的困扰,请着眼于好的一面:我认为PHP开发人员应为下一个面向内容的Web项目考虑eZ Publish的新堆栈。

1.它是开源的 (1. It’s open source)

Yes, it certainly sounds obvious for the readers of this portal, but its still worth emphasizing. There is still a lot of content managed with either agency or in-house developed software, more or less closed source. As a professional who builds solutions on top of CMSs I strongly think an open-source baseline is the way to go. The reasons are many: from practical ones like solving bugs directly without the need to wait for the vendor to solve it, to faster innovation boosted by the community.

是的,对于该门户网站的读者来说无疑是显而易见的,但仍然值得强调。 仍然有许多内容是由代理商或内部开发的软件来管理的,或多或少是封闭的。 作为在CMS之上构建解决方案的专业人员,我坚信开放源码基准是必经之路。 原因有很多:从实际的原因(例如直接解决错误而不需要等待供应商解决问题)到社区推动的更快创新。

eZ Publish was open-sourced before 2000. It did not conquer the world in these 15 years but it certainly left a strong footprint. It is now being refactored completely for the second time. It uses other state of the art open-source solutions like Symfony, and it contributes back, too. You might think that open-source is only important for developers, but its very important for business decisions as well. We decided not to build our own CMS 10 years ago and chose an open-source one. One of our important selling points is that the client will not be vendor locked if he uses an open-source product backed by an active community. Clients are becoming aware of this more and more, some only after really bad experiences with closed source solutions.

eZ Publish在2000年之前是开源的。在这15年中,eZ Publish并没有征服世界,但它无疑留下了强大的足迹。 现在第二次完全重构它。 它使用了其他最新的开源解决方案,例如Symfony,并且也做出了贡献。 您可能会认为开源仅对开发人员很重要,但对业务决策也很重要。 10年前,我们决定不构建自己的CMS,并选择了开源的CMS。 我们的重要卖点之一是,如果客户使用由活跃社区支持的开源产品,则该客户不会受到供应商的锁定。 客户越来越多地意识到这一点,其中的一些原因仅是源于封闭源解决方案的糟糕经验。

2.是企业 (2. It’s enterprise)

Although this might sound as a business topic, it is also in a way connected to development. The enterprise tag means that a client is able to get reliable support from a vendor. It also means that the roadmap should be more “committed”. It doesn’t mean it will be executed exactly as it is laid out, but with an enterprise tag you should expect the project to be backed by a company which can better budget and plan future releases. With the enterprise tag you would also expect a clear upgrade path provided by the vendor for every new version. Those traits are usually interesting for more complex projects, for clients that would rather pay the fee upfront to better control the risk and to better plan ahead. It’s basically a risk management decision whether to go enterprise or not.

尽管这听起来像是一个商业主题,但它也与开发息息相关。 企业标签意味着客户可以从供应商那里获得可靠的支持。 这也意味着路线图应该更加“坚定”。 这并不意味着它将完全按照其布局执行,但是使用企业标签时,您应该期望该项目得到一家公司的支持,该公司可以更好地预算并计划未来的发行。 使用企业标签,您还将期望供应商为每个新版本提供明确的升级路径。 对于更复杂的项目,对于那些宁愿预先支付费用以更好地控制风险并更好地进行预先计划的客户而言,这些特征通常很有趣。 是否进入企业基本上是风险管理的决定。

eZ systems, the company behind eZ Publish, were following the more obvious open-source business model at first: work on projects and have the core open-sourced. Five years ago they started to shift and today their model is different. They work on the core and sell subscriptions for the enterprise edition (there is also a free to use community edition under GPLv2). They don’t work on projects any more, all implementations of enterprise instances are done by the partner network or in-house by the client. It might seem like a simple thing but not so many vendors are using such a model successfully. The idea is to maintain the open-source spirit and focus on a higher level market with the enterprise edition, but it’s hard to find a good balance. From a developer’s perspective, enterprise open-source offers liberty in combination with security.

eZ Publish背后的公司eZ system最初遵循的是更为明显的开源业务模型:致力于项目并拥有核心的开源资源。 五年前,他们开始转变,如今,他们的模式有所不同。 他们在核心版本上工作,并出售企业版的订阅(在GPLv2下,还有一个免费使用的社区版)。 他们不再在项目上工作,企业实例的所有实现都由合作伙伴网络完成或由客户内部完成。 这似乎很简单,但是没有多少供应商成功使用这种模型。 这样做的目的是保持开源精神,并通过企业版专注于更高层次的市场,但是很难找到一个好的平衡点。 从开发人员的角度来看,企业开源提供了结合了安全性的自由。

3.具有出色的架构 (3. Has a great architecture)

10 years ago we started with the version of eZ which was based on what’s now called the legacy stack. Although the learning curve was steep at the beginning, when we got the big picture, it was like a pick-up truck – you could really do a lot of stuff with it. It was really good PHP software, but a bit ahead of its time. Things like the meta content model, separation of content and presentation and 25+ kernel extension points were excellent features but maybe not very needed 10 years ago. Back then, other CMSs just stored HTML files and got away with it. Today, when content needs to be very flexible and adaptable to different channels, those features are necessary. Even more stuff is needed, like APIs, REST, scalability for big data, etc.

10年前,我们从eZ版本开始,该版本基于现在称为传统堆栈的版本。 尽管一开始的学习曲线很陡峭,但是当我们了解了大局之后,它就像是一辆皮卡车–您真的可以用它做很多事情。 它确实是很好PHP软件,但是比它的时代要早一些。 诸如元内容模型,内容与表示的分离以及25个以上的内核扩展点之类的东西是出色的功能,但十年前可能并不需要。 那时,其他CMS只是存储HTML文件而已。 如今,当内容需要非常灵活且可适应不同渠道时,这些功能是必需的。 还需要更多东西,例如API,REST,大数据的可伸缩性等。

eZ Systems recognized this several years back and decided to refactor the CMS from scratch while maintaining all the good things: the meta content model, separation of content and presentation, extensibility, etc. This is still a process as the stable and standalone new stack of eZ is expected next year. The new stack is architectured with the following things in mind:

eZ Systems几年前就意识到了这一点,并决定从头开始重构CMS,同时保留所有优点:元内容模型,内容与表示的分离,可扩展性等。这仍然是一个稳定且独立的新堆栈,预计将于明年推出eZ。 在构建新堆栈时,请牢记以下几点:

  • maintain the easy extendable content model for channel agnostic content

    维护通道不可知内容的简单可扩展内容模型

  • provide APIs on several levels for easier development, integration, extensibility and upgrading

    提供多个级别的API,以简化开发,集成,可扩展性和升级

  • “do not reinvent the wheel”, use existing best-of-breed tools

    “不要重新发明轮子”,使用现有的最佳工具

  • focus on content management

    专注于内容管理

  • use newer PHP (5.3+) features to simplify the code (like closures, etc)

    使用更新PHP(5.3+)功能来简化代码(例如闭包等)

  • make the storage type replaceable to the point that different storage engines could be used

    使存储类型可替换,以至于可以使用不同的存储引擎

  • be fully backwards compatible while having both stacks (new and legacy) in the distribution to ease the transition period for existing projects

    完全向后兼容,同时在发行版中同时包含两个堆栈(新堆栈和旧堆栈),以简化现有项目的过渡期

eZ Publish 5 Hybrid Architectue

Check the eZ Publish 5 hybrid architecture diagram (provided by eZ Systems) for better understanding of the current situation.

查看eZ Publish 5混合体系结构图(由eZ Systems提供),以更好地了解当前情况。

4.具有面向未来的内容模型 (4. Has a future-proof content model)

The current content model was introduced in 2003. As I already mentioned, it was ahead of its time but today we can really use its full potential. Today, content needs to be broken up into smaller pieces to manage it easily, and to easily integrate and distribute it over more channels. With eZ, changing the default content type set or extending it to fit your needs is a breeze. Usually, it’s a matter of a few clicks in the admin interface, and this operation will not change the database model which will ensure a straightforward upgrade procedure.

当前的内容模型是在2003年引入的。正如我已经提到的,它已经超前了,但是今天我们可以真正发挥其全部潜力。 如今,需要将内容分解为较小的部分,以轻松地对其进行管理,并轻松地将其集成和分发到更多渠道。 使用eZ,轻松更改默认内容类型集或对其进行扩展以适应您的需求。 通常,只需在管理界面中单击几下即可,此操作不会更改数据库模型,这将确保简单的升级过程。

5.将内容与演示分开 (5. Separates content from presentation)

Again, this was introduced 11 years ago. Rich content is not stored in the repository as HTML. It is stored as a simplified XML version. It has some standard HTML tags like <b> or <h1> but also some custom ones like <embed> for inserting other eZ content. On one hand, it sounds like a limiting option, but is excellent if you have more distribution channels, not just the web. It’s also resilient to HTML standard changes etc. Presentation was implemented via the eZ templating engine (which looked very similar to Smarty), but with the new version, it’s rendered via Twig (Symfony templating engine) or directly from controllers as JSON or XML. E.g. implementing dumping of rich content in Markdown should be really straightforward.

同样,这是11年前引入的。 丰富内容不会以HTML格式存储在资源库中。 它存储为简化的XML版本。 它具有一些标准HTML标记(例如<b><h1> ,还有一些自定义标记(例如<embed>用于插入其他eZ内容。 一方面,这听起来像是一个限制选择,但如果您拥有更多的发行渠道,而不仅仅是网络,那将是极好的选择。 它也可以抵抗HTML标准更改等。演示是通过eZ模板引擎(与Smarty非常相似)实现的,但是在新版本中,它是通过Twig(Symfony模板引擎)或直接从控制器以JSON或XML呈现的。 例如,在Markdown中实现丰富内容的转储应该非常简单。

6.有几个API (6. Has several APIs)

When developing some feature or extension on top of the eZ legacy stack you would usually use 25+ extension points and/or call some mid level functions from the kernel. If no other option was available you could also read/write directly to the db or even hack the kernel. With the new stack this practice changed a lot.

在eZ传统堆栈上开发某些功能或扩展时,通常会使用25个以上的扩展点和/或从内核调用一些中级函数。 如果没有其他选项可用,您还可以直接读/写数据库,甚至破解内核。 有了新的堆栈,这种做法发生了很大变化。

  • First of all there is a well defined public API for managing content. So if you need to get a piece of content there is only one way to do it. Check some examples in this detailed post on our blog if you want to learn more about this.

    首先,有一个定义明确的公共API用于管理内容。 因此,如果您需要获得一份内容,只有一种方法可以做到。 如果您想了解更多有关此示例的信息,请查看我们博客上此详细文章中的一些示例。

  • There is a REST API which directly maps the Public API. This one comes hand to hand with the REST client in PHP and Javascript. So integrating across repositories and building rich client web applications should be possible. eZ Systems is currently building its new editorial interface on top of this.

    有一个REST API可直接映射Public API。 这与PHP和Javascript中的REST客户端密切相关。 因此,应该可以跨存储库进行集成并构建富客户端Web应用程序。 eZ Systems目前正在此基础上构建其新的编辑界面。

  • Last but not least, there is a persistence API. The storage layer is in the new kernel implemented with the generic part and the legacy SQL specific part is separated. They communicate via the persistence API. This was done like that to have the possibility of using a different storage engine like, for example, MongoDB. Previously, there was no chance for this as SQL code was scattered on many code levels. There is still no NOSQL storage engine developed (there are some more important features to implement at this moment), but the base is set.

    最后但并非最不重要的一点是,有一个持久性API。 存储层位于使用通用部分实现的新内核中,并且将旧有SQL特定部分分开。 它们通过持久性API进行通信。 这样做是为了有可能使用不同的存储引擎,例如MongoDB。 以前,这是不可能的,因为SQL代码散布在许多代码级别上。 仍然没有开发NOSQL存储引擎(目前有一些更重要的功能要实现),但是已经确定了基础。

7.这是Symfony (7. It’s Symfony)

If the legacy eZ could be called an obscure and too specific piece of code, then the new stack is the opposite. The “don’t reinvent the wheel” approach really kicked some butt in the case of building the new eZ. They didn’t just use a few components, they went the full Symfony stack approach. This means that all Symfony components are there or just a “php composer update” away, and this gives a myriad of options to developers. Even more, it brings us to the situation were present Symfony developers could learn the new eZ faster than the eZ legacy developers.

如果可以将旧版eZ称为晦涩且过于具体的代码段,则新堆栈则相反。 在构建新的eZ的情况下,“不要重新发明轮子”的方法确实起到了一定作用。 他们不仅使用了一些组件,还采用了完整的Symfony堆栈方法。 这意味着所有Symfony组件都已存在,或者只是“ php composer更新”而已,这为开发人员提供了众多选择。 更重要的是,这使我们想到了Symfony开发人员现在可以比eZ旧版开发人员更快地学习新的eZ。

8.高度可扩展 (8. It’s highly extensible)

I already mentioned that the legacy kernel had 25+ extension points. There are some documented extension points also in the new stack. For example, if you need a custom field type, there is a cookbook on how to make your own.

我已经提到过,旧版内核具有25个以上的扩展点。 新堆栈中也有一些文档记录的扩展点。 例如,如果您需要自定义字段类型,则有一个有关如何制作自己的的食谱

But this is just the tip of the iceberg. The whole new kernel is built using the Symfony service container and implemented as numerous services. This enables enormous extensibility. If, for some reason, the usual extension points are not enough, you can inherit a class from the kernel, add your code, call the parent where needed and configure the service so the system uses your class. This was not possible in the legacy code and as far as I know not many other CMS products give this kind of flexibility.

但这只是冰山一角。 整个新内核是使用Symfony服务容器构建的,并实现为众多服务。 这实现了极大的可扩展性。 如果由于某种原因,通常的扩展点还不够,则可以从内核继承一个类,添加代码,在需要的地方调用父级,然后配置服务,以便系统使用您的类。 在旧版代码中这是不可能的,据我所知,没有其他许多CMS产品提供这种灵活性。

9.以其可升级性而闻名 (9. Known for its upgradeability)

A decade ago when we were starting our web development business, sites were usually redesigned and reimplemented once every few years. For bigger sites, that meant pain when switching to new code, new CMS, new hosting, etc. In a few years the old site would end up in a stage where there was no option to advance it. Hacking and extending the CMS made it impossible to upgrade.

十年前,当我们开始进行Web开发业务时,通常每隔几年就对网站进行重新设计和重新实现。 对于较大的站点,这意味着切换到新代码,新CMS,新托管等时会感到痛苦。几年后,旧站点将最终陷入无法推进的阶段。 入侵和扩展CMS使其无法升级。

Today, the web life is much faster. Feature changes on the site are needed almost every day. This means that web development agencies need to be agile and always moving forward. This is possible if they have a solid core that can be upgraded without breaking extensions and integrations, and is where eZ is really strong. We at Netgen have installations that were built in 2005, were upgraded several times over the years and are currently running a version from the beginning of 2014. The upgrades are sometimes not completely simple, there are some bigger gaps between versions, but it’s usually just a matter of executing a few PHP and SQL scripts. Upgrading from legacy to the new stack (once there will be no legacy code bundled) will probably be hard as the whole architecture changes but possible, I have no doubt about that.

如今,网络生活变得更快。 几乎每天都需要在网站上进行功能更改。 这意味着Web开发机构需要保持敏捷并始终向前发展。 如果他们拥有可以在不破坏扩展和集成的情况下进行升级的坚实核心,并且eZ真正强大,那么这是可能的。 Netgen的安装程序建于2005年,多年来进行了几次升级,目前从2014年初开始运行一个版本。升级有时并不完全简单,版本之间存在较大差距,但通常只是执行一些PHP和SQL脚本的问题。 随着整个体系结构的变化,从旧版升级到新堆栈(一旦不再捆绑旧版代码)可能会很困难,但是有可能,我对此毫无疑问。

结论 (Conclusion)

If you are searching for an enterprise open-source content management system built around the best-of-its-breed PHP framework, highly extensible, upgradeable and easy to integrate – search no more. eZ is the choice for you. Start getting into it and by the time you figure it out, there will be a version with no legacy luggage :)

如果您要搜索基于同类最佳PHP框架构建的企业开源内容管理系统,该框架具有高度可扩展性,可升级性和易于集成性-无需再搜索。 eZ是您的选择。 开始学习它,等到您弄清楚它的时候,就会有一个没有遗留行李的版本:)

In case you are not yet convinced check a recent comparison between eZ Publish and Drupal by a fellow eZ community member Joe Kepley. Should be a very interesting read for Drupal developers :)

如果您尚未确信,请检查eZ社区成员Joe Kepley 对eZ Publish和Drupal的最新比较 。 对于Drupal开发人员来说应该是非常有趣的一本书:)

In case you are eager to learn more you still have a chance to register for the PHP Summer Camp / eZ Publish Summer Camp. It’s a double event that we are organizing at the beginning of September in Croatia.

如果您想了解更多信息,您仍然有机会注册PHP夏令营 / eZ Publish夏令营 。 这是我们在9月初在克罗地亚举办的双重活动。

Or just try it out. The latest community edition can be found here and installation information here.

或者只是尝试一下。 最新的社区版可以发现这里和安装信息在这里

Feel free to share your feedback in the comments.

随时在评论中分享您的反馈。

翻译自: https://www.sitepoint.com/9-reasons-consider-ez-publish-cms-next-web-project/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值