Symphony.

As many of you know, our plan has been not to pursue any significant updates to the Symphony 2 codebase post-2.1. In fact, we said as much just a few weeks ago. In the meantime, however, we’ve come across a couple of fairly compelling reasons to change our minds:

1. The Frontend Membership extension

As we push to get this extension finalized and released, we’ve realized that it makes sense to remove the dependancy between Frontend Membership and the SMTP Email Library.

So we’re working on a system-wide mailer abstraction, which will enable extensions to add support for different mail sending protocols, like PECL’s SMTP library, or an online service like Postmark. Symphony will fallback to PHP’s native sendmail function as it currently does now, but having an abstracted mailer will allow the Frontend Membership extension to hook into whichever mailer the developer chooses.

Frontend Membership will be released soon after 2.2, and will roll all the different versions of membership extensions we know of into one officially-supported and polished version.

2. Addition of new delegates

We want developers to continue extending Symphony 2 and making it more and more bad-ass. Since there’s not likely to be a Symphony 2.3, we wanted to take one last chance to add some of the most oft-requested delegates that are currently missing in the core.

To that end, we’re calling on you to let us know what delegates should be added to the v2 codebase. Bear in mind, we don’t want to litter the system with delegates. We want to look at adding a handful of important, well-placed delegates that will enable extension developers to build things they couldn’t build before.

Brendan and his crew in the Core working group will assess all the delegate suggestions made in this thread and determine which ones will be added to 2.2.

Timeline

We will be working on v2.2 straight after a 2.1.1 bugfix build is released, hopefully later this week.

Sounds very good to me.

It would be great if the mailer abstraction and the fallback (PHP sendmail) mailer would allow to set dedicated values for every standard email header, especially:

• from_name
• from_email
• reply_to_name
• reply_to_email

as it has been discussed here: http://getsymphony.com/discuss/issues/view/355/

Ideally one could set the following email headers (e.g. as hidden fields in a form submission):

• From (name + email address)
• To (name + email address)
• Subject
• Cc
• Bcc
• Reply-To (name + email address)
• Return-path (email address)

The rest of the headers will probably be set by the mailer, e.g.:

• Date
• Message-ID

I am not sure about the implementation of Content-Type, however. How should we generally deal with multipart emails (TEXT/HTML/attachments)?

one thing with setting the from header as a hidden field is that someone could potentially run a script to modify that form field and send unsolicited emails from some random email address.

Yes, that’s why Symphony generally uses member names for that (which is not much more secure, actually). I guess this problem may be solved by Symphony 3’s ability to overwrite values in events.

I’m excited about the members extension. I have like 4 different project websites using Members that I work on every once in awhile that I’d love to bring to completion.

Concerning the delegates, I think there should be a consistent concept:

• Either we need two main pre and post page generation delegates that pass there full context to the attached functions (e. g. Blueprints, Sections, Articles, edit, id)
• or we need a more fine grained system of delegates that are fired for each backend page when creating, editing or deleting things (e. g. one delegate each for creating, editing and deleting sections, pages, data sources …).

In both concepts it’s important that if I can do something I should be able to undo it as well. So if there is a create or edit delegate there should also be a delete delegate.

As far as I see the current system is a colorful mixture of both concepts. This means that in the process of preparing Symphony 2.2, we should remove unneeded delegates, too. And we should remove the uncommented delegates in the source as well. This means that some extensions need to be adjusted but this is just fine as 2.2 more than a bug fix release.

By the way how do we name releases in the Symphony context? Is it major.minor.maintenance? So that Symphony 3 is a major, 2.2 a minor and 2.0.7 a maintenance release?

Symphony Date Handling

A few months ago I wrote:

I mentioned this idea months ago in a thread but can’t find it anymore: it would be nice if Symphony either completely replaces the current use of the date() function with strftime() or at least uses the latter for the backend display of dates. This way the backend would be completely translatable.

The handling of date formats is the last prominent thing missing for a fully localised interface so if we’ll have another version in the Symphony 2 branch this would be my feature request. If the core team thinks that a switch to strftime() touches too many areas of the system, it would be best to introduce a localisizeDate() and a standardizeDate() function which would just convert English month names to local ones and vice versa.

In addition to that it would be great if the installer would learn a few more date formats beside these:

