Activators should be responsible for generating project commands

Created on 10 June 2024, 20 days ago
Updated 25 June 2024, 5 days ago

Problem/Motivation

Right now, project activation commands are generated by the source plugins, or by the UI. This is a problem because the frontend makes certain assumptions, which aren't necessarily valid, about whether the commands are applicable based on whether the project is downloaded, or activated.

Proposed resolution

The activators are the source of truth about the state of a project on the site. Therefore, they should also be responsible for generating truthful user-facing instructions about how to activate a project, given its current state on the site.

We should remove the $commands property from the Project object, and add a new getInstructions() method to ActivatorInterface which, given a Project object, can return one of three things:

  • A URL the user should be linked to when they click the "Install" button - for example, if Package Manager is disabled and the module is already in the codebase, this should send them to the /admin/modules page.
  • A translated set of instructions to be displayed in a pop-up modal.
  • NULL, to indicate that no instructions are available or necessary (for example, if the project is already installed).
πŸ“Œ Task
Status

Fixed

Version

2.0

Component

Code

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
  • Pipeline finished with Success
    20 days ago
    Total: 481s
    #195804
  • Pipeline finished with Failed
    20 days ago
    Total: 400s
    #195818
  • Pipeline finished with Canceled
    20 days ago
    Total: 254s
    #195819
  • Pipeline finished with Canceled
    20 days ago
    Total: 100s
    #195822
  • Pipeline finished with Failed
    20 days ago
    Total: 393s
    #195824
  • Pipeline finished with Failed
    20 days ago
    Total: 662s
    #195834
  • Pipeline finished with Failed
    20 days ago
    Total: 405s
    #195837
  • Pipeline finished with Failed
    20 days ago
    Total: 371s
    #195847
  • Pipeline finished with Failed
    20 days ago
    Total: 372s
    #195849
  • Pipeline finished with Success
    20 days ago
    Total: 739s
    #195860
  • Pipeline finished with Success
    20 days ago
    Total: 3067s
    #195870
  • Status changed to Needs review 20 days ago
  • πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts
  • πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts

    This is needed for recipes to be properly supported, so although it doesn't block ✨ Create a source plugin that exposes recipes in the file system Active , it is a Starshot blocker.

  • πŸ‡¦πŸ‡ΊAustralia sime Canberra

    Reading the code, the changes make perfect sense to me, and the ActivateInterface is intuitive when you trace that through to ModuleActivator it's good DX. Obviously this is a pretty important ticket for abstracting things out and make installing recipes possible.

    Big +1. Probably needs someone with longer experience with PB that me to RTBC.

    That would allow us to get rid of the text below that says what to do if you don't have Drush.

    Safe to keep it out of scope, but this is something that has niggled me for sure.

  • πŸ‡¦πŸ‡ΊAustralia sime Canberra

    Next positive reviewer, if no obvious issues, please RTBC to keep things rolling for the recipes work.

  • Pipeline finished with Success
    19 days ago
    Total: 383s
    #196461
  • Pipeline finished with Skipped
    19 days ago
    #196556
  • First commit to issue fork.
  • Status changed to Fixed 19 days ago
  • πŸ‡ΊπŸ‡ΈUnited States bnjmnm Ann Arbor, MI

    Happy to see this change!

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.69.0 2024