Future of Symphony CMS

[cylkee]

Dear Team, that is to say, esteemed colleagues listed here https://github.com/orgs/symphonycms/people @bauhouse , @bernardodiasc , @brendo , @creativedutchmen , @DavidOliver , @designermonkey , @jensscherbl , @jonmifsud , @michael-e , @nitriques , @pointybeard

I hope you are all safe and well.

The community and I are wondering what are your plans and commitments towards Symphony CMS.

Understandably and sympathetically, the pandemic is proving a very challenging time for everyone with the tragic loss of loved ones, changing working conditions, and pausing to reflect on what's important in life.

Symphony CMS, too, appears to have paused. Several members of the community are creating forks, e.g. https://github.com/petertron/symphonycms, and PRs for the core and extensions to deal with the looming transition to PHP 8, while others including myself are considering alternatives. which is a shame. Symphony CMS appears to be having trouble retaining devotees and attracting newbies.

The 'official' state of Symphony is stuck between 2.7.10 and 3.0.0, see #2809, while there appear to be no commits and a growing list of issues, so it would be productive to discuss how we can get back on track. For example, who has and/or can give control of the Symphony CMS websites and Github repos etc. Most recently, @nitriques, it appeared that you were taking the lead on development, merging PRs, keeping the website up, etc., so it would be especially appreciated to hear what are your and/or @DeuxHuitHuit's future intentions regarding Symphony CMS.

We're still chatting away on Gitter but perhaps this Issue thread can be a rallying point for organising the future of Symphony CMS..?

Best wishes and kind regards.

[michael-e]

Thank you for your kind words, @cylkee !

Engaging in open source software can be very exhausting. So at a certain point, I had to reduce my engagement. I have never been a good programmer anyway, but for some years I tried to help with what I can — "break things". :-) I found many bugs in Symphony 2, and most of the time others fixed them.

Maybe Symphony 3 was too big a project for @nitriques and his company. We haven't heard from him for a long time, and meanwhile I doubt that Symphony 3 will ever happen.

I still run two very big Symphony installations, and one of them has seen all Symphony 2 releases since "2.0 beta 5". Yes, I would love to find Symphony's code polished to work well with PHP 8. But my systems also use many extensions, and unfortunately, as I said above, I am not a good programmer. Finding issues is useless if you can't fix them properly.

I really love Symphony and I don't know how to ever replace it. It's a shame it has never attracted enough people to distill a strong and stable developer team.

Hopefully @nitriques can end the uncertainty regarding his commitment to Symphony.

[jonmifsud]

Hi @cylkee,

Thanks for pulling me in here; Unfortunately I started to shift away from Symphony a couple of years ago.

The primary reason is that I started to build more applications; we had 4 big Symphony installs in addition to a few smaller ones.

We've stopped working for 1 client; passed it on to Stuart Palmer (not sure what his Github handle is right now)

Two of the other projects we've done a UI migration out of Symphony and expect to have the backend moved as well by end of year.

The last one is a bit of a pain as it's a big app to move and I don't have resources.

The primary reason we are moving is that it's been becoming harder to find PHP devs and I've committed to moving cloud; not something I envisage happening with Symphony unfortunately.

If anyone is planning to migrate to NodeJS with AWS Lambda I've got assets around saving entries/reading data etc which I've rebuilt from the core but it's literally on a bare-bones basis to help us migrate. I'm feeling that the future is on NoSQL + Serverless which at the moment I don't think there's the energy to move Symphony in that direction - at least for the kind of apps we built.

If there's something I can assist with some extensions I used to build; happy to help. But my time is very limited as we're really putting all our time in a couple of startup projects.

[designermonkey]

