Symphony.

Funny how the author of that ‘choosing-cms-tips’ article says “it must have WYSIWYG editor.

No offense Mr_Smith, but as a designer and not a programmer that is one thing that I require for a CMS, and one thing that I feel like is lacking a bit in Symphony, the WYSIWYG editor. It’s really friggin’ hard to explain to a client how to add an image in there right now. A CMS needs to be client-friendly, and not just programmer friendly. I feel like Symphony does this pretty well right now, but there are some things that could be improved.

With regards to the WYSIWYG editor, the tools are half there, they just need to be plugged together. There are several WYSIWYG extensions (TinyMCE, markItUp etc.) and the Mediathek supports drag/drop of images into textarea fields. I think Symphony itself definitely should not* support this out of the box — it provides the framework, and it’s up to the development community to come up with an ingenious way to solve the problem.

I should probably add that if there are specific workflow or functionality requests like this, the best option is to create a new thread with a tag in the subject line such as [Suggestion] or [Workflow] or whatever best describes the post, and initiate discussion. Specifically for adding images to a textarea, if we define the workflow that we want to achieve we can probably come up with a decent solution :-)

I’ve mentioned this a couple of times, but I tend to break CMS’s down into three steps. First and foremost you need to understand if it is a CMS or a CMF. That is to say, a Content Management System and a Content Management Framework differ slightly in what they do for you.

So, we’ve established long ago that Symphony is definitely a CMS. So I would evaluate it against those three words.

Content

How is the content managed? Most CMS’s are page based, as opposed to item based. Symphony for its benefit, is item based, meaning that the content is treated like an item and can therefore be reused and re purposed as required. Page based CMS’s suffer a limitation on this front as the content has been tied to the page. They often require hacking/reverse engineering the core system in order to do relatively simple things. Think Wordpress.

Management

How easy is it to manage the system itself, the content and its users. Add to this managing your workflow and you’ve got a lot to ponder. Admittedly, Symphony has been weak in the past when it comes to managing users. However it excels when it comes to workflow and managing the system itself.

System

I’m not a backend developer, however one of the core things I understand about CMS’s is that it should provide enough hooks, a decent api and flexible backend for you to extend and build upon, as opposed to feeling like you’re hacking it or having to discover for yourself.

Recently, the community has been lively, in no short part due to the sterling effort put in by the Symphony team in order to push out the recent releases. In turn lot’s more extensions are being made, and it’s only a matter of time before enough traction builds up to really solidify Symphony as a solid contender.

The only thing I see as obstacles are getting new users used to the fundamentals and philosophies that underpin Symphony. Also moving away from proprietary languages and pure php into an open often misunderstood format like XSLT. Having said that both of the above just require a bit more documentation and some more hands on examples.

I’m certainly sticking here as we ride this wave!

Be interesting to see what elements are included with Expression Engine’s basic package, and see how many them are in with the Symphony package.

Symphony can do pretty much all that the “free” EE does out of the box. But it ain’t quite there yet, Symphony 2 is very young and has a lot of potential in my eyes.

I know there are developers developing extensions etc…. I don’t know, but is it easier to create extensions, then bake them into the core code?

Why would one like to bake everything into the core? In my world that’s just plain stupid since once you start going down that road you end up with a system that could make you dinner and serve you breakfast.

Once this site gets some nice Ensambles those will make an easy way of starting with Symphony. I’m talking about complete and finished packages to download, not download a separate installation, separate Ensamble workspace and the needed Extensions but everything in one package. Beacause once you’re hooked on Symphony there’s no turning back…

everything in one package

For development, it’s easier to have each of the pieces separate. For the end user, it certainly would be better to have a single package. I’m not quite there with the ensembles I’m working on, but there’s no reason that I couldn’t provide ensembles as complete packages, except for the little extra time, and possibly another repository, to provide both a developer module and an end-user package.

@Pertoyra, I see where your coming from, but I don’t think it’s stupid to have essential extensions baked in. Perhaps there could be different types/flavours of Symphony we can download, such as what we get from Ensembles, I certainly feel that is why it was developed to do.

