4 ms·

Drupal is easy to criticize, but its handling of security issues and its code quality aren't the two places I'd start. They're actually two of the strengths of

by ksenzee 10y ago

Drupal is easy to criticize, but its handling of security issues and its code quality aren't the two places I'd start. They're actually two of the strengths of the project.

jacquesm 10y ago
You're missing a /s there.
- mschuster91 10y ago
  I've seen worse, way worse, than Drupal Core. That of course does not include Drupal modules - there is, similar to the Wordpress ecosystem, the really bad stuff.
  - jacquesm 10y ago
    But that's the whole problem right there. Such a plug-in architecture with every Tom, Dick & Jane writing modules that are loosely vetted and deployed in the 100's of thousands is broken by design. There is no way a small review team focused on security will be able to audit what 1000's of dedicated lesser gods produce. I can see the advantage of it, you just focus on the core and let the world take care of its own problems but you end up with nearly every site being critically dependent on a couple of obscure modules that will not get the attention they need until it is much too late. This coupled with Drupals nasty habit of obsoleting everything every couple of year (I hear they are changing now) and you're set up for disaster. So even if Drupal Core is not all that bad it is never just Drupal Core.
    - Gaelan 10y ago
      To get a module marked as "covered by the Drupal security team" it is required to go through a community code review.
      - jacquesm 10y ago
        Yes, but that's backwards. There are many many modules that don't have that stamp but that are distributed via the site and besides I strongly believe that security is not something you just vet for after the fact but that should go in to the design of your product. If you don't do that it becomes a 'find the last hole in the cheese' exercise and very likely there will be many holes that you don't find that way that would not have been there in the first place had the whole thing been designed from day one with that in mind. On the whole I think 'let amateurs build it and experts vet it' is better than just 'let amateurs build it' but it doesn't come close to 'let experts build it and experts vet it'.
      - lightlyused 10y ago
        Which is pretty easy to pass, you just have to follow the coding standards.
        Gaelan 10y ago
        And not have any (glaring) security flaws.
    - heywire 10y ago
      > But that's the whole problem right there. Such a plug-in architecture with every Tom, Dick & Jane writing modules that are loosely vetted and deployed in the 100's of thousands is broken by design. Wait, are you talking about npm or Drupal? (only kind of kidding)
      - devwastaken 10y ago
        That actually is a really good point about packages on NPM, or rather the culture of a 'package for everything.'. All it would take is somebody to lose their github account or go rogue, for one popular package that requires their package to also be compromised, and then hundreds to thousands of sites are silently vulnerable. Seriously. A standard ES6 JS project will run you to actual hundreds of packages. Thats a huge attack surface.
    - devwastaken 10y ago
      This I can agree with. The community frowns upon selling modules. This is reflected by the official repository offering no option of purchasing modules, no marketplace. Contributors only make money by being sponsored by hosting sites like Acquia, where usually they're making modules /for/ them. This of course makes Drupal unnattractive for more advanced functionality. But, single developers still try to create that functionality anyways, even if its something that needs constant work and usual updates. This then understandably falls to the way side because life. Some things just need business behind them, they can't survive on openness alone. Also: https://www.lullabot.com/articles/why-paid-drupal-modules-fail-drupal-as-art https://www.lullabot.com/articles/why-paid-drupal-modules-fa...
      - jpetso 10y ago
        Drupal is GPL, so a module written specifically for Drupal must always be redistributable under GPL as well since it's a derived work. That places a natural limit on the feasibility of module purchases, since anyone could buy it and then mirror it for free. The correct answer here is that if you don't like Drupal's free & community-focused development model, you're likely better off switching to some off-the-shelf software. Alternatively, you can pay a consulting company to maintain the module, which is how many of them get written anyway (and then given away for free). So if you focus on modules with commercial backing, you've got a pretty close approximation without giving up GPL freedoms.
      - ajsalminen 10y ago
        If you think going non-free with the modules would help you should take a look at the codebases of some of the most popular premium Wordpress modules. You'll find much worse than in a popular Drupal contrib module.