If I look back at the history of the project (as I've kept my eyes on it for a while), it is a tragic story that @nitriques has tried to keep afloat for a number of years; the project had a schism and never recovered fully and has sadly been dwindling over the years. I am very sad about it as this was the majority of my free time for a long time, until I had my first child.

I have been attempting to rebuild the concepts of Symphony as a new platform for at least a decade now, on my own and with the help of Rowan at one point, but then life got in the way a few times as I have three children now and have had jobs which make it near impossible to devote any time to the project.

I was very unhappy with the direction the Symphony CMS project took with the database as it in my opinion, is extremely code heavy and complicated now compared to what it was, so I stopped using it.

I still believe that the concept is spot on for 'domain modelling' as well as basic CMS work and I've used it for some very interesting ideas and projects. I would love to see it continue.

[brendo]

It's really nice to see some old friends in this issue!

Like others, Symphony holds a special place in my heart. It was my first open source project and I devoted a lot of my early 20's to the project. It opened doors for me and one special memory was being able to travel around Germany and meet several of the friends I made along the way. I wasn't a good programmer either, but I was keen to learn and absorb and try to make things better along the way.

Similar to others, I haven't had much exposure to Symphony in several years. The last freelance project I was on decided to pivot away and since then I stopped freelancing and these days find myself using Ruby almost exclusively.

There are several things Symphony got right, and even to this day I'm reminded of it as we see a shift to "headless CMS" that provide content modelling (Strapi, Prismic, Contentful etc.). This was something we had nailed early on IMO, especially being able to extend this with custom extensions.

There are also a few things we got wrong and for that I'm not angry, everyone did the best that they could at the time with the technology available. It's quite easy looking back with our new wisdom to see that perhaps we should of embraced some Symfony or Laravel components when we could so we could spend more time on the product side rather than the guts.

Symphony 3 was ambitious, but it did make sense at the time. The development was mostly funded by a large client that needed a more robust solution to deploy on their systems (AWS I believe) and it was successful in that regard. When the client had a change in leadership, the funding was pulled and we left in a precarious spot. While Symphony 3 worked for them, it was also a greenfields project and didn't have to consider backwards compatibility.

Backwards compatibility was always a bit of a sore point in the community. We were quite poor at it in the start and given we formed strong friendships with many of the community, it hurt to see that our releases were breaking their client projects, causing grief and costing them money. We definitely got better as the releases matured, there were less breaking changes, we released more frequently and we communicated better but fundamentally I think it introduced a bit of fear into the process. Instead of channelling that into things like testing I think we just stopped being ambitious.

For me this was probably the tipping point. We had pushed Symphony a long way (given it started on PHP 3!) and we really needed to start fresh and double down and what we did best (IMO that was Sections and Extensions) and take advantage of some of the frameworks that we around that could of done some of the heavy lifting for us. Doing this in a backwards compatible way was the hard bit, and for me at least, it introduced a lot of fear and hesitation. I didn't want to let people down, especially those that relied on Symphony for their business.

I think focusing of content modelling would of lead to decoupling the system from XML/XSLT and more into "data" which can be transformed and rendered in various ways. We really missed the boat with JSON (Remote DS came too late) and forcing developers to use XSLT was always going to be decisive. It made sense at the time, it was a standards based CMS after all.

I guess the speed of development is different these days, there are many defacto standards and attempts at creating new frameworks that gain support overnight without any real formalisation. There's still no way to transform JSON content in a standards based way, so even with hindsight, I'm not sure what solution we would of implemented that was true to Symphony's core value.

At the end of the day, I'm curious to see what becomes of Symphony. Like @designermonkey, I think there's a strong market for a product that makes content modelling easy and intuitive. Symphony definitely has a lot of experience with this, and even the companies doing it today struggle with many of the same things we did (migration between environments, multi-developer teams etc.).

[cylkee]

Thanks, all, for taking the time to comment in great detail. It's been very informative and insightful.

For my part, I discovered Symphony around eight years ago. At the time, I was into just HTML/CSS/JS and some basic PHP and I landed a big project - a kind of sink or swim moment. I was lured by the ease with which I could model data structures on-the-fly without needing to learn SQL. I had no clue about XSLT/XPath and initially I struggled with it, but I've grown to love the versatility and flexibility of the whole CMS. It's certainly helped improve my relative skillset and expand on what I think is possible.

From the outside at my level of knowledge, it looks to me like Symphony has great potential. I only wish I was more skilled to be able to contribute something meaningful. Just before the pandemic struck I set up some dev servers and started UI/UX testing of 3.0.0, but more and more I was getting the impression that the community and repo was losing traction.

Recently, @animaux has brought my attention to a conversation he's had with @pointybeard about their fork pointybeard#4 Maybe there's a chance for some coalescence of forks into something 'official' in the future. I will continue to have existing personal and professional Symphony projects to manage, but with sadness and regret I've decided for the time being to focus my spare time and energy into learning something else that's in active development.

Thank you again and best wishes.

[animaux]

I honestly don’t think there will ever be another official symphony release.

@pointybeard is developing and modernizing her fork for her own needs and is understandably not keen of making this an official version with all the community pressure that involves. This however seems like a good thing, and the stuff her libraries does and her future plans look very interesting, especially since she is trying to keep compatibility as far as possible. I still have to understand how the libraries really work, since I am no man of proper PHP skills … but sometimes I can still learn a thing or two.

In short, it’s the only future I currently see for symphony, and its nice that it is in the hands of one of the original creators of symphony. ;)

