Symphony.

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.

Same here. I've never switched to Symphony because of XSLT, but mainly because of its clean and simple UI, its flexibility, the way I can put things together in the backend and the clear separation between what the system generates and where my HTML starts.

But I guess this should be another discussion and not mixed with the move to Laravel.

Same here. I've never switched to Symphony because of XSLT, but mainly because of its clean and simple UI, its flexibility, the way I can put things together in the backend and the clear separation between what the system generates and where my HTML starts.

Agreed. However, XSLT is the reason I have not switched to Rails, Django or Laravel. I simply love how modular and flexible it is, and using other languages really feels like step down.

Not a framework, but based on a framework. Not a simple CMS, but simple to adopt and use.

Absolutely. I think any comparisons of using a PHP coding framework or Symphony for a project are apples to oranges. But rebuilding on a modern PHP coding framework on the other hand could have legs and a proposal I'm glad is at least up for discussion. Symphony is more like a platform and as @jensscherbl said, it's the UI and flexibility are the big appeals (and of course the fact it's open source).

With that in mind maybe building on a well documented and modern framework will allow more focus on how Symphony provides a visual interface for control of site/app design. The core would be well documented, appeal to all developers of the Laravel community who want a visual interface to provide to clients knowing they can extend it easily, and for those not interested they can still just use the interface to build sites without caring about the underlying codebase. With areas like the core code base being developed elsewhere along with potentially a template language then it would certainly free up a lot more time to focus on core principles and doing them well. ExpressionEngine saw an explosion of growth and popularity when version 2 saw it completely rebuilt on CodeIgniter bringing together both communities. It really opened the door for many.

As for XSLT, personally I don't mind and am on the fence but I'd definitely say that it's one of the biggest turn offs for those that like the look of Symphony but don't yet know XSLT. I love Twig and Blade (PHP), ERb, Slim, and Liquid etc (Ruby), and Handlebars (JS) and it's definitely the way things are going. XSLT already follows the same suit in providing logic-less templates with modular structure and inheritance. It also has the advantage of being a web standard but it's just a little out of favour at present and as a result is being left behind (unfortunately). Providing a choice at least would again be another draw but it's worth keeping in mind that Symphony and the community is as good as it is because it isn't the size of that of WordPress. Sometimes barriers to entry are a good thing!

In terms of clarifying my point of view, I'm on the fence :) But it's very good discussion to have and one which could see some drastic changes going forward.

ExpressionEngine saw an explosion of growth and popularity when version 2 saw it completely rebuilt on CodeIgniter bringing together both communities. It really opened the door for many.

Drupal is changing its whole core system in favour of symfony 2 components. There's a clear tendency :)

You guys certainly got my attention! :)

In order to preface my thoughts, you should know that I'm a newbie to Symphony and to PHP. I'm fine with XSLT, HTML, Javascript, and SQL, with a background in Java and .NET. Scripted server languages (aside from old ASP junk) were new to me. I stumbled onto Symphony because I love XSLT. I figured PHP wouldn't be a problem. So, with that background, please understand the angle from which I've been approaching Symphony.

I have to guess that PHP is part of why Symphony is what it is. The language has breaking changes in point releases and only in v5 gained object-orientation. That history seems to be evident in Symphony.

Those with more Symphony experience may see this differently than I, but to me it looks like choices were made a while back that features would be added before the framework was truly ready for them. Some of those features were extensions (or perhaps what later became extensions) and some were in the core. Again, still guessin. As those features were added and were adopted by the community, the value in adapting the framework diminished. It now seems to be at the point where it would be too painful to fix (i.e. it would break too much of too many of the sites out there). I can only guess that this was hashed out quite a bit in a previous debate.

It seems clear that a rewrite would be "breaking enough" that it should, if undertaken, not be a rewrite at all. It should be a new system that takes the great features of Symphony as requirements. A migration tool to ease the pain where possible would of course be desirable.

Some folks most certainly want to continue to improve the Symphony codebase. I know the team and the community are working diligently, intelligently and successfully with this endeavo(u)r and I applaud them.

Some folks most certainly want a PHP-based rewrite that maintains (some) compatibility with the codebase of extensions and sites. I'm sure there's a happy ground there, perhaps in Laravel (with which I'm not familiar).

But at that point, I -- a newbie with no site to migrate, and with no love for what I've found in PHP -- I'm balking. I'll probably move on from Symphony after I finish the datasource extension I've been noodling on. I guess I'll shop for a CMS system that is founded on a more mature OO language (Ruby on Rails and Java are the candidates I'm thinking about, Apache Cocoon has always seemed attractive). If I'm jonesing for an XSLT layer, I'll find a framework I can jam an XSLT layer onto/into. If nothing feels right, I'll skip the CMS framework altogether and use smaller frameworks (such as ORM). PHP, unfortunately, has turned me off. I'm glad I took the time to get to know some of it, though. It may come in handy in my professional life to come. PHP isn't unusable. It's just not desirable.

