Symphony.

I've been using and building websites with Symphony from the beginning. I'm dumbfounded why Symphony has not become more popular.

I've been learning Laravel 4 lately and I'm experiencing the same excitement that I experienced when I first found Symphony. It makes developing an extension with Symphony seem painful. So...

If I had one wish I could wish for, it would be to take everything good about Symphony and rewrite it with Laravel 4.

If I had two wishes I could wish for, the first would be to take everything good about Symphony and rewrite it with Laravel 4... the second would be to make the templating system independent so that one could use whatever fit their fancy.

If I had three wishes I could wish for, the first would be to take everything good about Symphony and rewrite it with Laravel 4... the second would be to make the templating system independent so that one could use whatever fit their fancy... the third would be for $30 million a month to be given to me, tax-free in a Swiss bank account.

Wait a minute, maybe the money thing should be first!

This could make Symphony the next big thing. I know I'm not the only one thinking this is a good idea. Let's discuss.

The thing that sets Symphony apart for me is the XSLT.

If we added the ability to use another template system, then we would break how we provide data, as no other template system I know of uses XML.

Laravel also doesn't use XML, so we would have to build our XMLElement class (or use DOMDocument) and build the XSLTPage class also, which also adds to the point of keeping the template system as XSLT, as there would be no point in building it at all if we weren't going to just provide XML and XSLT.

While I love the idea of Laravel as a base framework, I think the other wishes could cause us issues around the entire setup of the project, especially the money one. Why should you get all the cash? Where's mine??

On a more serious note, there is a lot of talk about Laravel + Symphony at the moment between many of us longer serving community members.

I support this (not the money thing of course, since he would only spend it on blackjack and hookers anyways).

This would make contributing to the core and developing extensions in a clean and consistent way a lot easier for people like me.

Also, this would free us from dealing with low-level stuff like sessions, caching, mailing, orm, etc. and gives us more time to focus on actually improving the system and our workflows.

Laravel also doesn't use XML, so we would have to build our XMLElement class (or use DOMDocument) and build the XSLTPage class also, which also adds to the point of keeping the template system as XSLT, as there would be no point in building it at all if we weren't going to just provide XML and XSLT.

The second wish is less important but I think it would help with Symphony adoption. I don't understand why data cannot be sent to views as either JSON or XML based on a configurable option. An XSLT extension and Twig extension (for instance) could exist and developers/designers could choose their templating flavor.

On a more serious note, there is a lot of talk about Laravel + Symphony at the moment between many of us longer serving community members.

I guess we know a good thing when we see it.

This would make contributing to the core and developing extensions in a clean and consistent way a lot easier for people like me.

That's my personal reason as well.

Also, this would free us from dealing with low-level stuff like sessions, caching, mailing, orm, etc. and gives us more time to focus on actually improving the system and our workflows.

This, in my opinion, makes the business case. It allows us to focus on what makes Symphony awesome.

I guess the real question is no longer if we all want this, but when and how to do it. Complete rewrite (a new Symphony 3) after 2.4 (with only minor bugfix updates for 2.4)?

If we added the ability to use another template system, then we would break how we provide data, as no other template system I know of uses XML.

I know you guys all love XSLT. Personally, I'm not really sure about it after using it in many projects during the last 3 years since I switched to Symphony.

From an architectural point of view, an even more modular approach would be to only provide some sort of controller which holds all data for a page in one or more php objects (one for params, one for events, one for data sources).

Templating could then be provided by extensions. For example, there could be an XSLT extension that provides the controller data as the XML structure we all now today and uses XSLT to generate the actual output.

Other people might use other template extensions or none at all to generate their output.

Let me play the devil's advocate.

Judged by the numer of stars and forks, Laravel is about ten times as popular as Symphony. Is that enough? If we add code "on top" of it and call this Symphony 3 (for example), won't we end up having the same user base as today? Why should this undertaking result in a much bigger user base?

Regarding the number of issues in the past, Laravel had around 1800 in about two years, Symphony had around 1160. Does this mean that Laravel is more fun to deal with?