I can imagine a stage where I have a client who runs a restaurant and he needs a restaurant type site. It has booking system, dynamic menus which he can change. Photo gallery, contact from etc….Well if there is an Ensemble there already that either Stephen has done, or me or anyone then great - you just install it and style it accordingly. The functionality is already there and your saving yourself a whole heap of hassle reinventing the wheel.

Your client gets a quickturnover, and he’s happy.

Can Joomla do that?

Perhaps there could be different types/flavours of Symphony we can download…

Thats exactly the point of extensions. One minimal, secure and easy to maintain core and then you cherry-pick what additional functionality/flavor you want.

Especially when the Extensions integrate so nicely into the system as they do in Symphony. The end user won’t notice the difference.

Baking flavors increases maintenance work, needs somebody to decide on what to include and you end up confusing the user: “Oh, there is one with a user manager and one with Google Maps… but I can’t have both?”

@bauhaus:

For development, it’s easier to have each of the pieces separate. For the end user, it certainly would be better to have a single package.

I agree, what I’m talking about is an easy way to test drive Symphony created for a certain purpose. May it be a blog, or life stream, or data aggregator/storage, or forum or anything else.

Once you get the first fix…

Well the possibilities are endless. I’m not religious in any shape or form, but one genre of website that catches my eye is the Church websites - so I was thinking perhaps I could target local churches and give them a product that they would be happy with. If I have a test ensemble that they could see, even have a play around in the Author areas, and if they like what they see - they can have one and I just roll one off the production line.

Same can be done for School sites, Restaurants like I said, Sports clubs. These type of things can be charged out at a lower rate because time-wise you are not spending the same amount of time as if you were creating it from scratch. Add in the 960 framework and your not looking at much development time at all.

Or you can charge out at a normal rate, but because your time is halved, you can double your business.

In theory anyway.

can be done for School sites, Restaurants like I said, Sports clubs

To me an Ensemble shouldn’t be a “website in a box”. I think there should be ensembles broken down with discrete pieces of functionality, but not necessarily aimed at one particular “genre” of site. A School site might need a Timetable, but a Sports Club need a Calendar. These are pretty much the same thing, so I think there should be a “Calendar Ensemble” which demonstrates date-linked sections and XSLT to generate a calendar view.

Baking flavors increases maintenance work, needs somebody to decide on what to include and you end up confusing the user: “Oh, there is one with a user manager and one with Google Maps… but I can’t have both?”

Phoque puts it well — combining functionality within an Ensemble and it begins the muddy the water.

I think an ensemble should be as the others suggest — a forum, a blog, a calendar, a lifestream, a members management system, a shopping cart — discrete chunks of functionality from which learnings can be made and code lifted.

If it’s all done for you, where’s the fun? :-P

But it raises a good question in terms of your original post regarding marketing and exposure. Do we need Ensembles to market and expand Symphony’s capabilities? Could newcomers think Ensembles are all Symphony can do, and not see its real power? Is the concept of an ensemble difficult to grasp?

I know when I first saw bauhouse’s ensembles for v2.0r5 I was very confused. Because they used the Symphony UI styling it took me a long time to figure out where the XSLT stopped and Symphony began. As an integration piece it was flawless, but for a developer I had a difficult time piecing it apart.

Should there be naming conventions and a fairly unified stylesheet for producing ensembles? It might flatten the learning curve.

what I’m talking about is an easy way to test drive Symphony created for a certain purpose

Yes, as I understand it this is the basic idea behind Ensembles (though they’re in fact more flexible than that).

@nickdunn Yeah I love the idea of ensembles being more modular, but that’s a limited proposition as long as they can’t be easily combined or layered… isn’t it?

Yeah I love the idea of ensembles being more modular, but that’s a limited proposition as long as they can’t be easily combined or layered… isn’t it?

Yes indeed. A technical challenge. Naming conventions such as prefixing section names with the name of the Ensemble, and making pages children of a named parent page, would make things less likely to clash.

