Symphony.

Great example! Where are the differences to the old global function calls? ;)

Controllers in Laravel 4 are automatically dependency-injected. You don't have to use any "static calls" at all, as you can define an instance of User as a constructor dependency (btw, the global static classes are just Facades, so View::make is just a shorthand to $app['view']->make. In fact, the core application object is a IoC Container). You already can do this in Laravel 3, but it's a bit more boilerplate.

I'm encouraged by this discussion. I appreciate the thoughtful responses.

I do not have used Laravel yet, but have read somewhere that the framework have severe changes in each release.

Also reading about Chrome's change his engine from Webkit to Blink (the same for Opera), some comments about how depending on external engine make harder the browser development and evolution...

I mean, I can't tell about that, who can tell about Laravel (or anyother dependecy) tomorrow?

I do not have used Laravel yet, but have read somewhere that the framework have severe changes in each release.

The history is there, but that does not invalidate a release. Nor do I think it's a valid argument against using a framework.

depending on external engine make harder the browser development and evolution...

I disagree. If anything, dependencies speed development and evolution. I don't understand. It's not as if the framework could disappear making what you build nonfunctioning. If development of a framework ceased to exist, why can't you just continue coding on top of all that hard work?

I understand and support the idea. I just wondering if someone have in fact knowledges about Laravel's roadmap and if is a good (and the best) choice for Symphony codebase in long terms.

TL;DR Great idea, let's do it.

At the 2013 Symposium, I remember Fazal asking how I felt about Symphony, is it a framework or a CMS? My answer was I don't see Symphony as a framework, it definitely has parts of it that we try to expose (Email, Providers), but to me Symphony is the workflow, the sections methodology and the UI.

I'd briefly looked doing this separation much earlier, to another framework or even to another language like Ruby, so that it would give me/contributors more time to focus on making the tangible part of Symphony more awesome and less time fixing framework layer issues.

I feel that @salsbst sums up the situation best. Symphony was originally conceived when PHP4 was commonplace, Ruby was an idea and the concept of an app was unheard of.

Back when I started my involvement with the core, I wanted make Symphony more responsible and care about backwards compatibility. Not to extremes, but far better then the early days. Working in an agency, I saw the frustrations and politics first hand about updating a site back then. It was a risk and often meant you couldn't. Release notes were sparse, developer communication didn't exist so you really were on your own. Updating a site these days is easier, generally low risk and extension developers are notified about changes.

There was the crossroads, Symphony 2 or Symphony 3. I put my weight behind Symphony 2 and in retrospect, regret that decision. Porting the cool features of S3 and making the S2 codebase more modern is a time consuming process and history shows this. We still don't have all the S3 features, but we definitely have added a few ourselves along the way.

I often wonder what would of happened had S3 development spurred on. Immediately there would of been concern about S2, and rightfully so, the 2.2 release was the first release where the core is documented, where developers were told how they could migrate extensions and at that time, S3 would of meant throwing that work to the side. Such is the case when you have a mature product with a small development team.

But still, what if?

I see this conversation as a Symphony 3 V2, and with the benefit of hindsight and experience, I support it. I think that if Symphony is to grow substantially we need to seriously consider making this jump where we outsource the framework layer elsewhere so that we can focus on the tangible aspects that people can fall in love with.

There is so much that we want to do with Symphony, multiple database providers, caching layers, migrations, other templating engines (yes, not just XSLT), CSRF, better URL routing, unit testing, ACL, tutorials, documentation, roadmaps etc etc. Funnily enough, a lot of these challenges have already been solved in modern frameworks such as Laravel, Fuel or CI. With our small (but dedicated!) team, by the time we caught up today, we'd be behind tomorrow.

So where does this leave us? To be honest, I don't know.

@designermonkey already summarised some of the main concerns, realistically if we were to do this, we're introducing some pretty hardcore fragmentation. I'm happy and eager to learn a new framework, but my time these days is fragmented so I worry about a viable timeline. It's a similar situation to the original S3 discussion.

A heap of questions out aloud:

