0 users online. Create an account or sign in to join them.Users

Search

Symphony CMS Workspace

History

The default workspace for Symphony has been the Spectrum theme since the release of Symphony 2. Little has changed in the three years since the official release of Symphony 2.0 on 7 December 2008.

There had been discussion about replacing the Spectrum theme with the Piano Sonata ensemble. However, Nick Dunn made some good points about the ensemble that meant that it might not be a good choice for the default workspace.

Default Workspace

During the Symposium in Cologne, the topic of the default workspace came up and we decided to assemble a group to work on a collection of community contributed ensembles. However, for lack of time, the project stalled. During Symphony Hackathon 2.3, I raised the topic of the default workspace to see whether there was scope to work on a new workspace for the Symphony 2.3 release.

Features

To reflect the high standards of the Symphony CMS project in regard to functionality, usability, design and code, the default workspace should meet a minimum set of requirements. Also, the purpose of the theme is to serve as a working example for those who are new to Symphony CMS. The new default theme should follow the pattern established by the Spectrum theme:

A primer to Symphony 2's default theme

Every theme in Symphony has an important mission: to introduce newcomers to Symphony by way of a working example. Spectrum, the name of this version's default theme, was designed and developed with such a mission in mind by following a set of constraints. A default theme is required to:

  1. be presented in a format that is universally identified and intuitive.
  2. have a clear and simple HTML structure.
  3. demonstrate the fundamental concepts in Symphony—sections, fields, data sources and events—and their interactions together.
  4. avoid functionality that does not have any educational value.

The design

Our first rule states that a default theme needs to be in a format that is instantly recognisable to a user. As a result, all of the themes created in Symphony's history have emphasised a weblog structure. Spectrum continues this tradition.

Cubic, the name of a previous default theme, followed the teaching mandate very closely. However, the theme took it one step further and removed complex structure and colour in favour of a simplified look and feel. The main design goal for Spectrum is to introduce more colours but still follow the philosophy of a simplistic layout.

Features

Spectrum has a handful of additional features that you won't find in previous default themes. These new features are not only meant to demonstrate the capabilities of the system but also explain some fundamental philosophies in Symphony 2. Below is a list of features:

  • Logged in users will see links to Symphony's admin to edit articles, manage comments and add notes.
  • Logged in users will see 3 protected menu items, article drafts, the debug page and a link to the Symphony admin.
  • Articles on the drafts page sport a button to publish the article.
  • Article images take advantage of Symphony's build-in image manipulation feature to crop and size the image automatically.
  • The contact form on the about page saves the content to the Messages section on the back end and emails the website's owner.

Philosophy

All of the above takes advantage of new features found in version 2. An important concept that is being advocated in Symphony is the practise of creating a tighter connection between the front end and the back end. Developers are encouraged to take advantage of the simplified URL structure of the admin to create a more convenient environment for their users.

With the introduction of the Event editor, developers now have even more control when developing a website. For example, the Publish button on the article drafts page utilises the event editor to create an interaction between the front end and the back end. This allows the Publish button to update the "Publish this article" checkbox field from the "Articles" section. This feature also compliments and encourages the philosophy of a more seamless environment between the website and the admin interface.

Community Contributed Ensembles

I wrote a forum post about Community Contributed Ensembles to outline a process for moving forward on creating some bare bones default ensembles, based on the conclusions of the group that met to discuss the issues at the Cologne Symposium.

An Article About the Export Ensemble Extension

I was surprised that people at the Symposium in Germany were completely unaware of the work I've done to try to improve the Export Ensemble extension. So to publicly announce that I have assumed ownership of the extension with Alistair's departure, I have created an article: Symphony CMS: the Export Ensemble Extension. This is not to say that I want to be solely responsible for the extension, but that I saw some holes that needed to be filled, and since no one else was picking up the work, I felt this was an area where I could contribute.

If anyone has other suggestions about how to make the extension better, please let me know, or even better, just go ahead and add your own improvements and submit a pull request on the official extension repository.

Documenting the Process for Creating Ensembles