[creativedutchmen]

It's great to see so many people I've spent a huge part of my (online) time with in this thread. It feels like a warm bath.

Like most of you, I've not really used Symphony in a long time - I've migrated some of my clients towards other systems (like Wagtail), and basically stopped the rest. Web development was a blast, and I learned so much I can still use in my day-to-day work, but I have moved on to the field of data science.

For me Symphony was the first (and still the only) system that really allowed me to build the applications / websites I wanted to build for my clients, without writing everything from scratch. Our internal administration system is built on Symphony, and we still use it to send the occasional invoice. It's that powerful. Using XML and XSLT was a bold move, and one that made a lot of nice things possible, but it was probably also something that deterred a lot of people. For instance, I had a hard time finding someone to take over maintenance of a website simply because nobody wanted to work with XML.

Even though I no longer have skin in the game, I would very much like Symphony to survive - there's nothing quite like it.

Thanks so much to all of you, I had such a great time with all of you!

[jensscherbl]

Sorry for the late response.

I also moved away from Symphony a few years ago when I stopped freelancing and took on a full-time position as an Adobe Commerce developer.

Since a couple of month I’m at a new agency now, and also started freelancing on the side again to feed my curiosity regarding current technologies. After looking into the available options and ecosystems, I landed on @getkirby.

For me it represents a more modern version of everything I loved about Symphony back in the days:

• Beautiful, minimalistic and easy to use backend for the clients.
• Powerful and flexible as hell while also well documented and easy to learn and extend.
• Small footprint, no over-engineered frameworks, no interference with the frontend.
• Very friendly, helpful and highly skilled community.

On top of that, I also like that it's open source, but requires a fairly priced license for production use. It enables the people behind it to run a sustainable company and secures future development of the product, which seems to work pretty well so far, judging by the number of regular releases over the past years.

I still have very fond memories of working with Symphony and the Symphony community in the past. Working with Kirby now gives me the same feeling that I had with Symphony back then.

PS. I’m not using it myself, but @nilshoerrmann even made an XSLT templating extension for Kirby ;)

[animaux]

PS. I’m not using it myself, but @nilshoerrmann even made an XSLT templating extension for Kirby ;)

I think he stopped using it himself though ;)

[nilshoerrmann]

Oh, this is a trip down memory lane ☺️ Hi everyone 👋

Yes, we also moved away from Symphony due to the lack of constant development and – as Brendan pointed out already – the project missed some newer developments in webdesign.

We do indeed use Kirby these days and yes, we created an XSLT plugin for it. It‘s also true that we are moving away from it because it lacks flexibility – especially because we are bound to XSLT 1.0 in PHP.

Symphony is still great conceptually. Many ideas are still on point even today – it‘s the implementation that is out of date.

[jensscherbl]

We do indeed use Kirby these days and yes, we created an XSLT plugin for it. It‘s also true that we are moving away from it because it lacks flexibility – especially because we are bound to XSLT 1.0 in PHP.

Hi @nilshoerrmann,

nice to see you again! :) Just to clarify, are you moving away from Kirby, or just from XSLT?

Symphony is still great conceptually. Many ideas are still on point even today – it‘s the implementation that is out of date.

Exactly. Many of the currently popular open source and SaaS systems have adopted these concepts by now, in one way or another. Symphony was very much ahead of its time back then.

[nilshoerrmann]

Just to clarify, are you moving away from Kirby, or just from XSLT?

The Kirby XSLT plugin. Still using XSLT in other contexts and Kirby for web projects.

[animaux]

Still using XSLT in other contexts and Kirby for web projects.

Same here, I’ve only just recently used XSLT for some slightly complicated data reorganization. Struggling with other tools I used a quick symphony installation to do the task in the end … 🙈

especially because we are bound to XSLT 1.0 in PHP.

With EXSLT and custom functions I did not find this much of a limitation in recent years. But I guess when it comes to JSON and so on, it’s a different animal.