Who cares?

[nilshoerrmann]

I'll play devils advocate. @jensscherbl [asks on Twitter]():

What's going on? No one using Symphony anymore? Is it dying?

I say, yes, it will die, if no one takes leadership. Is there anyone willing to really lead this project actively? With knowledge, vision and enthusiasm? Or is it dead already?

[bernardodiasc]

where people without tecnical instruction is getting websites done

Yes, I mean Wordpress. Which became a powerful platform and is widely adopted even by skilled developers. Personally I don't like WP, but I can see it value.

Beside that, I see the content output as part of the content management. In this aspect, the absence of predefined content structure and templates in Symphony is a great advantage that allow us to build frontend layouts with creativity.

I like Symphony the way it is right now. Popularity don't mean quality. But if we narrow down too much the niche, the project also lose strength. And we need to start consider some market demands to make things economically viable.

[nitriques]

I do not agree. But this is a separate topic. I think more of Symphony like a application framework like Django or Rails.

[iwyg]

@nitriques Thanks for pointing out that Symphony is primarily meant for developers.
But I do not agree on your last comment. Symphony in it's current state is no application framework and it never was. At most it's a content management framework, since you're allowed to shape your own content structure and that it's not opinionated about generated output, etc. But due to it's lacking api capabilities it's not a "Framework" actually.

@germchaos Wordpress is a perfect anti-example of what we are heading for. WP has the same problem as jQuery. To may plugins, too less quality. Everyone can write wp/jquery plugins without any knowledge of the underlying language, because both make it ease to do so. I wouldn't say that jQuery itself is bad, not at all. But WB is, the code is scary, and we have to face that this also applies for the current Symphony source.

Look at Craft. Craft is a quite decent cms/cmf that combines most of the key-principles of symphony and it has gained a popularity level in just no time. That's our competitor and it has overrun symphony already.

[nitriques]

@iwyg

Symphony in it's current state is no application framework and it never was.

I agree. I lacked a better word...

But due to it's lacking api capabilities it's not a "Framework" actually.

I would not say that. It's a framework. Not made to be friendly in some parts, but still a Framework. I like CMF more than I like CMS.

Wordpress is a perfect anti-example of what we are heading for.

Make that in bold please :)

Look at Craft. Craft is a quite decent cms/cmf

Is it open source ? Can I use xslt as template engine ? :-1:

[bernardodiasc]

@iwyg according to the fact that maybe my writing is not understood (localization issues), WP is indeed a very bad choice, that's what I mean when told about large adoption with low quality cheaper demand.

For the record http://www.getsymphony.com/learn/articles/view/the-tao-of-symphony/

Do we have Next specifications and technical requirements already?

[nilshoerrmann]

@nitriques Thanks for pointing out that Symphony is primarily meant for developers.

It was not in earlier days – it attracted a lot of designers without a development background. Old guy goes away feeding pigeons again …

[jonmifsud]

@nilshoerrmann I do think it still is geared towards designers, as well as developers.

As long as you have basic knowledge & common sense you can handle Symphony. Obviously with docs not being so updated; it would always be harder for new designer picking up symphony; then a developer if the proper docs & guides are not provided.

[allen]

When we talk about developers in Symphony's context, I think more in terms of web developers. Someone that is not necessarily a bonafide programmer, but rather someone with a balanced understanding of the web. In this sense, we're talking about a "web developer", not a "software developer" and certainly not a software engineer.

Of course, as a "web developer" wants to do more advanced stuff with the system, then they will require knowledge in those relevant areas. For example, asynchronous data exchanges, REST API and external service integration.

Strictly visual designers will invariably have a hard time understanding the system. The very concept of sections (which is another word for data structure) will be a huge challenge for them, let alone having to wrestle both HTML and CSS at the same time as XML and XSLT.

[allen]

A belated response, but thanks for @padwanRO for chiming in. Evidently, there are still lots of users and contributors that are still invested in Symphony and still use it regularly in a commercial environment.

It has always been the case that, when we need to start with a new system from scratch, a significant amount of energy is required to get the ball rolling. The Next project at this point in time is a little premature. We're still in the stage of "gearing up for things to come".