The great ideas that are evident in Symphony, though, and the community's contributions, will most certainly last in my mind as I move forward.

Regards, Stu

Just a tiny thing about what defines Symphony CMS for me.

To catch up with part of Nils’ comments: As a mostly non-programming developer I’d really found the data source editor to be the most limiting factor in more complex sites. For example I would love to see an interface for Dynamic data source sorting, and more options for limiting/modifiying output.

From my perspective as a designer, more than a developer, the appeal of symphony has always been the nice and clean way to define the structure of my data within sections, without having to dive in to PHP or far worse SQL. This (plus the output options) is what really makes it stand out against other CMSes and frameworks. So in my opinion enhancing these interfaces and functionalities should be the main focus in further development.

From my perspective as a designer, more than a developer, the appeal of symphony has always been the nice and clean way to define the structure of my data within sections, without having to dive in to PHP or far worse SQL.

I think this is more or less the reason we're all here, but I don't think this discussion should be about weather symphony's content management concept is good or not. If you find it awkward, you probably wouldn't use symphony, right?

Nils has made a good point with regards to the Data Source Editor. It is indeed limited and not suited for complex filtering, but the actual problem is not (only) the requirement for php knowledge but that you end up writing boilerplate every time. With that in mind, the question is: is the DS Editor the real problem we are facing here, or is the problem something more low-level, maybe the datasource itself? And if so, maybe that's also the reason why it's so difficult to write a more sophisticated DS editor. I've scanned through the discussion about XMLElement on Github and it's basically the same. XMLElement has become such a central Object in Symphony and it obviously causes problems.

So you could end up asking: "where do we really need XMLElement?" For creating backendpages? Certainly not (and I highly doubt anyone enjoys writing html that way). And maybe it boils down to "ok, we actually just need xml conversion right before applying the xslt stylesheets and of course for reading and writing configuration". Don't get me wrong, and I'm aware that this topic is far more complex than what I've pointed out, but I hope you get the idea.

For me, regardless of what the underlying API and core look like, Symphony is:

• XSLT - I have gone from confusion to absolute adoration of this as a templating language, I think it is perfectly fit for the purpose of outputting HTML, even if it has limits with other structured data.

• The key concepts - compartmentalised Sections, Data Sources, Events, Templates, Extensions - I could take or leave Pages in the core if their URL routing function could be managed elsewhere.

• The UI - clean, modular and functional as it should be.

If any of these elements were to drastically change, I wouldn't be comfortable calling it Symphony anymore :)

@Sam I second that! :·)

Good summary.

I guess I'll shop for a CMS system that is founded on a more mature OO language (Ruby on Rails and Java are the candidates I'm thinking about, Apache Cocoon has always seemed attractive).

A language does not a CMS make. Especially when these days it's all about layers of abstraction through the software layer. Laravel could very easily be compared with Ruby on Rails now. Each framework learns from others and those in other languages and the best bits from each inevitable bring the game forward. Rails was a masterstroke but now others like Django (Python) and Laravel (PHP), and many many others have adopted similar notions in routing, Migrations, ORMs, IoC etc. Even Composer now provides in PHP what Ruby has in Gems. If Symphony is what you need in a CMS then why look elsewhere? The grass always looks greener elsewhere when looking from afar.

the appeal of symphony has always been the nice and clean way to define the structure of my data within sections, without having to dive in to PHP or far worse SQL. This (plus the output options) is what really makes it stand out against other CMSes and frameworks.

Totally. There's no better way to build a site without having to get entrenched in code. One of Symphony's key strengths which will appeal to designers and front-end developers. And from this point of view it doesn't matter to this target market what the core is written in so considering a core rewrite should be for the point of view of core maintainers, addon devs, and in attracting new back-end devs over to Symphony and it does sound like that side of things could do with a bit of an overhaul.

A personal thought:

My primary goal is not to work on Symphony, my primary goal is to work with Symphony.
In order to work with Symphony, I'm willing to contribute to Symphony.

But contributing to Symphony means "improving the backend" to me, not fixing the underlying PHP framework. Currently, this contribution is difficult because of the slow development of the underlying PHP structure. (This is an observation, not a reproach – I know everyone involved is doing his best, some even investing time excessively.)

First of: TLDR. sorry.

My opinion: I love the philosophy of Symphony. The concept of sections, datasources and events and the o so sweet smell of XSL. I've worked many many hours with the core, adding functionality to Symphony, making extensions, constantly pushing Symphony to the edge.

Currently I have a love/hate relation with Symphony. I love the clean-ness, but I hate the underlying codebase; it's not well documented, coded upon legacy code upon legacy code, and sometimes it can be difficult to achieve seemingly simple tasks.

It's been said before that Symphony is trying to act like an ORM while it isn't. I +1 to use an existing framework like Laravel and build a new Symphony upon it with the Symphony philosophy in mind.