So let's talk about the elegance and overall quality of the current codebase: How can you be sure that it is so much better than what we have? We all know Symphony and its shortcomings so well, and so we may tend to say "others must be better" — but maybe in the end we find out that they have the same amount of issues? (Just because software is a complex matter.)

Regarding maintenance: Do we think that we could fix bugs faster or better if we rely on a community who doesn't know us (and has not waited for us, probably)? If you find a severe bug, would you like to be told "we can not fix it until Laravel changes the codebase"?

Last, let's assume that we really write it down ("What is so great about Symphony?") We might find out that many of these things won't be any simpler with Laravel.

@Lewis I'd really appreciate such an approach. I'm not sure if it has to be Laravel allthough I like it for its simplicity, but there're other great frameworks out there, e.g. symfony, flow, etc. In fact, Laravel uses some Symfony Components (who does not?). But I'm actually a bit worried about Laravel's short lifecicles.

Let's face it: with the arise of systems like Bolt CMS, pyroCMS, or Craft, Symphony's core concepts are no longer a unique selling point (apart from the xslt templating).

So let's talk about the elegance and overall quality of the current codebase: How can you be sure that it is so much better than what we have? We all know Symphony and its shortcomings so well, and so we may tend to say "others must be better" — but maybe in the end we find out that they have the same amount of issues? (Just because software is a complex matter.)

Laravel and other frameworks are fully tested, and with tested I don't mean "Reload Browser: Oh great, it works", and in fact Laravel embraces the concept of test driven development.

The truth is most classes in Symphony just can't be tested and untested code is unpredictable. There's almost no or less seperation of responsibilities. For example look at the Page class and its descendant classes. They are more or less a templating system that does all the businesslogic. There's no clear definition of dependencies and what's even worse: it hides a lot of its dependencies which leads back to "untestable".

Furthermore, Symphony embraces a lot of concpets that are akward or considered bad practice, e.g. introducing global state by leveraging the singleton pattern all over the place, the event delegation system is pretty limmited, there's opcode and configuration outsourced to the database (loaded extension, events and callbacks), the extension driver concept really should be a service provider that does only one thing: providing services with all their dependencies, and nothing more.

Lewis is right. It's no fun developing extensions for symphony with code quality in mind. In fact, I'm worried about the overall code quality of most extensions not only because I recently read something like this in a comment:

Symphony leverages the singleton pattern, so we do as well.

It's fair to say installing a symphony extension is adding a piece of unpredictable software to an untested System.

Don't take me wrong. I really like love Symphony as a CMS because I can get the results I want in almost no time while having full control over the output. As I stumbled over Symphony the first time it was like "yea. that's the system I was always looking for" and that's why I think it needs a fresh start.

I too am going to play devils advocate here (even after my initial response), as after this post, I spent the night reading the Laravel website, and docs trying to figure out what the draws were.

I think the thing that is drawing people to Laravel is the methodology of how it implements it's code. This is the same not only for our developers, but for those on many other frameworks as it is a fresh new way of using up to date PHP.

The thing we have to bear in mind is that we have a very specific way of doing what we do with our codebase, ie Managers and Objects, a very specific way of configuring this too. We can (and have been thanks to Brendan) update the way we do things in the core within the scope of how our specific application works, to use more modern methods of doing things, and there is still a long way to go with it. Composer is a prime example of this, as we could use components from other frameworks, as Laravel even does! (Symfony being a big one, did anyone else notice that?).

Laravel is a framework as Symfony is, as Symphony CMS is too. Just flatly basing our admin on another framework would mean that it is no longer ours, but we could certainly share resources. We are all acutely aware of the fact that the API is in need of some serious love, but we can't forget the time and effort that has gone into what we have.

After the community nearly split to keep the current codebase intact and modified over a full rewrite, Brendan and other key players have pumped in a massive amount of their own free time to move the codebase toward those goals that Sym3 had, at a pace that the community was willing to accept and handle. When I say handle, I mean one that would allow extension developers to keep up, and also try and maintain developers in the working group, and also make it easier for smaller agencies with business investments in Symphony to roll out updates to clients without worry of massive blackout changes in functionality.