As Daniel explained, we simply need to be patient and wait until we get all the ducks in a row. Daniel had the idea of getting Symphony on a new codebase for several years now and his persistence and patience shows that he is confident and committed to the project.

I understand that it is frustrating to see how slow things are moving, but we shouldn't move against the tide. As funds are made available, people's time is freed up and ideas become matured, that is when we'd be truly ready to move to the next stage.

In the mean time, we have Symphony 2.3.3. I hear it's pretty cool :)

[designermonkey]

Damn right it is! ;)

[nilshoerrmann]

When we talk about developers in Symphony's context, I think more in terms of web developers. Someone that is not necessarily a bonafide programmer, but rather someone with a balanced understanding of the web.

One of the biggest benefits of Symphony 1 was the fact that web designers (those of us doing HTML, CSS and JavaScript) were able to create complex sites easily without having to dig into PHP. You only needed to learn XSLT which was not that hard if you knew HTML (xPath made things complicated but powerful). Even the installer was just a single file. It was all about simplicity.

That changed silently with Symphony 2 where even web designers had to look into the underlying PHP source because of bugs or laking core features ("Why don't you just create an extension"). For me as a long term user, saying that Symphony is primarily meant for developers (those doing PHP and MySQL) is the confession that Symphony failed on the interface and thus designer focussed system components. It's a shift in perspective, although it might just be about accepting the reality.

[michael-e]

We shouldn't forget: One of the biggest benefits of Symphony 2 is its increased flexibility and extendability, and maybe these have come at at price. For example, the attempt to make everything manageable in the backend is a tedious task if you want to improve the flexibility of datasource filters. Another point, from my personal experience: Many parts of the backend don't scale well with bigger websites. So in short: The current concept has compromises (which in turn make people take extreme standpoints in the whole discussion).

Of course I understand Nils. When I started using Symphony (with version 1.5) I was pretty sure that I would never have to do PHP and MySQL stuff. The opposite has been the case: I had to learn a lot about these things. Partly this has been caused by pushing my limits more and more with every project — which is an interesting side effect of using Symphony. :-) But to a certain extent I may have had a naive understanding of Symphony's promise. And yes, I remember: Symphony 2 had a really bad start. Long ago I had my biggest website running on Symphony 2 beta 5, and I remember well that it was wonky, to say the least.

Get over it. It's impossible to be everybody's darling. (Maybe Symphony's biggest fault is to give this promise?)

@allen is right:

Of course, as a "web developer" wants to do more advanced stuff with the system, then they will require knowledge in those relevant areas. For example, asynchronous data exchanges, REST API and external service integration.

Things that I have built will never be possible without coding a lot. The question is: How simple can "building and maintaining a website/web app/whatever" be anyway? Can we do everything using a GUI? Probably not. If the GUI is limited, can the system use XML or XSLT to push the limit? At which point do we force developers to dive into PHP (i.e. leave coding and start programming)? And if PHP is really needed to do or extend things, how simple can that be? (This is one of the reasons why we want to use a framework, right?)

Still, this is the biggest thing about Symphony next: We can think it over. And don't say that you give up now just because people have different approaches to Symphony, or coding or programming in general, or ideas for the architecture of Next. Give it up when it's lost for you, but hey, there is nothing to be seen at this moment, nor is anything settled, so how could it be lost?

Please imagine, purely theoretical, Symphony Next being ahead of Symphony 2 to the same degree as Symphony 2 pushed the limits compared to Symphony 1. How cool would that be?

In the mean time, we have Symphony 2.3.3. I hear it's pretty cool :)

Yep, it probably is. I really have to try this associations stuff. And I am convinced that, again, the overall quality has improved a lot.

[nitriques]

@nilshoerrmann : @allen answer is what I meant by 'developers'. People who understand xml, xslt, css, html, that has a basic understanding of how to program. If Symphony would require a B.Eng degree, I would not be nice.

That changed silently with Symphony 2 where even web designers had to look into the underlying PHP source because of bugs or laking core features.

That's true. But I think the goal is still to be able to create complex websites without having to do PHP. Hey, I am a C programmer and I loved the fact that I did had to do that much PHP. Even more, on the majority of our websites, I do not do PHP. Never.

Just like @michael-e says

Partly this has been caused by pushing my limits more and more with every project — which is an interesting side effect of using Symphony. :-)

