Contrib.social

Create a FrankenPHP-based launcher so that people who don't have DDEV can run Drupal CMS locally

Open on Drupal.org →
Created on 24 September 2024, 4 months ago

Problem/Motivation

Let me preface this by saying that, although the call is not ultimately mine to make, I'd call this a general release blocker.

This is also about people who will build real-world projects with Drupal CMS. In other words, this is directed at our consumers, not contributors. So we're talking about things in the project_template directory.

For end users who are developers, Drupal CMS is already well-set up. Our platform of choice is DDEV, and we have good integration with it. As of ✨ The project template's quick-start commands should drop you into the installer Active , you can simply run ddev launch in a Drupal CMS project and it will spin up smoothly.

However, DDEV is not a suitable runtime for everyone. Its setup process can be somewhat complicated and requires a Docker provider, which adds to the intimidation factor. Even if our hypothetical consumer is comfortable with the command line, they might not have the permission to install things like Docker and DDEV on their system (a work laptop, for example).

We need to lower the bar and make it possible to run Drupal CMS even if you have nothing else installed. No Composer, no PHP, and no familiarity or comfort with the command line.

Proposed resolution

There is work afoot in core to make Drupal compatible with persistent app servers, and eventually make those the recommended way to deploy Drupal to production: #2218651: [meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole → .

FrankenPHP, in particular, is interesting because they supply stand-alone binaries for macOS and Linux, meaning you can run Drupal without installing anything else. There is an issue to add better integration with FrankenPHP: 📌 Add Caddyfile configuration Needs review .

I propose that we add that patch to Drupal CMS, and create a new Launch Drupal CMS.command shell script in the project template. Because it has the .command extension, this script will be double-clickable from Finder (and possibly also in Linux too, since it will have the chmod execute bit). When run, it will download the appropriate version of FrankenPHP and start it up, serving Drupal CMS.

✨ Feature request
Status

Active

Component

Infrastructure

Created by

🇺🇸United States phenaproxima Massachusetts

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @phenaproxima
  • Comment 4 months ago →
    🇺🇸United States phenaproxima Massachusetts
  • Pipeline finished with Canceled
    4 months ago
    Total: 574s
    #291686
  • Merge request !102Resolve #3476543 "Launcher" → (Closed) created by phenaproxima
  • Pipeline finished with Canceled
    4 months ago
    Total: 598s
    #291691
  • Pipeline finished with Success
    4 months ago
    Total: 713s
    #291697
  • Pipeline finished with Success
    4 months ago
    Total: 574s
    #291724
  • Pipeline finished with Success
    4 months ago
    Total: 392s
    #291735
  • Comment 4 months ago →
    🇺🇸United States phenaproxima Massachusetts

    Well, that worked a treat. Here's how to test.

    If you download and unzip the drupal-cms.zip archive created by the "build project" CI job (https://git.drupalcode.org/project/drupal_cms/-/jobs/2846314), you'll see a "Launch Drupal CMS.command" file. Double-click that -- I've only tested on macOS -- and it should open a terminal session that downloads FrankenPHP and kicks you into the installer.

    The caveats are that, for now, the first couple of times will be rocky because the downloaded files will be quarantined by the system, so you'll need to go into the system preferences to allow them to run. Maddening.

    But once you've done that, it works great. There's probably a way to lift a file from quarantine at the command line but I don't yet know what that way would be.

  • Pipeline finished with Success
    4 months ago
    Total: 587s
    #291739
  • Pipeline finished with Success
    4 months ago
    Total: 739s
    #291746
  • Pipeline finished with Canceled
    4 months ago
    Total: 325s
    #291812
  • Pipeline finished with Success
    4 months ago
    #291814
  • Pipeline finished with Canceled
    4 months ago
    Total: 476s
    #291828
  • Pipeline finished with Success
    4 months ago
    #291833
  • Pipeline finished with Success
    4 months ago
    Total: 590s
    #291881
  • Comment 4 months ago →
    🇺🇸United States phenaproxima Massachusetts

    Okay, I'm happy now -- although I've only tested on macOS, this launcher works really well and is friendly.

    You do have to take it out of quarantine, but once you do, it only downloads what it needs to download once (FrankenPHP and Composer), and gets everything launched so you can visit the installer -- which works all the way through.

    I still need to manually test it on Linux (Ubuntu). If it works as well in Linux as it does on macOS, I think this can be merged. But I'd like someone else to look it over and manually test it as well first.

  • Comment 4 months ago →
    🇸🇪Sweden johnwebdev

    What about Windows which is arguably the hardest to setup Docker in,

  • Comment 4 months ago →
    🇺🇸United States phenaproxima Massachusetts

    Windows is a bit of a tough nut to crack. I'm hoping that this launcher works in WSL with minimal (if any) changes, since according to my cursory research, WSL will run Linux binaries without any recompilation.

    Obviously this means we'd need people to enable WSL, but I'm guessing that's not too much more of a lift than asking someone to install Laravel Herd (which also looks pretty nice).

  • Comment 4 months ago →
    🇺🇸United States phenaproxima Massachusetts

    After some discussion with @tim.plunkett and @effulgentsia, I've decided to close this out without merging, leaving it as a proof of concept.

    What I've concluded from this adventure is that a non-Docker runtime is necessary for Drupal CMS to be broadly adopted, but trying to roll our own is going to be painful. There are already great solutions out there, so I think we should analyze our choices, adopt one, and go with that.

    The discussion continues in 📌 [policy] Adopt an officially supported non-Docker runtime Active .

  • Comment 4 months ago →
    System Message
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024