• If we were to focus on Laravel now, what would happen in the community? Happy? Sad? Frustrated? Abandon the product?
• 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?
• How far down the Laravel road do we have to go before we can determine if this is possible or not?
• Who would work on the new build?
• Who would support the current release? How long would we do that for?
• What does it mean for Allen, and Soario?
• What does it mean for all the agencies, freelancers and designers out there that already know Symphony, warts and all?
• Would anyone build a migration tool? Not just for sites, but we have hundreds of extensions in the community
• 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

Taylor Otwell, the creator of laravel presented a release model on this years first Laravel conference that's based on the one the symfony project has. It'll be a 6 month release cycle. Laravel 4.0 will be released in may this year, Laravel 4.1 will follow in november. So far, there no plans for laravel 5 in the near future.

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

Let's look at Symfony on 01.07.2011. v1.4 is the current release. v2.0 (complete rewrite) is launched. They're totally incompatible, no upgrade path. v1.4 was maintained until 01.11.2012. v2.0 shines brightly.

Symphony 2.x = Symfony 1.4
Symphony 3.x = Symfony 2.x

Extensions will be bundles. There is no upgrade path. There is only re-creation of Sym2.x extensions as Sym3.x bundles. It will be tough, but in the end it will be worth it.

One thing we have to consider when comparing the current situation with the one a few years back when Symphony 3 was on the horizon for the first time: that time, there wasn't a stable, field-tested release at all. Symphony 2.0.7 was a buggy piece of software and we were all waiting for a stable release we could trust in for our client work. Today, we have two stable releases: Symphony 2.2.5 and Symphony 2.3.3, with the first one approved for years. The latter one has a few issues but these are – from my experience – mostly related to extension compatibility and solvable.

Independent of what we do, Symphony is at the crossroads: we will either loose users because we cannot solve the underlying issues in the codebase and fall behind other systems (this is already happening, think of Kirby or Craft) or we will loose users for the short term because we have to make the drastic change described in this thread. In my eyes, focussing on Symphony's main attractions (UI, workflow, concept, XSL templating) will be more future-proof.

When we started using Symphony, one feature was very important for use and others that hasn't been mentioned for a while: interoperability with other content providers via XML and dynamic data sources. This was a huge feature. But nowadays, in a world of web services JSON has risen and we don't have a proper answer to that yet. This discussion could be a good chance to recollect the core features and philosophy of Symphony.

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

Designers: If the UI and concepts (Sections, Fields, Events, DSs, XSLT) are still available, designers shouldn't any difference.

Developers: Give'em performant tools to craft their things. They'll love them.

Controllers in Laravel 4 are automatically dependency-injected. You don't have to use any "static calls" at all, as you can define an instance of User as a constructor dependency

And call the static method outside the controller. It is much better! ;)

btw, the global static classes are just Facades, so View::make is just a shorthand to $app['view']->make

Do not worry, I know a facade.

If you read the documentation and also the code, then the only impression: this "framework" is for amateur. Laravel uses so much singletons and static methods, this is the same as procedural programming. Symfony 2 and Zend Framework 2 have got a much better architecture.

I get the feeling that the community is very small. Is that correct?

And if I look on the "About" page on www.laravel.com, then I find only one man with a hobby, which is calling "Laravel".

Comparing with:

• Symfony: SensioLabs
• Zend Framework: Zend Technologies

Just a stupid, non-technical comment: Symfony as a basis for Symphony CMS somehow sounds obvious :)

Laravel uses so much singletons and static methods

Actually there're almost no singletons in the Illuminate codebase, except for the facades of course.

I get the feeling that the community is very small. Is that correct?

Not sure, laravel was first released in 2011, so it's a pretty young project, but it's been supported by evato (net.tuts) since the early days which opened it up for a wider audience. I was concerned about the fast release cycles at first but turnes out this will change with the upcoming 4.0 release.

Just a stupid, non-technical comment: Symfony as a basis for Symphony CMS somehow sounds obvious :)

And it deals a lot with xml, and there's a Symfony CMF project already, so yes, maybe :)

But isn't this a bit early to argue which framework to use? The question still is weather to found on a framework or not, right?