But you can't build a really complex system without having some kind of programming language. If you do not want to do PHP, well respect the limits the system can give you. Or do PHP and you are free to do anything you want.

@michael-e

Please imagine, purely theoretical, Symphony Next being ahead of Symphony 2 to the same degree as Symphony 2 pushed the limits compared to Symphony 1. How cool would that be?

I CAN wait to see that :)

@allen:

In the mean time, we have Symphony 2.3.3. I hear it's pretty cool :)

YES it is! I updated a bunch of extension for 2.3.3 (specially field uploads one). Relations are awesome too. Thanks @designermonkey

[bernardodiasc]

Consider everyones previous experiences with this CMS, for what kind Symphony 2 applications you can tell it is great? And for what kind it is not?

For example: Its very easy to build an institutional website. But its hard to build a fórum.

Some extensions have great concepts proof to heat Next perspective (examples: https://github.com/symphonycms/members, https://github.com/vlad-ghita/symphony-resources, https://github.com/vlad-ghita/sections_event, https://github.com/Petertron/symphony_deluxe, https://github.com/hananils/storage, and many many many others... localization, versioning, dump content and content strcture, access levels, enviroments, ui improvements...) - this things are Symphony 2 being awesome!

My first impression on old Symphony 3 discussions, is that would be a file-based CMS. Easy to transport data and structure as an improvement to what we have today.

[nilshoerrmann]

It would be great if Symphony was separated into three components:

1. an API that either the backend or the developer interacts with directly
2. a backend, offering an UI to administer content and structure via the API
3. a templating layer using the API's output

Having an open API as the core of the system would focus on content creation and content retrieval (either from direct input or from another source like an external API). The goal of an API is not to create HTML but to serve data and to serve this data in different flavours as needed (XML, JSON, PHP array).

Separating the backend from the API would allow advanced developers to circumvent the UI, interacting with the data directly. The main backend could just focus on the basics needed for 95% of all cases. And having an API it would be easy to just plug in a different backend with a different focus.

Having the templating separated into a separate layer would widen the possible Symphony use cases: while XSLT is a great tool the create HTML or ePub documents, JSON is a much simpler choice if you are working on a JavaScript based web application that wants to share data with the core but uses a frontend templating language.

---

This way Symphony would still offer everything needed for classic websites but would also be better suited for applications that just need a content hub.

[bauhouse]

@rowan-lewis, I am curious to know more about the Symphony 3 code base that you have been working with for the past three years. Is there anything public that you can point to?

@nilshoerrmann, I like the idea of three components. Opening up an API is definitely the way to go.

[nitriques]

@nilshoerrmann Very good idea man.

[jonmifsud]

@nilshoerrmann I really like the way you've split it up; I think puts the focus on the aspects we need to develop.

[brendo]

How Nils has described it is pretty much the loose architecture I had in my head. I think Craig used to refer to this as Symphony eating it's own dog food. By making it do that for the admin layer, you're proving the framework works and can develop complex applications.

[jensscherbl]

@brendo

Do you have enough spare time (and interest) to just start with a prototype and continue as lead developer?

I think all that's needed to keep this going is someone taking the lead and make decisions, even if that pisses a few people off.

You should just choose a (well documented and seemingly futureproof) framework you find suitable, talk to people off the record about ideas and suggestions if you need, and start coding.

I bet it would be a lot easier from there for the rest of us to jump in and help with whatever task you delegate to us, be it coding individual parts, writing docs and tutorials, wrapping everything up in a new community site, etc...

@nilshoerrmann

Sounds good to me. And by the way, that's exactly how ProcessWire works (but with a different approach to sections and stuff, which I still don't like as much as Symphony's).

@allen

In the mean time, we have Symphony 2.3.3. I hear it's pretty cool :)

True. The main problem for me is the current state of the ecosystem. Symphony itself lacks certain functionality, and the extensions catering to these use cases are often orphaned (Symphonists), not up to date with the latest Symphony release (last stable release of the Members extension is 7 month old) or poor quality in general.

I guess a new Symphony wouldn't solve all of these problems either, but my hope is that it would be easier to develop my own extensions (better API, better documentation) for particluar projects (in a reasonable amount of time, without trial and error and digging through the core) or participate in the development of larger extensions like Members.

[designermonkey]

I did actually start to outline this idea in April, but no one seemed that interested. https://gist.github.com/designermonkey/5380725

[brendo]

Funny you should mention that Jens, it had crossed my mind to just do something and then get people onboard. This process feels a lot like the Members extension, we found the large chats were a great way to get ideas and feedback, but it was better to have a much smaller team decide and build the product based on those discussions.

[michaeljgilmore]

While I'm a newbie I can tell you that Symphony is a new choice for us and would hate to see it go away. If I can offer help in any way I'd be happy to lend a hand. Cheers - Michael

[nitriques]

@brendo

it was better to have a much smaller team decide and build the product based on those discussions.

I think that's pretty much the way to go. http://insideintercom.io/product-strategy-means-saying-no/

[michael-e]

Great article!

[iwyg]

@nilshoerrmann What do you think this API should look like?

• Request
• Users/Security
• Services (all of them :))
• Response