The article is a prelude to first documenting my process for creating ensembles, as a recommendation for a standard approach to building ensembles (which differs slightly from designermonkey's A Symphony Workflow).

The Default Symphony Ensemble

Based on the decisions we made at the Symposium, I'd like to move ahead with creating an ensemble to replace the default ensemble to be included in the official Symphony download and to replace the default workspace.

Bare Bones Ensembles

Next, the plan is to build bare bones ensembles to complement the default workspace, so we will end up with the following basic ensembles:

  • Blog
  • Gallery
  • Products

Developer Ensembles

This is what I'm most excited about: the possibility of creating a library of ensembles that provide examples of more specific use cases for Symphony, providing the templates and collections of extensions that demonstrate how to craft more complex sites.

Community Contributed Ensembles

Soon after our first Symposium, GitHub added the organizations feature. I reserved the builders organization for the possibility of creating a group of Symphony designers and developers who would be able to collaborate on community contributed ensembles, which would include the redesign for the Symphony CMS site.

This organization will be distinct from the symphonists organization, which is now reserved for community curated extensions, where the original extension developer is no longer actively developing the code. The code may still deserve a place in the Symphony extension library, so the community needs to take over the responsibility of maintaining the code.

Anyone who would be interested in helping to build these ensembles, please let me know, and I can add you to the builders organization on GitHub.

Goals

Starter Kit

Perhaps we can be even more explicit about the purpose of the default workspace. If we call it a Symphony Starter Kit, the ensemble could be more of a tutorial, with links to the API, documentation and threads in the forum that answer commonly asked questions. There may be more work involved to maintain this sort of workspace.

At any rate, the ensemble should be a good starter kit for anyone who wants to learn what Symphony is all about and how to use it. So there should be examples of pages, data sources, utilities and events. It would be great to include examples of how to consume external data sources as well.

Frequently Asked Questions

It would be easier to maintain a list of common problems and frequently asked questions as part of the site documentation. It would be great if the default workspace could point directly to the resources that answer these questions.

Example Files

The default ensemble can serve as a repository for commonly used utilities. In fact, it would be great to have some of the useful templates available from the XSLT Utilities page of the Symphony CMS site as part of the default ensemble.

Design

As we consider the design of the ensemble, we need to determine how the design fits with the goals of the default theme. It would be interesting to include a means of selecting from a library of themes, but we also have to consider maintainability.

Are you new to Symphony?

Help yourself by letting us know what you would like to see in the next version. What would help you to get started with Symphony?

Feel free to add your thoughts to the Google Doc.

This is amazing Stephen, we don't have many excuses left to not go ahead :)

I really like the idea of a "starter kit" because it suits better with the philosophy of symphony. You're not installing joomla, so no one is going to use the default ensemble as a finished site. It really makes sense to have a learning resource that looks like a blog but is in fact much more oriented to those willing to learn.

Great work!

Great stuff. If the idea of these is to teach Symphony and XSLT in its simplest form, I wonder whether these bare bones examples should all use something like Twitter Bootstrap so they are consistent in both look and feel as well as their markup structure. That would allow a developer to more easily see where HTML/CSS stops, and Symphony/XSLT begins.

I'm not suggesting that look and feel is not important, but it would let you spend less time writing and fixing CSS in page templates, and more time on perfecting the Symphony implementation.

(And you never know, being linked to from the Bootstrap site might be a useful thing...)

I wonder whether these bare bones examples should all use something like Twitter Bootstrap so they are consistent in both look and feel as well as their markup structure.

That's not a bad idea at all. Especially as it makes clear that we don't offer something similar to Wordpress themes. And the styling of Bootstrap is nice and up-to-date.

Regarding teaching XSLT: I remember that I found it quite useful in the beginning to see the same layout generated using xsl:for-each on the one hand and xsl:apply-templates on the other. Maybe the templates used to build the new default ensemble could start with simpler templating on the home page, moving to more advanced stuff for the rest of the site.

Wow, Stephen!

I wonder whether these bare bones examples should all use something like Twitter Bootstrap so they are consistent in both look and feel as well as their markup structure.

Great idea!

Lovely idea. Am I correct in thinking that this is somewhat like a 'HTML5 Boilerplate' for Symphony projects?

If so: I think that would be awesome (and we could probably learn something from how the H5BP guys have developed that).

So who will be teaming up with Stephen and will it be possible to have a small version of this new default workspace up and running for Symphony 2.3 final? (I'm not sure when it will be released, the last beta is due these days but there will certainly be a RC as well.)

By the way, one thing that came into my mind when reading the initial post:

Why don't we bundle the full Symphony documentation (the one on this very website) with the default ensemble? As the default workspace can be updated continuously with the core, we could make sure that the documentation is updated regularly. Just as a thought.

Agree with Nils on the packaging of documentation - should make it easier for starters.

I'm interested in setting up a multilingual ensemble... obviously separate to this, I guess once all extensions are updated - I should be able to upgrade my current 2.2.5 Ensemble to 2.3 without any major issues.

I don't think it's a good idea. Either we'd have to update the docs on both ends (website and default ensemble), or (in case we drop the website docs) a developer would always need to install the default ensemble in order to access the docs.

My feeling is that the Symphoniversum is moving to a more decentralised approach: we now have Nick's extensions website that is far superior to what we have on this site. Why shouldn't the documentation be a page of its own as well? Just using a demo install of the system.

I like the idea of integrating Bootstrap and documentation. I'm keeping this short, as I will be in China for the next 9 days. I am back on March 20. Sorry, this is bad timing to have this ready for the 2.3 release.

But, because the workspace is a submodule, it can be the next priority after the 2.3 core release. I do want to make this a priority as soon as I'm back. The plane is boarding, so I'll chat later.

(+) Bare Bones Ensembles
(+) Bootstrap

(-) HTML5 Boilerplate (full of unnecessary crap, plus Paul Irish advocates sloppy coding)
(-) decentralized approach (I had high hopes that symphonyextensions.com would be part of the (new) main site someday)

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3, 5.4, 5.5 or 5.6
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details