@iwyg Thanks for the infos.

But isn't this a bit early to argue which framework to use? The question still is weather to found on a framework or not, right?

Right!

My vote: 1+ for a framework

Because:

Why reinvent the wheel? Use a solid (code)base and create the concepts of Symphony on top.

Symphony CMS could also use separate Symfony2 components, like HTTP-stuff. That would be compromise between using full framework or not using a framework at all. How that sounds?

I would love it if we built a core 'container' like Laravel that used components from Laravel, Symfony et al.

In my mind, it would still be ours then. Although I am coming round to the idea of this, I am still a little nervous to let go of the reins to another framework a little.

Also, the other templating languages scares me a little, from an agency point of view. The discussion has already started about which would we choose here. I am not moving on xslt, but my colleagues are already wanting to use a PHP based language, which in my mind goes against everything we stand for as XSLT evangelists here.

Worrying.

Well, Symphony must :) provide the XML/XSLT templating layer. Other layers should be pluggable as well (bundles). Each agency will then use what they see fit.

I find the idea and responses exciting, and very encouraging for Symphony's future. As a fairly novice developer, I'd like to be able to refer to a well-defined and documented framework/modules' API(s), and to have lots of examples/tutorials available which I think is more likely when the framework/modules are widely used. Symphony being on top of a popular, stable and well-tested codebase would only make me more likely to stick with it, learn more and contribute where I can.

It would also be awesome to not be limited to MySQL. E.g., SQLite for quick, small sites.

I don't imagine that halting new features in Symphony 2 would be a massive issue. It certainly wouldn't trouble me, at least. And for my existing/impending projects, Symphony 2 will continue to work and be extensible where necessary.

Change happens, and based mainly on others' insights as well as my attempts to do custom things in Symphony I see this as a necessary step forward.

And I think it would be good to not be tied to any particular templating method. I like and plan to continue using and learning XSLT, but we know it's a big barrier to entry for many. If Symphony generates all data/Datasources for a Page as an associative array, can it then optionally convert to XML if XSLT is being used, or pass on the array as it is for other templating methods, allowing for modularity in this area? I'm imagining no template module being installed by default, with the developer getting to pick their preferred option(s) right from the get-go of a project. (Composer?)

I suppose if that were the case, where Symphony currently outputs separate data sources (depending on how the developer sets things up, of course) and the developer shows related entries in the right nested places by, for example, using XSLT keys, Symphony could, instead, tend to output related entries as child variables in the array where appropriate, like SSM does, allowing for simple for-each use in a PHP-like templating engine?

Perhaps we could increase awareness and usage of XSLT by drawing in users who would give Symphony a go because they know they can use Twig (comes with Symfony)/Blade (comes with Laravel)/whatever and then showing off nice, modular XSLT template schemes.

If Symphony generates all data/Datasources for a Page as an associative array, can it then optionally convert to XML if XSLT is being used, or pass on the array as it is for other templating methods, allowing for modularity in this area?

Please remember the name: "Symphony - Open Source XSLT CMS"

If the XSLT/XML is killed, where is the advantage of the system or the differences to another CMS?

Do we really need more then one template language? Twig, Smarty, Blade & Co. are parsed by user function, but with XSLT you can use (fast) native PHP functions. The core should support only one template language. Everything else is too much work for core developers and the community.

The focus must be on the concepts of Symphony: sections, datasources and events with XML/XSLT and a nice, easy to use and flexible UI.

Perhaps we could increase awareness and usage of XSLT by drawing in users who would give Symphony a go because they know they can use Twig

But they will just use Twig. People will not learn xslt if they don't want to, so we will be (like all other CMSs) backing away from our stance on standards. It's the biggest point of the Tao of Symphony; standards.

I can't re-iterate this enough, it will lose us our focus. We are the XML and XSLT CMS, and we will no longer be, it will be just-another-template-layer-we-offer-that-no-one-ever-uses-and-then-get-dropped-in-a-year. 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?

The core should be written as xml+xslt (even admin pages), and offer other templating systems as an addition on top of the core processing, but should take a PHP developer to install them.