Symphony.

The extensions used in the Ensembles would be standardised and sanctioned by the Symphony team and developers.

I would be happy to provide help with my Multilingual extension if someone is interested in including it in an ensemble for theme developers.

Still need to resolve some remaining issues, but should be ready soon.

Thanks for clarifying, Allen. That does put the offer in a different light. And I can see how this would be a good opportunity to increase exposure for Symphony.

I've always thought it would be interesting to create a front end for Symphony that included a login area that resembled WordPress, but using front end forms in Symphony. By building a blog ensemble that matches the data model of a standard WordPress blog, it might be possible to create a standard data structure that could be used to adapt WordPress themes for use with Symphony. These could then become the starting point for additional features.

Thanks for input all, that clears up what I had thought... "Don't be and asshat" heehee

@Allen, these ensembles fall into the blog,portfolio,forum type categories that were discuss in Cologne almost. If a standardised 'Ensemble' theme was the aim, we'd definitely have more success in pushing these concepts onto Theme Forest users.

A complete install with theme is a great hook for new comers to explore the systems potential.

I agree with @bauhouse that building a blog ensemble representative of a word press blog is a good idea if exposure on themeforest is the aim.

The vast majority of users and developers on theme forest use wordpress so it would make sense to first provide a Symphony ensemble that would enable existing themeforest themes to be ported to Symphony.

The reason why I use Symphony for just about every web project is that I can create exactly the data structures and templates that I want. However, when I started it out it was definitely hard work learning everything from a blank canvas.

By providing an ensemble which gives all the functionality that a wordpress user/developer is used to then I think it makes it easier for them to experiment and experience the real benefits that symphony can offer.

Competition aside I would be more than happy to work with existing theme forest theme developers to port their designs to Symphony. As it has been mentioned, it would be most successful if a standardised base ensemble could be agreed upon.

Nice to see Symphony starting to get a bit of mainstream attention. Hopefully this will go some way to building awareness.

Envato could really do with changing its notice and details to clarify what's required as it's going to cause a lot of confusion for those new to Symphony. It's a shame they didn't run through this with someone in the know first.

It's also a shame I'm not going to be around to have a go! I've never experimented with ensembles so would have used it as an opportunity to do so.

All the best, everyone. :-)

Is there any interest in an updated version of Pompodium (Symphony 2.3, responsive + mobile)? It's something we could add to the competition.

@Nils: Pompodium is definitely one I think should be submitted. In terms of design, feature and quality, it's all top notch.

Would you be happy enough for your particular build to be considered as the basis for a standardised Ensemble (minus all the designs obviously)? That way, we've got something for other theme developers to start from.

As per @bauhouse's suggestion, we should also evaluate how it compares to a standard Wordpress build and see if any changes/additions are necessary.

I'm scheduling a time with Josh from Envato to discuss things in more detail over Skype. Let me know if you guys have any questions/clarifications you'd like me to pass over.

I've wanted to contribute Symphony ensembles to TF for a while now, but never saw a market for it. I didn't want to spend the hours putting one together that very few would purchase, because of how specific the Ensemble would have to be.

I'm with others in that I don't see how this would really work. We can make Ensembles, but how do we make them flexible and configurable enough to appeal to a wide audience? Authors in Symphony can't and shouldn't create pages, due to the XSLT need-to-know behind them.. That sort of thing. They'd appeal more to devs, which is great, but it's definitely a different idea from what people are used to getting out of TF.

That being said, I'm excited they're even asking about us. I've been working on a Wordpress (ugh) theme to sell on there for the past couple weekends. Maybe I'll throw it together in Symphony first and see how it goes. I just don't really know what to provide them with.

Either way, exciting to see some public interest where I otherwise thought would never exist.

Hi guys! Josh from Envato here. Wanted to stop in and say thanks for your support for this new event. In the past we have had great success with our Envato's most wanted events and in most cases, everyone has a great time and the lucky winners also go on to gather some nice residual income as time goes on.

Though this particular event is a bit different considering how Symphony works, I am hopeful that the inclusion of high quality Symphony items into our marketplace will be a win for you as well as anyone who can benefit form your submission.

Please let me know if there is anything I can do for you all moving forward or if you need more information.

Also, if any of you feel so inclined, any tips or help you can offer on the most wanted thread would be really helpful to our community.

Thanks, Josh

@Nils, I would definitely be interested in an updated version of Pompodium.

This kind of brings up another issue I've thought about with Ensembles being used in this way. If someone purchases and installs an Ensemble, and development continues on it, (bug fixes, new pages and/or features are built and added into the Sections associated with it, etc.), how would that person be able to upgrade to get those features, without losing any of their information.

I could be wrong, I've never tried it and only assumed, but I imagine there are no migrations set up to make that a painless process? That's going to be a really difficult thing to support and explain to any customers, right?

I was thinking about that too; there's no 100% clean way to get it done. I use CDI on a daily basis for in-house migration to production; however ensembles would work slightly different, and I'm not sure using something like CDI is ideal in these scenarios, as you'd likely have clashes on migrations due to changes done client side.

Most likely to support upgrades/updates we will need to look at a different way of storing Section/Page changes. Maybe an XML file which could take care of these migrations (At least until sections are themselves defined using xml as previously suggested)

The best approah I think is to look at Ensembles as a more "locked-down" version of Symphony. This can be done by asserting a few system rules.

Here's how I'd do it: each ensemble comes pre-installed with an extension called "Ensemble", which is responsible for asserting the below rules.

Rules

1. Assert the type of Ensemble the build is (forum, e-commerce, blog, bug tracker, etc.) This can be done by creating a definition XML file.
2. Existing sections in an ensemble cannot be removed. However new sections can be added and modified freely.
3. Fields in an existing sections cannot be changed, but new fields can be added.
4. Data sources, events, page and XSLT utilities can be modified, however, "original" copies are never removed and can be restored at any time.

The basic gist of the rule is to assert the integrity of an Ensemble structure depending on the type of Ensemble it is, but allow end-user level additions to the system to customise. With pages, data sources and events, these can be modified but if things break, there's always a button to revert the page back to its original state.

These rules would mean there shouldn't be any conflicts with the system as core ensemble fields cannot be modified by the user.

It's important to note that there are two main concepts at play here:

Ensemble type

This is the structural definition of an ensemble. A type is governed by a "Blueprint Definition" file, which lists the required sections, pages, data sources, events.

Ensemble theme

This is essentially stuff that is dropped in to the workspace folder. This includes CSS, JS and image assets as well as DS, Events and Page overrides.

We can look at offering a couple of Ensemble types to get theme authors started, a Blog type and a Community type (akin to the Symphony site, with a forum and a membership area). Most theme developers should then be able to take the Ensemble type and customise the workspace area, thus creating "themes".

For those that have used Shopify, they use a fairly typical setup that is akin to the rules mentioned above.

@Allen, whilst the rules could make sense, there's still no upgrade path for an ensemble. Though the theme (workspace folder) is in itself quite easy to update fpr themes.

There'll need to be an upgrade functionality built into the Ensemble extension. The way it can work is akin to the (original, old-school) Symphony 3's section synchronise feature. For the rest of the components, they can be stored within the extension itself.

I've done a very rough and not-so-clear explanation of the idea, but I'm happy to chat further in more detail.

This will require some development effort for the Ensemble extension though...

What about the work that was done on migrating Pages and Sections to XML?

Wouldn't that help the migration of structure at least?

Yes that would; however not sure it has an ETA on when it will be integrated.

It won't be integrated.

At least not any time soon (soon being within the next few months). There are still a lot of hurdles with it, and the project might be taking a new direction.