Experiences with ExpressionEngine

[Leevi Graham]

Hi guys,

I'm an ExpressionEngine addon developer interested in Symfony2 and this project. I'd like to add my 2c about the good parts of EE2 into the discussion.

In my opinion channels and custom fields are the most powerful features of EE2. Channels are essentially models that have their own custom fields which in turn are used to dynamically create publish forms in the admin. This combination provides implementors an easy way to customise the CMS and developers to extend the CMS functionality. These days I'd hesitate using any CMS that has predefined content types such as a blog, events etc as I find that they are too restrictive.

My current understanding of Symfony2 makes me think that a channel / custom field implementation would fit perfectly with the form / validator components of Symfony2. Developers could create new fields that would be automatically available to new and existing channels.

Other great features:

• Multi-site manager: 
  
• Multiple sites served from the one install. 
• Site A can pull channel content from site B in the templates if required. This works well if your IA requires a "master" site. 
• Member groups are shared across the install. This is great for creating "networks" of sites. 
• Strong developer community: Not all developers are seasoned pros which can be a problem but the low barrier to entry means that there are lots of addons for the CMS.
• Commercially backed: This is both a positive and a negative. Pros: The product is always being developed because there is investment. Con: The product might not be developed fast enough and it's hard to get changes made in the core.

EE2 is still missing some components that I also consider a must-have for a great CMS. They are:

• Asset management: Wordpress seems to have a great UI for this although I'm not sure about the technical implementation
  
• Member management: From a developers point of view it's hard to extend the built in membership permission forms.
  
• Workflow: There must be good workflow and entry previews. The simplest implementation is revisions and drafts. Drafts are not pushed to the live site until they become a revision. A user should be able to preview a draft on the front end before it's published as a revision. This also applies when there's an existing published revision.

So that's my opinion. I'm happy to answer any questions about EE so fire them through!

- Leevi

On a side note, while I don't have the dev chops that some of the other guys in this group have I do have some experience with CMS UI which I'm happy to contribute to the project if it gets of the ground.

[Bastian Kuberek]

This is essentially what Apostrophe and sympal does. You can create a channel Model and use sfDoctrineSlot to have custom fields attached to them.

I too, come from EE background. I have done a whole lot in EE. But once I was introduced to symfony, I never went back. You can do all EE does with symfony. Some of the featrues are not built in, but you can easily put those together.

- Bastian

[Lukas Kahwe Smith]

On 28.01.2011, at 10:48, Leevi Graham wrote:

> In my opinion channels and custom fields are the most powerful features of EE2. Channels are essentially models that have their own custom fields which in turn are used to dynamically create publish forms in the admin. This combination provides implementors an easy way to customise the CMS and developers to extend the CMS functionality. These days I'd hesitate using any CMS that has predefined content types such as a blog, events etc as I find that they are too restrictive.

We are using JCR as out content storage API, which effectively means you can easily store arbitrarily structured content nodes. These nodes are represented as model's which map to plain old php objects. So you should be free to do what you need. That being said at the beginning our focus will be on developer driven content structuring. So the focus is less on providing tools for end users to model their data structures via a GUI, though architecturally there is nothing that prevents someone from adding this.

> My current understanding of Symfony2 makes me think that a channel / custom field implementation would fit perfectly with the form / validator components of Symfony2. Developers could create new fields that would be automatically available to new and existing channels.

Yes, the work being done towards an admin generator will ease this kind of feature quite a bit.

> Other great features:
>
> • Multi-site manager:
> • Multiple sites served from the one install.
> • Site A can pull channel content from site B in the templates if required. This works well if your IA requires a "master" site.
> • Member groups are shared across the install. This is great for creating "networks" of sites.
> • Strong developer community: Not all developers are seasoned pros which can be a problem but the low barrier to entry means that there are lots of addons for the CMS.

Again, we are not trying to make things super complex, but at the same time the main target audience are developers, not content editors with limited programming knowledge.

> • Commercially backed: This is both a positive and a negative. Pros: The product is always being developed because there is investment. Con: The product might not be developed fast enough and it's hard to get changes made in the core.

The number of companies that have approached me who want to back this is steadily increasing. That being said there will not be a single company that will be THE company behind this initiative. Essentially the community is defined by individuals and not by companies.

> EE2 is still missing some components that I also consider a must-have for a great CMS. They are:
>
> • Asset management: Wordpress seems to have a great UI for this although I'm not sure about the technical implementation

Many of us have expressed how important asset management is to them, so I expect that we will provide a sophisticated solution for this.

> • Member management: From a developers point of view it's hard to extend the built in membership permission forms.

I am still a bit fuzzy on this. JCR provides an ACL API which we plan to leverage.

> • Workflow: There must be good workflow and entry previews. The simplest implementation is revisions and drafts. Drafts are not pushed to the live site until they become a revision. A user should be able to preview a draft on the front end before it's published as a revision. This also applies when there's an existing published revision.

This is another topic that was mentioned a few times before, but its very non trivial indeed. Then again as we will focus on enabling developers we will likely forgo implementing a GUI for this initially.

> So that's my opinion. I'm happy to answer any questions about EE so fire them through!

Great, can you maybe add your POV to the wiki page on github where we compare different approaches?

> On a side note, while I don't have the dev chops that some of the other guys in this group have I do have some experience with CMS UI which I'm happy to contribute to the project if it gets of the ground.

great!

regards,
Lukas Kahwe Smith
m...@pooteeweet.org

[Leevi Graham]

Thanks for the reply. I think its cleared up my understanding of the project a bit.

Would I be right in saying the amins of the project are to create a strong CMS base that can be extended into custom CMS implementations?

[Lukas Kahwe Smith]

On 30.01.2011, at 23:28, Leevi Graham wrote:

> Thanks for the reply. I think its cleared up my understanding of the project a bit.
>
> Would I be right in saying the amins of the project are to create a strong CMS base that can be extended into custom CMS implementations?

yes .. its a toolbox for developers.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org