Symphony.

I think once 2.3x is fairly stable, as hopefully it will be in 2.33, it would be a perfect time to move on to something solid with more benefits under the hood, as long as there is still at least someone available to fix/provide insight to any show stopping bugs that might be uncovered for the 2.3x branch (and possibly provide bugfix releases).

Personally I am happy with where the core feature set is right now - with maybe the only exception being a lack of solid entry relations management (sometimes SBL is just too simple). However, the extension ecosystem has most of what I need to get by, and there's nothing stopping extension developers from improving 2.3x until a framework-based core is ready.

Having said that, I think an extension migration tool or at least and extensive guide would also be essential to coincide with a new core. There are a lot of excellent tools for Symphony out there, that hopefully won't be abandoned.

Oh yeah and as regards the templating layer debate, I stand firmly on the side of XSLT. It may be the barrier to entry for Symphony, but it is absolutely Symphony's most U of SPs for me.

I can't re-iterate this enough, it will lose us our focus. We are the XML and XSLT CMS…

I am on your side!

I cannot believe that this is even being considered to be honest, if you (the general you) don't like xslt that much, then why the hell are you using Symphony?

1++

@Kaiuwe, @designermonkey: Interesting. I can see that point of view, too. I guess this is one of those questions which gets right to the heart of what Symphony is/"should be" trying to do/enable.

I still can't help thinking it might be worth considering taking a modular, agnostic approach to views, with XSLT being the only module that is taken responsibility for by the core devs to maintain focus. But as I say, I'm happy using XSLT myself. I do feel very slightly dirty typing out Blade stuff!

But as I say, I'm happy using XSLT myself. I do feel very slightly dirty typing out Blade stuff!

Indeed. I love XSLT. It's all I know templating wise.

I still can't help thinking it might be worth considering taking a modular, agnostic approach to views, with XSLT being the only module that is taken responsibility for by the core devs to maintain focus.

A modular, agnostic approach is the smart choice. And I too believe that an XSLT bundle/module should be considered as core development. Could this also not be a feature? The fact that any templating system could be used?

Some thoughts on @brendo's questions.

If we were to focus on Laravel now, what would happen in the community? Happy? Sad? Frustrated? Abandon the product?

It appears the majority would be happy. I do not believe the next public release of Symphony (2.3.3) should not abandon security fixes, and overall community support until a Symphony 3 could take its place.

Would people be happy knowing that Symphony 2.3.3 is likely to be the last release in a while? That no new features would be added and support is limited while the team focuses elsewhere?

I don't see why 2.3 should not be the last major point release. Websites built with 2.3 today will work in 2.3 tomorrow.

Who would work on the new build?

I think that and identifying what makes Symphony, Symphony is the next topic of discussion.

Who would support the current release? How long would we do that for?

I believe security fixes for 2.3 should be supported indefinitely.

What does it mean for Allen, and Soario?

I have reached out to him.

Would anyone build a migration tool? Not just for sites, but we have hundreds of extensions in the community

I'm not sure if it's possible to build a migration tool for extensions. However, giving extension developers more powerful tools to work with is probably motivation enough. It is for me.

Who would write documentation? Right now our documentation is the single biggest thing Symphony fails at. It is way too hard for a new user to pick up Symphony and start developing with it. I have seen this with my own eyes, and I've heard it from you while traveling. Moving to Laravel doesn't change this

I'm more motivated to work on documentation for a forward thinking Symphony than I am for the current Symphony.

As a personal frustration in the docs, I asked Allen for a site login the other day to pull out the existing content, still waiting for this.

In the mean time, I have outlined the structure of the documentation-to-be, focussing on the admin and interaction before any developer level stuff.

If anyone is interested in helping, please contact me asap about this. The last time we called for help was two years ago, and then those in charge left the community (for good enough reasons, not in a bad way).

The admin docs wouldn't change much whatever the core was, so we need to move on this now.

We. Should. Not. Question. XSLT.
This is a core feauture of Symphony and a great tool for web designers that needs to be promoted. It's something we should use proudly.

I see the advantages of using a framework, and I see that some of you really like Laravel. And I won't say that it's no fun to work with Laravel — I just don't know this. But at first sight, when I visit the Laravel website, there are some things that frighten me:

• The community forums are an ugly mess.
• Taylor Otwell, the master himself, has created an email bundle based on the Swiftmailer library. Has this library been re-animated at last? I don't think so. So he has built on something that is bloated, old, more or less unsupported code. Why the hell did he do that?
• They still advertise a conference that has taken place in February.

It has been said that we should first think about the if before we discuss which library to use. But theoretically, we might not find a single one that is really cool. So probably we can not separate those two questions.

We. Should. Not. Question. XSLT. This is a core feauture of Symphony and a great tool for web designers that needs to be promoted. It's something we should use proudly.

Yes. Yes!

Has this library been re-animated at last? I don't think so.

Swiftwailer was last updated 3 days ago. Fabien Potencier is one of the contributer, in fact SensioLabs is the maintainer.

Why the hell did he do that?

Maybe because of this.

