Symphony.

@iwyg

Problem is always that we just end up in endless discussions about how things should be done, and then the scope of a change becomes larger and larger.

Last time we discussed database, I proposed something similar to what Brendan is implementing right now (PDO), then everyone else chipped in and we ended up planning much bigger changes that never got beyond a first draft (Huib started working on something, if I remember correctly).

While in general I share the opinions of the people involved, let's just do smaller steps here and actually get shit done over time.

we ended up planning much bigger changes that never got beyond a first draft

Very true. It turns out it's not very easy to make big changes like this to Symphony. What tends to happen is that when working on feature A, you need a working implementation of features B,C and D. Then for each of these features the same happens, resulting in a lot of very interesting, but never completed, drafts.

For instance, with the DB stuff I wanted to have it unit-tested, because starting "low" is much easier than starting at the top, and I felt (and still feel) automated tests would make Symphony a whole lot better. However, there is no dependency injection in Symphony yet, which makes testing hard, so I'd have to write that, too. Which then requires a rewrite of... You get the point.

So, yes, maybe starting small is a good idea.

Just to sidetrack this discussion back to the design of the backend, the talk above between @brockpetrie and @Nils prompted me to finally post a little redesign of the Symphony backend I've been working on.

It's a proof-of-concept so the code is ugly and doesn't use many current Symphony standards, but hopefully it can add something to this discussion and any feedback from the community would be invaluable.

The post is here.

@creativedutchman, @jensscherbl. Yea, truly frustrating.

@creativedutchman, @jensscherbl. Yea, truly frustrating.

I agree. The more I work with Symphony in larger projects, the more I wish it was modular so I could rope in different parts of the framework at certain times. Unfortunately when Symphony was conceived this wasn't thought of too much, so we're in an uphill battle to retrofit the framework to do. We are all perfectionists and that's what makes Symphony great, but at times it also hinders our progress.

I believe that Symphony Next is the only way this can be done, and while I'd like to take full charge on that I'm unfortunately time poor. At the moment I work full time, am a director of a startup, freelance, have an Android side project and contribute to Symphony. Symphony Next is a serious rewrite and at the present minute, I can't commit to working on it (as much as I'd love to!). I fully believe the direction is to use Laravel components, regardless of how good or bad they are, just because of the size of community that can suddenly help contribute.

All that aside, Symphony 2.4 is a step in the right direction. Trying to abstract some of the core stuff out to make it more extensible and support more modern environments and higher load sites. It's easy to focus on what we do poorly, but we also do a hell of a lot right :)

I fully believe the direction is to use Laravel components, regardless of how good or bad they are, just because of the size of community that can suddenly help contribute.

Problem with Laravel at the moment is that the illuminate components are not really as modular and exchangeable as advertised. Each component requires another component which requires another component and so on. Use one illuminate component and it's pulling in the entire framework (along with lots of stuff that is only useful in the context of the framework, like facades and service providers).

Good news is, other people in the php community are well aware of this and pushing hard to improve this.

Aside from the other discussions, the 2.4 beta 1 seems to behaving quite well in my local environment, has anyone noticed any odd bugs while toying around with this branch?

@brendo, only styling issues on DS Editor but no major boo boos have come to light from testing further.. exciting times! Admin URL changes working great. Is there any need for notes to Devs of what constants to use when putting extensions together that reference the core/maybe affected by the admin URL change?

Will there be a beta 2?

Yeah @juro, there will be!

@moonoo2, can you log those issues on Github please? And yes, there is a migration guide that details all the changes in this release :)

A second beta has been released of the upcoming Symphony 2.4 build.

This release includes:

• #1615: Change the FrontendOutputPreGenerate delegate to use XMLElement for the XML parameter instead of a string.
• #901: Better support for ATAG 2.0 and WCAG 2.0 guidelines (please, if you use assistive technologies let us know how we are going and how we can improve!)
• Two new helper functions to XMLElement, convertFromXMLString and convertFromDOMDocument which are going to make developer's lives much easier
• Update to jQuery 2.1
• Improvements and bug fixes for when the URL is not /symphony

The next beta will likely include better caching support (#1046) and then we'll probably start to wrap things up and get this release out the door. If you'd like to contribute, this is our hitlist for Symphony 2.4.

• #1420 Adding a new setting to the Date field might be an nice introductory task for someone looking to get into extension development
• #1874 If you have experience in CSRF, we could use your expertise :)
• #1348 If you'd like a challenge, you could help untangle our web of parameter handling
• #1801 Would you like to improve the Forgot Password experience, the Login page logic needs a bit of enhancement to get it across the line
• #1642 If you'd like to help John with some interesting logic, the Redirect to 404 on Datasources isn't working in all scenarios

As always, if you find anything quirky or wrong, please log it on Github

If you set an admin path other than symphony on installation, is editing config.php's admin-path all that's required to change it back?

Also, where is a good place to read up on how custom admin paths are handled? I'm testing with Hiawatha (doesn't use .htaccess), and I think that after installation the 'take me to the admin area' button resulted in a 404. Subsequent requests for /symphony and /custom-admin-path work, though.

Hi David,

If you set an admin path other than symphony on installation, is editing config.php's admin-path all that's required to change it back?

Yes, changing the admin path in config is all that's required after installation.

There has been an absolute flurry of activity on Github in the last week, expect a third (and likely final beta) in the next week, with a launch in April (Happy Easter?!)

Big thanks to everyone who has chipped in, it's been a great call to arms. Special thanks to @nilshoerrmann for his colossal effort!

If there's any of you who uses (or wants to use) interationalized domain names in a project, can you please give my branch for improved idn support a try and report back if there are any issues? Thanks.

Update This has already been pulled in.

Just a note, we're rolling the Publish Filtering extension into the core.

Also, any extension devs out there, please check your extensions against the integration branch ASAP, as we're close to a release.

Thanks.

Yeah, as John said, there has been a surge of activity on Github for the last fortnight and we're rapidly approaching a final beta! Super thanks to everybody, this release kicks ass and I'm sure there is going to be a lot of excited people once it's live :)

A 2.4 beta 3 will be released, if anyone would like to test this.

It will be released on Thursday, barring any major issues. I doubt there will be any as many of us are using it and developing with it.

Hats off to all involved, especially Nils H for all his effort.

When do you guys except Symphony 2.4 to land in final release? Is Easter still the goal?

It will be released on Thursday