(It took me a while to write this, and since, others have chimed in. Hopefully this makes sense…)

@NickToye, what you’re looking for doesn’t require the extensions to be part of the core. The required extensions just need to be baked into the ensemble. Same end result. Symphony shines because it is extensible, with no assumptions made about the site you want to build.

Developer workflow/usability enhancements have some merit as extensions that should be added to the core, such as carsten’s Collapse Section Fields extension. It’s a huge usability improvement in being able to sort section fields.

But it’s definitely not a good idea to undo the work the dev team has done to pare the core to the absolute minimum. Abstraction and extensibility give Symphony its power and flexibility.

A core set of ensembles is what is needed now. My own pet project is to develop a design business administration system:

• Clients
• Projects
• Tickets
• Tasks
• Calendar
• Reports
• Proposals
• Messages
• Sites
• Brands

Obviously, this is going to take some time, but that’s the long-term goal.

I’m hoping that some effort will also be put into how best to aggregate sections from different Symphony ensembles. With the latest updates to the installer, I would imagine it would now be easier to create an extension that changes the SQL to add sections, fields and entries tables to an existing Symphony install.

This would be a killer feature and would certainly propel Symphony forward as an extremely extensible CMS. If no one else takes this on, I’m going to have to figure out how to do it. That, to me, is the way forward.

I know when I first saw bauhouse’s ensembles for v2.0r5 I was very confused.

@nickdunn, sorry for causing confusion with my ensembles. It was a time for beta testing and seeing whether there was a way to improve the admin area when the section link seemed a little broken. Hopefully, they also demonstrated Symphony’s potential.

I’m hoping that some effort will also be put into how best to aggregate sections from different Symphony ensembles. With the latest updates to the installer, I would imagine it would now be easier to create an extension that changes the SQL to add sections, fields and entries tables to an existing Symphony install.

I’ve tried, and it’s near-impossible in its current form. But this is definitely worthy of a new thread sometime as I have some ideas to discuss.

@nickdunn, sorry for causing confusion with my ensembles

Not at all! As a newcomer I was still learning Symphony’s lingo (fields, sections, events, pages) but in hindsight it taught me a lot. The work you put in highlighted weak areas that were strengthened for the 2.0 release, so props! Beta testing is never easy.

@Nickdunn,

Well Ensembles can be what you want them to be, and depending on your position in the market. For you where you obviously work for people who win projects with big budgets - there is a different kind of pressure on you to deliver quickly and efficiently. For someone who works and runs a business - churning out websites quickly makes more business sense, then having fun.

I used to work for agencies, one of the big upcoming one’s in Manchester (going back about 4 or 5 years though), and it wasn’t really my problem to worry about whether or not the business was efficient. I had my workload and I did it, I had loads of fun because I was allowed to. When you run your own business and develop websites, the time you can save by churning them out leaves you more time to develop the business.

It’s not that much fun to be honest, but I don’t answer to anyone and I decide on how I run the business.

@nickdunn THis is getting OT and I know I’ve posted this concept elsewhere before, but since it’s apropos…

• The first step in modular ensembles is namespacing Sections. This way, not only can you avoid name clashes in the data model, but also in the xsl templates that would act on them. Since each section is associated with a URI, there is no collision. Namespaced Sections would also allow for inter-operable ensembles, so a ‘members’ ensemble would have a recognizable namespace:field that other apps/ensembles can link to through link fields, etc.

• A way to export Datasources. This is the trickiest, since it would require modeling the state (ie the param pool + page url params) in order to accommodate using them in the DS queries

• Last, a way to define a Page class or template which would use the datasources.

Of course all this would need an import/export extension, which would be no small feat. Looking into extending a Section (in order to add namespace URIs) I see that the Section ‘Create’ delegate is broken.

Looks like time to start a new thread: Modular Ensembles

Have you all noticed this? I really love nickdunn saying:

As a newcomer I was still learning Symphony’s lingo…

@Nick: This sounds so funny today, because it obviously took you just a few months to be a grand master.