Symphony.

As long as you have command line access to PHP (probably not a problem for the kind of user Symphony is aimed at?)

Here in the forum I often read that people use Symphony on shared hosting, so I don't think so. On the contrary: I would assume that the majority of users has no command line access (or does not actively use the command line).

Good point. I suppose deployment to shared hosting without SSH access could still be done via FTP, but with the difference being that it would require a local dev installation which does have PHP available at the command line.

From the little I've read, it seems that Composer is the future of PHP dependency management?

Still I consider the requirement to use the command line a show-stopper for many newcomers.

@DavidOliver definitely. It's for php what's npm is for node or bundler for ruby. I don't say that it should be a requirement. Take git: using git with symphony is an option.

I began to say that maybe the top ten most popular extensions should be put together with the most recent version core into a zip, but I realized that members and emailtemplatemanager aren't in there. I agree with @michael-e. Don't make a show-stopper, make it simpler.

Edit: Simpler for the new user. Is this desirable to do with very little effort for the Symphony team? Aren't members and emailtemplatemanager within the most popular extensions and why isn't that reflected in the SymphonyExtensions.com?

(Edited to remove rambling in light of @iwyg's reply.)

@iwyg, so Composer would be one way of installing extensions, and not necessarily the way. Sounds good.

Does Symphony 2.3.2 drop support for PHP 5.2?

EDIT: Nah, sorry, at the release info page is written that 5.2 is supported.

hm? No, it's the last version to support 5.3.2, and it's about time

Yeah. Its only I ran across 5.2.17 with one ongoing server. Will see if they offer a more recent PHP version. Had an issue, but all is running fine for now.

php 5.2 is just a huge pain in the buttom

Completely in agreement with Composer and PSR compatibility. It's definitely the future of package management for PHP. Having Composer compatibility doesn't mean that it's either/or when it comes to installations.

As a side note, if users of Symphony are comfortable with XML and XSLT then JSON files will be a breeze. Think XML without all the brackets. :)

The 2.3.2 final was released on the 24th of March. Big thanks to everyone who contributed :)

I read in the 2.4 changelog that sections and pages are going to be cached in XML files. Maybe a stupid question, but why aren't they stored in filesystem in first place, instead of the database?

It just looks like Symphony stores simple structure related things in the DB in order to provide a admin GUI for the lazier users, whereas I would rather write those things quickly in PHP.

I am new to this CMS, so please tell me, do I have a wrong impression?

Yes, currently symphony stores these in Database; there has been a long discussion and it was agreed that this will be Migrated to XML, not cached.

Whilst you are fluent in PHP not everyone is; we would still like to keep things editable in the backend to make it simpler day-to-day for normal users. As in addition to developers there are also designers and other not-so-technical people which are trying to start out on a proper CMS.

Wouldn't it be better to store those things in JSON, considering advantages like lightning fast parsing by PHP and human readability?

Anyway, sounds pretty good. Any idea when is 2.4 it coming? I looked around on this forum and noticed someone mentioning March 2013, I guess those were old plans.

Not sure if you've grasped what this is all about... I would suggest you do some reading/research before...

Symphony has been advocating XML/XSLT standards; it is only fair that the config would be saved in XML to comply with all the other things rather then put up in a JSON file. I don't see why json is more readable then XML but I guess that's a preference.

As for 2.4 the date is currently up to discussion as discussions have started to take place on Symphony Next; which is planned to be a Major rewrite of Symphony. We're currently discussing as a community the way forward. And it could be the case that there might be a freeze on things being introduced on 2.4 and it would be the final version. However there's also a possibility that we opt to leave 2.3.x as the final stable version prior to moving to next. I don't think it has been decided as of yet. @Brendo might be able to shed more light.

Unfortunately (for some features), there will be no 2.4. There will be a release at 2.3.3 and then another for 2.3.4 which will apply some smaller already developed features, and wrap up some work with the datasource editor, which has been under discussion for quite some time.

This is all in an effort to move the main focus on to the Next project where we will get a lot of this stuff right from the ground up on a stable framework with no legacy code and gremlins hanging around.

The 2.3.x branch of the project will always be maintained and bug-fixed until the Next project is mature enough for a release.

@John so the all-new symphony relationship management will not be incorporated before symphony next?

That could be a secret, I'm not telling ;o)

For me this is the single most important thing Symphony is currently lacking (apart from a more powerful DS-editor), since most of my Symphony sites heavily rely on subsection manager.

Since when do we have secrets here! :D