Initially, I disagreed with this decision, but now after my time in this project (and the fact I now manage my own team too), I can see why this was the right action to take.

From what Michael said above… We log a lot of issues, we fix a lot of issues. We have a lot of open issues which could scare people off, but these are fundamental changes to what we do hence the length of time they remain open. Starting again would possibly kill this project, as the flood gates would open, and we haven't got the resources to handle it.

One thing I will say again is that we are an XML & XSLT CMS system, we are so much so that we are moving our entire schema system over to XML in the next major release. If you want to use another templating language, then you will have to build an extension to transform the XML into ueable code and go from there. A poll was done not too long ago about templating languages, and if I remember rightly, the choice massively swung in favour of XSLT. After all it is the point of why we are all here, and to change something as fundamental as that would mean we have seriously lost focus as a project.

---

So where do we go from here?

We are on a precipice again about the same decision, but with the pendulum swinging the other way, and we have to handle this carefully to avoid alienating developers and users, but also appease people's worries and concerns. What is needed, instead of a complete overhaul, is a defined roadmap with visible goals, and people who are willing to sign up for putting in the time to get there.

• We need to get a publicly visible roadmap.
• We need to get the new website and documentation up and running.
• We need to elicit a sense of community and direction that has waned a lot over the last two years.

These things need to happen before we can seriously think about reforming major parts of the codebase, although we can definitly plan for when to do these things. We already have a backlog of work to fill two full version releases.

These things are already underway, but lack of interest in helping out to achieve them is holding them up. We all paid a lot of money in contributions to get a great design for the site, but now the actual work needs doing, people have vanished.

As a community lead, I ask for everyone interested in these ideas to write down the things you want to be done, the things in other frameworks you admire that could actually benefit us, and the reasons why, and as always we will try and accomodate these things into the core, or core extensions. I also ask for people to offer time to help us all get to where we want to be, which is on top of the CMS/CMF pile.

I will personally take the time to ask questions and discuss options with developers, and try to assign tasks to people who are willing to help, but we all need to remember that to make the product work, we have to put in the time to do the things that we may not want to.

Anyone who wants to help out properly, please email me: john@designermonkey.co.uk whether you think I have your email or not, and we can definitely get where we need to go which is a great modular CMF that works like Laravel, FirePHP and the like, and also shares resources like XSLT Processors, XMLElement classes etc etc.

Thomas, I wrote this reply as you wrote yours.

I completely agree with the testing issue, and the ease of development. I struggle with it every day, but in hand with that I find it easy in other respects to follow.

Hi John and thanks for your reply.

I think we all here appreciate the time and effort Symphony team is putting in this project.

With regards to losing the projects focus when questioning the core xml/xslt concept I'd fully agree, but I don't think fundamental changes would put this project in danger per se. Take Typo3 as an example. In 2009 the Typo3 community introduced flow3 (or Typo3 flow as it is called now) to the public. Later in 2012 the First stable version of Typo3 6 was released, it was a complete rewrite of the Typo3 core founded on Flow3. Both, flow3 and Typo3 where parallel developments that took a couple of years. In the meantime developers were encouraged to use extbase, which simply was a bridge between the old typo3 core and the new core concepts that were introduced with the flow3 framework. It didn't put the Typo3 project in danger, if anything the typo3 community is bigger than ever. What happened is, that the overall codequality became better not to say outstanding (read about the AOP concept, it's juts amazing).

That said, I believe that having a stable, predictable, and state of the art codebase is one of the most important keys for a successfull and strong community based project.

The key benefits would be:

• more talented developers are more likely willing to spend their free time with such a project.
• overall development cycles and feature implementation will become faster because you spend more time on the actual development than on debugging (and yes, not testing your code because "ain't no one got time fot this" is just a lame excuse :). It's a process we all have to go through: it hurts in the beginngin just like learning xslt).
• hence new features are unlikely to introduce new bugs.

I'm very impressed what's possible in oss development nowerdays, not least due to the popularity of github. Take Travis-ci as an example. It really helps large community projects to stay stable and predictable (e.g. you can configure your repository the accept pull request after a successful built).