by ksenzee 10y ago

Drupal is easy to criticize, but its handling of security issues and its code quality aren't the two places I'd start. They're actually two of the strengths of the project.

jacquesm 10y ago

You're missing a /s there.

mschuster91 10y ago
I've seen worse, way worse, than Drupal Core. That of course does not include Drupal modules - there is, similar to the Wordpress ecosystem, the really bad stuff.
- jacquesm 10y ago
  But that's the whole problem right there. Such a plug-in architecture with every Tom, Dick & Jane writing modules that are loosely vetted and deployed in the 100's of thousands is broken by design. There is no way a small review team focused on security will be able to audit what 1000's of dedicated lesser gods produce. I can see the advantage of it, you just focus on the core and let the world take care of its own problems but you end up with nearly every site being critically dependent on a couple of obscure modules that will not get the attention they need until it is much too late. This coupled with Drupals nasty habit of obsoleting everything every couple of year (I hear they are changing now) and you're set up for disaster. So even if Drupal Core is not all that bad it is never just Drupal Core.
  - Gaelan 10y ago
    To get a module marked as "covered by the Drupal security team" it is required to go through a community code review.
    - jacquesm 10y ago
      Yes, but that's backwards. There are many many modules that don't have that stamp but that are distributed via the site and besides I strongly believe that security is not something you just vet for after the fact but that should go in to the design of your product. If you don't do that it becomes a 'find the last hole in the cheese' exercise and very likely there will be many holes that you don't find that way that would not have been there in the first place had the whole thing been designed from day one with that in mind. On the whole I think 'let amateurs build it and experts vet it' is better than just 'let amateurs build it' but it doesn't come close to 'let experts build it and experts vet it'.
    - lightlyused 10y ago
      Which is pretty easy to pass, you just have to follow the coding standards.
      - Gaelan 10y ago
        And not have any (glaring) security flaws.
  - heywire 10y ago
    > But that's the whole problem right there. Such a plug-in architecture with every Tom, Dick & Jane writing modules that are loosely vetted and deployed in the 100's of thousands is broken by design. Wait, are you talking about npm or Drupal? (only kind of kidding)
    - devwastaken 10y ago
      That actually is a really good point about packages on NPM, or rather the culture of a 'package for everything.'. All it would take is somebody to lose their github account or go rogue, for one popular package that requires their package to also be compromised, and then hundreds to thousands of sites are silently vulnerable. Seriously. A standard ES6 JS project will run you to actual hundreds of packages. Thats a huge attack surface.
  - devwastaken 10y ago
    This I can agree with. The community frowns upon selling modules. This is reflected by the official repository offering no option of purchasing modules, no marketplace. Contributors only make money by being sponsored by hosting sites like Acquia, where usually they're making modules /for/ them. This of course makes Drupal unnattractive for more advanced functionality. But, single developers still try to create that functionality anyways, even if its something that needs constant work and usual updates. This then understandably falls to the way side because life. Some things just need business behind them, they can't survive on openness alone. Also: https://www.lullabot.com/articles/why-paid-drupal-modules-fail-drupal-as-art https://www.lullabot.com/articles/why-paid-drupal-modules-fa...
    - jpetso 10y ago
      Drupal is GPL, so a module written specifically for Drupal must always be redistributable under GPL as well since it's a derived work. That places a natural limit on the feasibility of module purchases, since anyone could buy it and then mirror it for free. The correct answer here is that if you don't like Drupal's free & community-focused development model, you're likely better off switching to some off-the-shelf software. Alternatively, you can pay a consulting company to maintain the module, which is how many of them get written anyway (and then given away for free). So if you focus on modules with commercial backing, you've got a pretty close approximation without giving up GPL freedoms.
    - ajsalminen 10y ago
      If you think going non-free with the modules would help you should take a look at the codebases of some of the most popular premium Wordpress modules. You'll find much worse than in a popular Drupal contrib module.