$dateFormats = array(           
    array('Y/m/d', $dateformat == 'Y/m/d', DateTimeObj::get('Y/m/d')),
    array('m/d/Y', $dateformat == 'm/d/Y', DateTimeObj::get('m/d/Y')),
    array('m/d/y', $dateformat == 'm/d/y', DateTimeObj::get('m/d/y')),
    array('d F Y', $dateformat == 'd F Y', DateTimeObj::get('d F Y')),
);

In Germany for example we use to have these date notations and I guess there are many more in other countries:

• 15. August 2010
• 15.8.2010 or 15.8.10

By the way how do we name releases in the Symphony context? Is it major.minor.maintenance? So that Symphony 3 is a major, 2.2 a minor and 2.0.7 a maintenance release?

I’m getting quite confused with this myself. I.e. I’ve been waiting for a maintenance release of 2.1.1 to fix the logout issues and file upload issues so I can go on to use 2.1 as I won’t use it with these issues intact, yet we’re being told it won’t be available until the next release, and being told that is 2.2

I’m not a Git-ter and only ever use downloads, so I now have to wait. Any chance we can get this release versioning sorted now?

John, Craig mentioned at the end of his first post that there will be a maintenance release:

We will be working on v2.2 straight after a 2.1.1 bugfix build is released, hopefully later this week.

It would be good to have some kind of timeline accessible on this site showing what’s next.

Speaking of major.minor.maintenance the following seems to apply:

• major releases may break compatibility, they introduce new features, new interfaces, new concepts etc.
• minor releases are compatible with older releases, they introduce new features but don’t break the known concepts and interfaces.
• maintenance releases are for bug fixes only.

While major releases may take years, minor releases are available every few months and maintenance releases are pushed as quick as possible after the bugs are discovered (based on their severeness and the number of other bugs that need to be solved simultaneously).

Is this a general consensus?

John, Craig mentioned at the end of his first post that there will be a maintenance release:

I need to learn to read!

It would be good to have some kind of timeline accessible on this site showing what’s next.

+1

Given that Symphony 2.2 won’t be just a bugfix release, it’d be great to have distinct pages in the backend to manage datasources, utilities and events, just like it happens in Symphony 3. It can be achieved with an extension (like Rowan’s Datasource index), but I think it better fits as a core feature. What do you think?

Given that Symphony 2.2 won’t be just a bugfix release, it’d be great to have distinct pages in the backend to manage datasources, utilities and events, just like it happens in Symphony 3. It can be achieved with an extension (like Rowan’s Datasource index), but I think it better fits as a core feature. What do you think?

This is a very rough extension that shows what I had in mind

A nice additional feature would be the escaping of Data Source Filter operators. This way the full potential of regexp filters and the strtotime functionality in date fields would be available. Motivated by those two discussions/comments.

One more thing: there happen to be two extensions here implementing the same collapse-expand effect on field boxes in the section editor. This topic was discussed two and a half years ago but the feature never went official. Is it possible to have it in Symphony 2.2?

I would rather see the team devoting more of its time to 3.0.0 than adding new stuff to 2.2. But I don’t depend on Symphony for a living.

If it can be done with an extension then I don’t think it should be added into the core. Additional “features” in 2.2 for me should be hooks that allow for greater extensibility by extensions:

• consolidated delegates
• more hooks in the backend (JS and DOM)
• various things regarding localisation (above)
• improving the email sending bits

Since this is likely to very almost be the final update to S2 I would line to see code commenting of the core. Since the core isn’t going to be changing much in the future it makes sense to use this as an opportunity to finally document the code (I’m talking about the *Manager classes mostly) to allow for an element of automated Class API documentation.

It’s not a small job, mind, so could be added as a 2.2.1 release that doesn’t change anything but adds PHPDoc comments. This could be a full community effort if the tasks are assigned to people.

Everything Nick mentioned is spot-on.

With regard to code commenting, I think it’s certainly a task too big for the Symphony team to undertake as our focus moves on to version 3. We will almost certainly require the aid of the community to help us document the code.

I put forward a suggestion to the Core, JS and Documentation working group members to discuss a good documenting strategy (is PHPDoc the way to go? If not, what are the alternatives?). Once we get a recommendation from the working group, we’ll provide instructions to the community at large to help with this effort.