would be the bare minimum imo.

Not sure though If I get you right here. What do you mean by "Separating the backend from the API"? Is it with regards to the current Symphony CMS?

Normally, a backend would be "just" a secured area of you application or website where a user can interact with the application, alter its behaviour, add or delete content etc. If you're referring to the separation of UI and API, then I totally agree (separation of business logic and presentation). But I actually thought that this was clear already?

[designermonkey]

The core app would be a REST API pure and simple, that way it could be loaded into another app's IoC container and called by php methods, or used via HTTP. The other app would be a backend interface, or a frontend interface, which could both separately call in the API app into their containers.

It would allow the app to live on a separate server if required. It would also mean the admin/frontend would need to be able to be configured to allow access to an API via php (embedded) or REST (separated). It may mean a little more work in building the admin and frontend to allow bot methods.

I've thought this idea for a few years, but not had the skills or team to build it. I have started a little core app personally on these ideas, but still haven't any time to do the work :(

[nitriques]

@designermonkey This is really a neat idea. It think the focus should be put on the php api first. And then extend it to http.

I will try to do some architecture work on that soon.

[designermonkey]

All the REST stuff would be done by routes anyway, which would call the same php methods anyway.

[iwyg]

But don't reinvent the wheel. Just take HttpFoundation as a starting point. This stuff is amazing.

[designermonkey]

I've started something with Slim and it's coming along nicely, although its not Symphony,mits another project for now.

On 19 Jul 2013, at 16:34, Thomas Appel notifications@github.com wrote:

But don't reinvent the wheel. Just take HttpFoundation as a starting point. This stuff is amazing.

— Reply to this email directly or view it on GitHub.

[gkhalley]

I don't think anyone is as excited as they should be. A direct investment by @padwanRO and company is exactly what Symphony CMF needs. It will be a rocket engine if it's played correctly.

2.3.3 is solid. There is time, people-power, and momentum to get to Next soon!

However, making the API the center of the framework is a mistake. The focus should be on how to rapidly communicate the framework parts to the website developer. Not only is the existing user interface a good start toward this end it will be the unchanging part of Next. Expand and expose more of the abstract concepts to the user interface.

Secondly, make the back-end database correspond with the front-end. In other words, use tables. People already understand SQL and everything can be done with a single line in most cases. If you can learn XSLT, SQL can't be that hard. Later on, maybe offer a NoSQL database.

[iwyg]

When people talk about Symphony CMF, this is what I'm thinking of :)

@designermonkey did you have a look at this? It's been around for quite a bit but I haven't had the time to dig in deeper. Reading about the php Content Repository implementation is quite interesting though, especially with regards to a CMS implementation.

People already understand SQL and everything can be done with a single line in most cases

Sure, but there're good reasons to move away from raw sql. First of all, I don't want this in my code, not just because it sucks but also it's not testable. Second and most likely the most important aspect in not using a raw sql implementation is Security.

[jonmifsud]

People already understand SQL and everything can be done with a single line in most cases

There are also levels of complexity when it comes to dealing with data the way Symphony does at the moment, the data is currently organised per field allowing users to add & remove fields at ease, reducing the risk of doing damage to data held in the same table. This does come at a cost of having to understand the Symphony structure if you want to do some custom SQL queries.

Ideally SQL is always abstracted:

1. Easier for developers to work with Symphony.
2. Protection against having something totally unexpected going on.
3. Would possibly allow to switch DB engines without many custom changes being required as the driver would take care of the required changes.

@iwyg the CMF concept is indeed explained quite neatly... however we must pay attention not to confuse the two..

[iwyg]

yep, but that's exactly why I keep thinking of symfony cmf when someone speaks about symphony cmf

[gkhalley]

I concur. Raw SQL is not necessary, but an ORM implementation or other. The structure of SQL is more to my point. Three things have led me from a simple table user (loosely comparable to creating spreadsheets) to a relational poweruser by understanding the following: 1) relationship by looking at many examples, 2) indexes (unique or otherwise), and 3) when to NOT use a relationship by just making an immutable 'value object'. The power of Symphony to a beginner comes from the ability to control the data, something that doesn't seem to be as easy to manipulate in other CMSs. My first point is that these understandings could be conveyed through admin interface if it was carefully thought out prior to creating API.