To be honest I find it somewhat sad to see that the project is apparently not taking such possibilities into consideration (and I think with the current state of Symphony it's not even an option), at least this is what it seems to me.

Standing on the shoulders of giants

We're not not taking this into consideration, we just need to get a direction together about what to tackle and how.

Personally, I am a little dubious about a full rewrite as I remember what happened last time it was proposed, but if the community and key developers can get behind it, I am happy to follow suit. I would be excited to see the possibilities, but I know there is a lot of other work that needs doing to ensure we have a visible future.

I definitely agree we can take all of the best bits from other ways of doing things, especially avoiding the singleton pattern (I don't fully understand it, but I do know why it should be avoided) as we need solid way of testing code (I for one make many mistakes o_O).

We need to plan thoroughly if we're going to do it, and by all means, prove my skepticism wrong ;)

I think we all here appreciate the time and effort Symphony team is putting in this project.

Hells ya.

What makes Symphony great is not its code base. And I agree, faults can be found in any approach. But there is a huge benefit to working with a solid foundation, as iwyg nicely outlined.

Personally, I am a little dubious about a full rewrite as I remember what happened last time it was proposed, but if the community and key developers can get behind it, I am happy to follow suit

I do not believe a rewrite of Symphony's PHP is as daunting as it sounds when working with a framework such as Laravel 4. Much of the mundane tasks are handled by the framework.

This could be a turning point where Symphony is more about Symphony and less about PHP. In other words, I believe there'd be less reinventing the wheel and more innovation.

In other words, I believe there'd be less reinventing the wheel and more innovation.

Agreed. See Standing on the shoulders of giants

The good thing with using such frameworks is, that you only use the components you really need. See Laravel's Illuminate bundles or Symfony's components. Or doctrine. In fact, most frameworks share components (flow3 uses doctrine's dbal, Laravel uses symfony's http kernel, almost all of them are using monolog that implements the psr logger interface).

especially avoiding the singleton pattern

I think the singleton pattern is commonly used because many developers believe that this is the only way to ensure the uniqueness of a class instance. This is however not the case and leads, as you pointed out, to problems when it comes to testing. The easiest way to ensure the uniqueness of an object is to just create one instance.

There's a concept called Inversion of Control which implements the serivce locator pattern that is considered bad practice by many developers, but it's actually not. It just depends on how you use it. Most IoC systems offer a way to create a shared object that stays unique for the whole application runtime. In fact, laravel's application core is just a huge IoC container and all services register to that container. This way you write much cleaner code that's easy to test, and most of all: it's reusable.

Switching to a framework would of course never "solve all problems". It would most likely create others, for example in the relationship to an independent group of developers. That said, we are already relying on third party components that are essential to our system, like jQuery as our JavaScript framework or Markdown for text formatting. We just aligned our development processes to these components already.

Personally, I discovered Laravel when investigating framework options for a web app that will use a custom front-end interface and doesn't need a default backend like Symphony offers. I really enjoy working with XSLT (who does not in our community?). But I have to say that the best templating layer doesn't help if a system is not stable or lacking basic features. Symphony promises to be a XML and XSLT content management system. A concept that is really interesting for designers that work with HTML markup and CSS. But does it really live up to this promise?

I don't think so.

As soon as you dig a little bit deeper, you'll notice that you'll need PHP knowledge. You need advanced filtering conditions, simple negations? Not possible in the Data Source editor. You need to create a front-end form and need some default values? Not possible in the event editor.

Of course there are extension for this. But the group of active developers is so small that maintenance is really a question of available time. New Symphony versions are breaking compatibility, extensions don't get updated and you need to dig into the PHP again. Of course it's good, that Symphony is changing – I actually think it has to change much more in less time – but we are waiting for structural changes under the hood to finally work on the most essential parts of the systems: the interfaces (API and UI) that are used by developers and authors. And some features have been planed and promised since years.

We are building a XML based content management framework, and one of the biggest problems is XML creation time. But we have to postpone a fix because we need to tackle other things first or because we don't have a solution? This is a huge problem.

Symphony cannot concentrate on its core features at the moment: XML, XSLT, flexible information architecture and data retrieval. We need a solution for this, otherwise my guess is that even long term contributors will move along (some already have and that's a great loss).

These issues are of course not a problem of reluctance: the biggest problems are time and money. We don't have enough contributors or these contributors don't have the monetary resources to invest time in this lovely open source system called Symphony.

I think this discussion should not be about whether to use or not to use a framework: as I said in the beginning, we already use frameworks. The actual question is: do we focus on the right things? What is Symphony about? Where are its strengths? We should definitely only invest our time into these core areas.

The actual question is: do we focus on the right things? What is Symphony about? Where are its strengths? We should definitely only invest our time into these core areas.

^ This. Because when I think “Symphony”, its use of XML and XSLT are the first things that come to mind. If one is not on board with using these tools, then why would one use Symphony in the first place?

Hence, I too have reservations about the idea of basing Symphony on Laravel. Mainly, I wonder how that would be different from simply leaving Symphony and building an XSLT view system on top of Laravel. (We could call it Simfony!)

I guess what I’m trying to get it is an existential question: if we decide we want Laravel to be the new basis for Symphony, why bother having Symphony at all? Why not just Laravel + XSLT?

I completely agree with what others here have said about borrowing, stealing, or otherwise integrating other frameworks’ components into the project. That’s par for the course. However, I feel like this suggestion goes beyond integration and is more like assimilation. I think this underscores what Nils said above: we need to decide what Symphony is before we decide what to do about future versions. As John said, we need roadmaps and more publicly visible plans for the project. Maybe then we can understand what the project needs. I’m sceptical about simply basing it entirely on another framework though.

I guess what I’m trying to get it is an existential question: if we decide we want Laravel to be the new basis for Symphony, why bother having Symphony at all? Why not just Laravel + XSLT?

It could be an option to have Symphony as a Laravel bundle. Symphony is more than XML and XSLT: it's an UI and API as well and the system has been outstanding in these areas for years. The question for me is: how do we keep our system up-to-date and how do we keep up with younger projects providing a better API and UI but opting for another templating layer?

This is why we should focus – what that means for us needs to be discussed and decided here.

Just been skimming through this; I would agree with saying that symphony is not quite perfect; and there are some issues every now and again but that would be applicable for all the projects I presume.

Though I haven't really tried to use Laravel just yet I am not too sure to what you're referring to as being too complex. I've been working on some interesting extensions (some for personal use in symphony) and whilst maybe the Documentation is not perfect (which is probably where we lack alongside the testing) I was able to more or less do everything bar one unique case where I had to try insert GEO localisation in a field.

I think a roadmap + suggestions of what would make things easier would be good starting point.

Interesting discussion. I've been using Laravel since version 3 and version 4 really took things to another level. Composer and PSR compliance really opened up the field. It is a fantastic framework and community. I had actually thought to myself that my ideal would be Symphony's UI, elegance, and philosophy, in combination with Laravel's code base under the hood but only ever thought of this as a pipedream which wouldn't/couldn't ever happen. That's not to say it's not possible but just with the huge directional shift and wholesale changes that would come with it.

I think we all here appreciate the time and effort Symphony team is putting in this project.

'kin A to that!

To touch on why Laravel's moved along so fast to get where it is would be to analyse both it's strength and weakness. Taylor Ortwell progressed it for his own needs (originally) and with each version release wasn't thinking of breaking compatibility or having to support a million sites already using the framework. It was young, didn't have a high adoption rate, and hadn't been around for years seeing many production systems depending on it. Symphony does have that to consider so it's understandable that it holds' things back. The parallels are similar to that of CodeIgniter in that sense and it too had prominents community members leaving and jumping on the bandwagon of a bold, vibrant new framework that wasn't afraid to shake things up with a split in opinion (Interesting to note Phil Sturgeon's comments on above article and his shift in opinion and eventual adoption of Laravel 4 later on in place of both CodeIgniter and Fuel.). You can however see why there are very good reasons the longer serving frameworks needs to think both backwards and forwards whereas the new frameworks can afford to throw caution to the wind and only look forwards. Any directional shift in Symphony would need it to be a new major release version (Symphony 3) and then eventually support would tail off for v2. That would also mean having to juggle two very different code bases for a while and stretch resources even more.

There's always pros and cons. The shift will definitely attract a number of developers and will allow Symphony to use resources from lots of other resources via Composer bringing it up to speed with modern systems. It will be easier to build for and maintain but the downsides would include what happens if/when Laravel 5 comes out? Another rebuild anyone? If you've looked on the forums for Laravel 1 and 2 you'll see that support does reach a cut-off point and anyone who built their systems on those framework versions are pretty much on their own. So it's something to consider in then having to keep pace with that frameworks releases.

why bother having Symphony at all? Why not just Laravel + XSLT?

For me the needs are different. If I'm working on something where there doesn't need to be a back-end UI then a framework would be a good choice. If I'm working on something for a client who needs a back-end UI a CMS like Symphony would be the winner. I wouldn't like to re-invent the wheel and build a new back-end UI with all the functionality associated for each new client project. It's the whole approach and philosophy of Symphony that sells it. I know I'd be getting elegance, simplicity, and flexibility to do what I want. Tried and tested saving me countless hours.

I've been waiting for this debate to happen for a while now, and I'm happy that Lewis was the first to be outwardly vocal about it.

Symphony exists in an awkward space. It's too simple/lacking for people who require a framework, and too complicated for people who need a simple CMS. The market the Symphony entered upon conception has changed. Wordpress (like it or loathe it) is a completely different beast with a multi tiered eco system. Drupal is down, but not out.

Symphony needs to be re-established as a true CMS, that sits comfortably in it's space. Not a framework, but based on a framework. Not a simple CMS, but simple to adopt and use.

I think there would be nothing lost if we were to build upon a tested framework. Everyone has done a stellar job in keeping the project alive and moving forward. So by continuing with building it on something else, just means we're bringing forward the experience and knowledge that was built up over the years.

So, as Tachyondecay, pointed out, we need to agree on what Symphony is before we can commit to any framework or path forwards. Choosing a framework will boil down to choosing it for stability, longevity and community size.

We already have our own loose set of principles and ideas. We need to take these concepts, write them down, agree and commit to them.

Symphony, is and always has been a CMS. It does have traits of a framework, but essentially, it is not. That being said, we understand that it's strengths are ease of use, I think one of the great unsung strengths is the admin UI. It's more intuitive and powerful (via extensions) then anything else I've come across. It still has drawbacks, but we can address these better with a new start.

I think we should solidify the Admin concepts, the Api concepts, and the core of what is great about a CMS: Content, Management, System.

Management of Content. A System of Management. And Management of the System.

It may sound cryptic, but that's all we need to start with.

The other great discussion is XML/XSLT.

I am happy with XML, but I've grown to loathe XSLT at times. It has amazing things about it, but at other times, I feel like it's a burden. I've grown a skill that I find hard to apply on other projects. I don't think I've written two projects which share enough of the same XSLT, looking back at older projects is sometimes confusing.

I've grown to like Twig, Handlebars and such, and they're everywhere, I'm in favour of this approach.

Symphony is more than XML and XSLT: it's an UI and API as well and the system has been outstanding in these areas for years.

Even liking a lot of XLS+XML, this template system have low relevance in the reason why I use Symphony (sadly I see the opposite around me, it is relevant in the reason why others not use it). I love the way Symphony do what he does, mainly on user experience and how easy/fast is creation and mantain a full customised website.

But Symphony on Laravel is not about the template system, right? Laravel already have good documentation and a lot of great tutorials around web. Is a good PHP framework choice as Jquery is for Javascript? How about Angular? Choices like this perpetuate by years.

Technically I'm not able to have an opinion about programming decisions. In general, outsource part of the system can have very good benefits. Is this will help us evolve, get better results, grow up community and contributors? What about the development process? The key developers are comfortable with the idea of rebuild entire system?