I think Symphony can be a whole lot better if it's not reïnventing the wheel but rather spreads it's way of how content should be managed. I really like what I see about Laravel and I see great opportunities of a 'Symphony based on Laravel'-CMS. Perhaps ditching the old codebase is not that bad.

A language does not a CMS make. Especially when these days it's all about layers of abstraction through the software layer...

I want to agree with you, I really do, but alas, when the CMS you're working with is as bare-bones as Symphony, you're going to be building extensions. I don't mind doing so -- I'm a programmer. At least I get to build them the way I want them. Subject to the API's at my disposal or resorting to hacking. And my time.

The shortcomings of PHP then rear their heads. It has partial OO support and still has recent language point versions that don't support some basic functionality. We're missing some tools. Static functions and function pointers are on my mind because I'm wishing I had both of them as I work. I might be happier if Symphony required and fully supported PHP 5.4, but we shouldn't need to be on the bleeding edge just to get basic object-orientation.

(Stu takes a deep breath)

I'm realizing that I'm thread-hijacking, so I'll quit bashing PHP. I'm sure there are plenty of people here who know it and that makes it a good choice.

Back on the subject, if someone snapped their fingers and presented me with a clean implementation and a clean API on top of Laravel, I might not be sneaking looks at Apache Cocoon and NoSQL implementations (all the while knowing that I owe it to myself to finish and polish my datasource extension for my own sanity). I also want to share my settings config stuff so others can use it in their projects if they wish.

Closing thought: if those people who are now working to improve the existing codebase were to announce that they were going to start rewriting it on Laravel, it would presumably have a vaporware-like effect on adoption of Symphony until it's complete. Is the community prepared for that? Perhaps a different group should take the reins on that, not out of competition or disagreement, but in order to keep the trains running with the existing codebase so that both may thrive to their fullest.

Why "Laravel“? (It is a one man show and all these static calls are a joke!) A framework as codebase is a very good idea. But why not a major framework like Symfony or Zend Framework?

My two cents.

Why "Laravel“?

Some points on why Laravel here.

It is a one man show

Isn't that like saying Symphony CMS is a one man show because Brendan is the lead developer? :-) Of course, stability and developer support/community should be carefully considered.

and all these static calls are a joke!

When They Say Laravel Shouldn’t Use Static Methods…

A framework as codebase is a very good idea. But why not a major framework like Symfony or Zend Framework?

Pros and cons to each choice, I'm sure. As I understand it, Laravel doesn't attempt to do everything and can be thought of as somewhere in between a framework and a micro-framework, and places elegance of code and enjoyment as a high priority. It uses modules from other frameworks for a few areas, and so shouldn't be burdening itself with reinventing the wheel unnecessarily.

I don't have any PHP framework experience to speak of to usefully comment further (apart from Symphony CMS, I've only really been involved slightly with Rails, CakePHP, Laravel recently, and some other CMSes), but I like the sound of that approach and am enjoying my little experiments with Laravel 4 so far.

Some points on why Laravel here. … When They Say Laravel Shouldn’t Use Static Methods…

class UsersController extends Controller {
    /**
      * Display the specified resource.
      */
    public function show($id)
    {
        // find the user
        $user = User::find($id);

        // display view, and pass user object
        return View::make('users.profile')
            ->with('user', $user);
    }
}

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

As I understand it, Laravel doesn't attempt to do everything and can be thought of as somewhere in between a framework and a micro-framework

Is valid for all frameworks: If you do not need a component, then you do not use them. This is one of the big pluses of a framework.

My opinion: The concepts of sections, datasources and events are very nice. XML and XSLT is great. But the codebase is very ugly. Why reinvent the wheel? Use a solid (code)base and create the concepts of Symphony on top.

There are many good frameworks out there. Use these and you will save a lot of time.

The concepts of sections, datasources and events are very nice. XML and XSLT is great. But the codebase is very ugly. Why reinvent the wheel? Use a solid (code)base and create the concepts of Symphony on top.

Straight to the point. It 100% summarizes my opinion as well.

This

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

would be simply great.

I'm starting to understand the modularity of Laravel 4, and I think we could take only the bits we need, and make our own (like XSLTPage) if we were to do this. So our build wouldn't in definition be Laravel per se, but only the parts of it's collection, plus others.

Modularity will win out in this discussion rather than pick and entire 'collection' of Composer modules like Laravel is.

The problem is, who is going to do this while maintaining the core 2.4.x codebase? There are too many companies/agencies/freelancers out there who need support on this codebase for us to just jump onto another one. Also, we have to consider that we have very limited man hours anyway, let alone investing more into another product.

Also, (sorry)

I'm hoping peoples expectations of this aren't that it will happen quickly. Allen and co need to decide overall whether Symphony will move this way, as even though this is an open source project, it is his (and others) intellectual property. There will also have to be some serious planning and research to figure out the architecture of the new product.

It's not just about the coding of it, the major work will be in preparation, research, trial and error. We could be talking longer than a year here.

Just so everyone is aware.