I don't agree that the existing backend data structures are more secure.

[nitriques]

This discussion is exactly why we need some BDFL... At least, maybe not for life, but benevolent dictators for sure.

[iwyg]

I want to be his hand. Hand of the BDFL… sounds good to me.

[designermonkey]

I tried. ;o)

I may try again soon. Still taking time out.

[nitriques]

@designermonkey Yes you tried, and it worked very well. But every dictator needs some rest. No stress.

[iwyg]

@designermonkey you know, I mean it :)

[allen]

Are you guys comfortable with trying out a collaboration method that we used to create Symphony 2?

If so, we need to split into two groups. One group tackles the information architecture, the other tackles the system architecture. We won't need any further sub groups like what we had in our post-2.0 working group model, that kind of structure requires full-time micro-management that we don't have the capacity to do.

The method is really basic but it outlines the areas of responsibility clearly.

The Information architecture group is responsible for everything that a user does to interact with the system.

The system architecture group is responsible for everything that the system has to do to make user's requests possible.

The information architecture group must come up with requirements and use cases, along with interface level designs. The group is not responsible and has no direct control over code level designs (API, syntax, object/classes, etc.) The IA group is however responsible for front-end code such as HTML, JS, CSS, etc.

The system architecture group must design a core system that adheres the requirements set by the IA group and is responsible for everything below the interface stack.

Both groups are encouraged to discuss and offer suggestions to other groups, but the groups themselves are responsible for making their final decision.

Group discussions should happen every day if possible, with preliminary decisions made as quickly as possible. I say preliminary because the decision could change in a week's time, but a preliminary decision has to be made quickly so that members of both groups are not stifled. It's always okay to revert the decision after trying out something and realising it's not going to work. It's always better to know for sure what works and doesn't than to be faced with decisions and not know which to take.

Just to give you a little background, Scott was the IA and Alistair was the SA. I was mostly there to make sure the arguments didn't end up in a back-ally knife fight. As cool as that would've been to witness.

[allen]

So if you all agree to try out this approach, then let me know which group you want to be in. For starters, I think 3 members in each group would work well.

I am more than happy to be the "answer guy". By that I mean, I will give you my iMessage/mobile number and if there is a preliminary decision that needs to be made ASAP, I will be there to make one. I can't be there to handle day-to-day management tasks, but answering questions on the spot, is something I can do.

[nitriques]

I would love to be part on the SA. I have a strong background in system design and architecture and I have a B. Eng in Software Dev.

[nitriques]

@allen you can PM me here or on twitter @nitriques

[iwyg]

@allen PM for sure. In case you're still interested, just drop me a PM.

[allen]

I will check in with @rowan-lewis tomorrow and see what he's up to. Including @brendo, I think we've got the SA group sorted. Who's up for IA?

[allen]

@nitriques + @iwyg: Cool stuff. I'll send out a message once we get some people on board the IA group.

[iwyg]

Great! Thanks @allen

[jonmifsud]

@allen would love to say I'd make the IA group but not sure my skills align as much as they would in SA.