Drupal kinda merging with Symfony / a new Drupal Fork

what do you think? will you stay with the fork?

[explorador]

Hi, been using diff CMS and also developing a few on my own (perl based). About Open Source, I've been using Drupal a lot and quite happy with it. There is always transition challenges, some didn't like the 6 to 7 jump and I agree, still I adapted and took on Drupal 7.

But now they are changing most of the code like making a new CMS (almost) and they are mixing a lot of Drupal with Symfony. Worried? perhaps we should. I've taken a look at it and didn't like it. Share your opinions Drupal Users.

[explorador]

Oh and yes, the community created a fork to keep the benefits of Drupal 7 alive.

[ergophobe]

I think this is a make or break release for Drupal. Will it be Windows Millenium or Windows XP? Time will tell.

I have one live site running on Drupal 8 and in general I like it. There are many changes, but from the perspective of themers and even to some degree module developers, things like the Form API, Schema API are mostly the same AFAIK.

That said, there is great fear that it is reaching a level of complexity with Symfony and a move to full OOP that willl leave a lot of hobbyist programmers behind. The big money behind Drupal really only has interest in enterprise solutions, but so many traditional Drupal users do not have enterprise needs or budgets.

So this is the motivation behind the fork. Several really committed core developers have cycled out either because they disagree with the new direction or because they simply don't understand it and feel they can no longer contribute.

At the same time, the way Drupal is now is a major hassle. A given variable might be an array or an object depending on context. It makes it harder to extend and maintain.

As for the fork, though, the big question is what happens with all the contrib modules. Most module developers will probably upgrade for D8 rather than port to Backdrop, but that reminds to be seen. If Backdrop doesn't get a nice base of key modules, it will die. But then, the same could be true of Drupal in general.

[explorador]

Thank you Ergo for your comments, very interesting.

I'm looking forward on playing with the new Drupal 8 but so far it worries me, I've been playing around with Symfony and I don't like it, and yes I know about programming etc. I just don't see the love in there. Anyway I understand it's shocking to jump from one thing to the otherin no time.

The Fork sounds interesting. What worries me is developing a serious website for a corporation in Drupal (something I already did), and then finding you have to update it to keep it safe but suddenly finding that it's not even the same code.

There are clients that stay with us so it's understandable being able or responsible for the code, but clients who were "just a one time client" asking for a solution to stay on their servers? suddenly all that worked needs rewriting? because there are no updates to the core? and suddenly the core it's not compatible? that sucks, it opens a lot of space for confusion between an old client and the developer who shouldn't need to take care of that code anymore.

[ergophobe]

suddenly finding that it's not even the same code

I'm not sure I follow. What do you mean? No matter how you cut it, if you're on Drupal 6, it will see EOL in a year or so. So you'll be on a new code base if you need to update it.

If you're on Drupal 7, you won't need a major version upgrade for 3-5 years. So you can sit tight.

It has always been a fundamental principle with Drupal that major versions can and will break core APIs. So the shift to Symfony and the fork don't change any of that. Major version Drupal upgrades are painful and always have been. I've done upgrades from 4->5, 4->6, 5->6 and 6->7 and they have all sucked. The one plus these days are better data import tools. It's generally felt in the Drupal community that with a complex site, it's easiest to skip every other version (so you're on an even or odd version track) and every 6-8 years you build the site over and then import the data.

I think one of the goals of the Backdrop fork is to get out of that paradigm, but it does have its advantages - namely you don't have the Microsoft problem of supporting stuff you built 12 years ago.

[explorador]

Ergophobe, well my experience with Symfony wasn't too pleasant (still in that same spot) so Drupal going with SF sounds intimidating to me, specially thinking about some big projects on a big company IF they have a problem updating and call me to fix it... yes Drupal has b
een breaking the code compatibility, at times even that we stay with the brand and import the data, it's almost like migrating to a diff CMS, that's what I meant to some extent but yes you are right on your lines, more clear on that now.

I wonder what's been the experience of the average Drupal users going on for years without updates, just curious. First thing I think of is security risks, affordable? I guess I'm dreaming too much of installing once and leaving it running.

[ergophobe]

Understood... and agreed. I've been playing with Drupal 8 and just tracking down an error message through the maze of Symfony and PSR0 routing is daunting. I tried to submit a 4-byte unicode patch and eventually my head hurt (and as it stand now, there's no patch in Drupal core for it).

The big issue with leaving it running is if anyone has an Ubercart install - as soon as EOL for D6 is declared, your Ubercart install fails PCI Compliance requirements because it is no longer being patched for exploits. If you're running a vanilla site, D6 is fine, but more and more I'm finding that a lot of responsive design components (say Flexslider or Bootstrap or Zurb or whatever) that you might want to use are off the table with D6 unless you use JQMulti which lets you run more modern JQuery, but it's complicated

One way or the other, I think most D6 users are going to be looking to upgrade in the next couple of years. The question is what will they upgrade to?

[Kendo]

What worries me is developing a serious website for a corporation in Drupal and then finding you have to update it to keep it safe but suddenly finding that it's not even the same code.

This is always on the cards and it doesn't matter which CMS you use.

If you use a custom theme you are likely to find that it's not updated for the new version due to imcompatibility. Even if using a default theme, any modifications that you make at all can pose probelms if the CMS is changed radically and the worse case scenario is not being update to the new version of CMS due to the server not using the latest version of PHP or SQL.

We have been developing modules for use with all of the popular CMS and I can tell that it is most annoying to have to provide a different module for each different version and a nuisance having to provide a new one every time they change something.