• 0 Posts
  • 6 Comments
Joined 2 years ago
cake
Cake day: October 27th, 2023

help-circle
  • @gramie@lemmy.ca

    @pirat@lemmy.ml @stopforgettingit@lemmy.dbzer0.com

    I think the new Drupal CMS install profile + Recipes via the Project Browser makes Drupal MUCH easier to maintain than WP for anyone already familar with Composer or other package managers like npm, gem, homebrew, etc

    The idea that most WP sites (that aren’t hosted by WP.com) are still maintained by downloading the plugin files from WP.org and then uploading the files to the site blows my mind.



  • @KazuyaDarklight@lemmy.world

    @ozoned@piefed.social

    If you are going to evaluate Drupal in 2025, I STRONGLY encourage you to start with the Drupal CMS install. There are so many optional modules with Drupal, it can be overwhelming.

    If you are already familiar with Docker, you can spin up a Drupal CMS instance using DDEV. You’ll have no problem Googling that.

    If you aren’t familiar with Docker and want to try it, https://new.drupal.org/drupal-cms/launcher is a ridiculously easy way to start on most operating systems. That approach gets a little trickier when you want to move the site/cms application instance to a host. There is documentation, but I would look it over before getting too far into this approach.

    My recommendation for spinning up a Drupal CMS instance is on a free sandbox on https://docs.pantheon.io/drupal-cms. Acquia offers a free trial in exchange for the information they need to target you with marketing, but it is only a 4 hour trial. Pantheon lets you keep your sandbox as long as you account remains active.

    Unfortunately ActivityPub isn’t included in any of the Drupal CMS Recipes (yet), so you have to add it with composer require 'drupal/activitypub:^1.0@alpha'.

    Composer is npm for PHP. If you are familiar npm, apt-get, homebrrw, pip, gem, etc, you’ll have no problem understanding Composer.


  • @Cris_Color@lemmy.world

    @abeorch@friendica.ginestes.es @pastermil@sh.itjust.works

    Many years ago I worked on a project with some FSF staff who refused to use non-FOSS solutions to coordinate or conduct meetings. While the developers involved where all prolific contributors to open source projects used by millions of people, they were all willing to compromise on some of the tools we use to develop and communicate for “the greater good”. The FSF staff weren’t willing to make those compromises. At the time I was frustrated by this. As Slack ownership changed, costs increased and policies around what they could do with “our” data evolved, I now have a lot more respect for the FSF staff who are “holding the line”.