Comment by calibas | Hacker News Reader

Comment by calibas | Hacker News Reader

Parent Full thread

I've been told that after Drupal 8, they decided that mandatory nightmarish upgrades every few years was not a good idea and introduced much better backwards compatibility. They lost half the community during the D7 to D8 transition, many quit Drupal altogether or went with a D7 fork named Backdrop.

For the record, I've done D6 to D7 and D7 to D8 data migrations on fairly complex sites. I say "data migration" and not "upgrade" because you're effectively creating a new site, then migrating the data over. Essential modules in one Drupal version may not exist in the next, though I understand D8, 9 & 10 modules are near identical so upgrading is way easier.

There's another thing that really split the community, many want automatic security updates to Drupal core, but the Drupal core devs have taken a hard stance against this. Letting the site rewrite it's core files is seen as a major security risk, which I agree, but in my opinion that's outweighed by an even greater security risk. Every Drupal site needs an active dev to immediately perform security updates, but this isn't the case for half (or more) of Drupal sites and those sites get burned badly by the policy of forbidding automatic security updates. Drupal's adherence to "best security" has led to some absolute disasters (see Drupalgeddon parts 1, 2 & 3 where thousands and thousands of sites were hacked).

Regarding Drupal versus Wordpress comparisons. Drupal has been moving towards being a Content Management Framework that requires a knowledgeable PHP developer to build and maintain. If you want an easy way of creating a blog/website that practically runs itself and has thousands of plugins for just about any functionality you can imagine, you don't want Drupal, you want Wordpress.

> There's another thing that really split the community, many want automatic security updates to Drupal core, but the Drupal core devs have taken a hard stance against this.

That might have been true at some point, but certainly is not the case anymore. In fact, automatic updates is a "strategic initiative" for Drupal core:

https://www.drupal.org/about/core/strategic-initiatives/auto...

This still means there is no out of the box way to update Drupal core automatically _yet_, but you can in fact do so with a contributed project, developed and maintained by people that are contributing to the core initiative.

The upgrades from D8 to D9 to D10 are still somewhat of a pain because they do deprecate things and not all modules are compatible (let alone custom code).

Not to mention that upgrades have no tangible benefits for site admins. They lose features, and rarely any UX improvements.

To be fair, WordPress core does break things sometimes, but most plugins are very actively maintained, so it's just a few clicks and the upgrade is done. Every upgrade brings UX improvements (and not just Gutenberg, but things around user account security, for example).

I supported Drupal for 15 years, but that ship has sailed.

Agreed that is a bad stance from a security standpoint. Security updates will always be coming , users can not be relied on to always update so you get sites that will never be updated and eventually hacked and spam/ scan / redirect to malware and create a bad experience. On your average shared host drupal would be set to write to itself anyway since php will run under the same username of the files. I guess permissions could be set lower to 444 to prevent this - but the fact Wordpress will auto update the core is essentially to security.

I'm not very familiar with Wordpress, so don't know how auto-updates work in it. Does it really autoupdate the core remotely automatically, or it is a human who presses the update button?

The default is that is updates automatically.

It has a very unique "cron job", wherein pages effectively fork by doing a "curl wp-cron.php". One of those jobs is a daily check for updates, and it will apply one if it exists. I've had people argue that they want to disable they behaviour, and do manual qa before updates. I can see why. But the last person I argued this with had their website replaced with a gore image because they got behind in updates.

Thanks for explaining how it works.

Wordpress, as a development framework, sucks.

It really depends on what you know in WP. Want to use it for enterprises? Look into WordPress VIP or try to use https://roots.io (you can even use Laravel modules with it)

Whenever I read someone say "best" "sucks" - it makes me wonder how much research they've done.

Eh I think it’s fine. You work with it for enough years you will have accumulated enough code to quickly bang out new projects. But yeah if you don’t bring your own toolbox it isn’t great.

Reply on news.ycombinator.com