On the other hand. It's just a bundle, you can just plug in a different Mail service if you want to.

We. Should. Not. Question. XSLT.

I'm sorry, but I disagree. I think it's actually a factor that's holding progress back at the moment.

True everyone is.

Time for changings. Time for new base. New vibes. Phoenix CMS. Rise from the flames, up to sky, take up hopes and dreams.

Let's go!

I think that the idea of building a new Symphony on top of a framework (be it Laravel, Symfony, CodeIgniter, etc.) sounds very cool.

In my opinion the strength of Symphony doesn't only spring from the adoption of standards like XML/XSLT but also originates from its sleek UI and its core concepts. Sections have entries that are fetched by datasources and shown on pages. It's that simple. That's why I started using Symphony. Because it looks familiar, and it did look familiar since the very first time I used it.

Of course, nowadays there are other products providing the same features. However, I still believe that Symphony either names these concepts better or makes them more intuitive. It embodies the KISS principle in a unique and hard-to-imitate way.

Clearly, I'm not saying that it is perfect. We're now paying the price for a decision made a few years ago, when the Working Groups were asked to choose between the so called "Symphony 3 Demo" and Symphony 2.

At that time my vote went to improving Symphony 2, because I was eager to give my contribute. Now, like @brendo, I realize it was a mistake. The codebase has proved old in terms of both functionalities and architecture. Making a change to it these days means almost certainly breaking something.

Another issue with Symphony is that since when Alistair abandoned it, Symphony has lost its stability. If I were asked to explain my statement with a picture, I would draw a straight line vs a broken line. The evolution of Symphony is now a broken line. There's no clear direction, no bias, no vision. Yes, we're releasing new versions at a remarkable rhythm and I think some of the new features are exciting, but is it enough to say that we know what Symphony is supposed to be in a year or two?

Of course I partially ascribe that to the choice of sticking with Symphony 2.

The rest is, in my opinion, due to the fact that apart from @brendo no one else is officially entitled to be the main developer of the platform. Ideally, we should have some two or three core developers that set the pace, take care of the vision, review pull requests and agree upon a few coding/design guidelines for the platform (I have seen some issues on GitHub addressing this last problem, which is great.)

When I learnt about Soario I felt somehow reassured because, I thought, maybe an agency is what Symphony needs to regain the stability it needs. To let it go on a straight line.

Therefore, before we can start thinking about the future of Symphony, we should at least know exactly which are the available resources in terms of time, people and commitment. Can we afford writing Symphony from scratch on top of another framework, given the amount of resources we have now? Yes, no, maybe. I don't know.

Please don't get me wrong, I love Symphony and I hope for its best (and I also hope to be wrong about what I've previously said on the lack of resources and stability.)

Clearly I don't want to use Symphony 2 for the rest of my life and would really love to attend the birth of a "Symphony 3" baby. But I also fear that, with the developers that are officially involved right now and the time they have at their disposal, jumping on the Symphony 3 wagon is something we are not ready to do.

Apologies for the long post and thanks to Lewis for bringing up this discussion!

In my opinion the strength of Symphony doesn't only spring from the adoption of standards like XML/XSLT but also originates from its sleek UI and its core concepts. Sections have entries that are fetched by datasources and shown on pages. It's that simple. That's why I started using Symphony. Because it looks familiar, and it did look familiar since the very first time I used it.

I believe this is true, at least for me. And agree with the XSLT as the main/default/master template system.

Therefore, before we can start thinking about the future of Symphony, we should at least know exactly which are the available resources in terms of time, people and commitment.

Well said. @designermonkey brought this questions too.

@iwyg: Sorry, I don't get your point. On the one hand, you say that Swiftmailer has not been significantly updated for 3 years now and it's still Fabien Potencier who is responsible for it (who has very little time, actually). On the other hand you say that it has been a good decision to use it? Sorry, I don't agree. Getting rid of Swiftmailer, which is a "bloated monster" in my eyes (much bigger than Symphony!), was one of the main reasons for me to drop the old Email Newsletters extension and contribute to @creativedutchmen's development of the Email Newsletter Manager (plus the Core Email API and the Email Template Manager).

On the other hand. It's just a bundle, you can just plug in a different Mail service if you want to.

I know that. My question was different: Why the hell did he build upon this framework at all?

days, 3 days

I know that. My question was different: Why the hell did he build upon this framework at all?

That's beyond my mindreading capabilities :)

days, 3 days

Ah, oooops, sorry. :-)

Anyway my experience with Swiftmailer is somehow like "I wouldn't like to use it again". At the time when I used it, bugs were never fixed, and today the codebase is rather old, and it's bloated.

But this is just one of the things that made me feel uncomfortable. The Lavarel forums are much worse. :-(

The Lavarel forums are much worse.

Currently undergoing a spam issue. Not built on Laravel.

Spam or no spam, I would never visit these forums. Compared to our Symphony forum it's rather chaotic and very ugly.

And why is it not built on Laravel? Even Symphony (the system that should drop all its code, people say) runs a forum based on Symphony!