Problem/Motivation

This is to decide what needs to be done for the 'dr' command to be considered stable instead of experimental.

The general idea is to have dr command so one can manage a 'normal' Drupal site' without drush. Task such as,

  • cache:rebuild
  • config:export
  • config:import
  • config:status
  • core:cron
  • core:status
  • pm:install
  • pm:uninstall
  • site:install
  • sql:drop
  • sql:query
  • updatedb
  • user:login
  • watchdog:show

Anything else?

Stable blockers

Install
#3594342: Update install command to allow installing using any database driver
#3594320: Allow `dr install` to install when database is already configured
Cache clear - Already in core
Config export #3594337: Add a command to export configuration
Config import #3594338: Add a command to import configuration
Extension install #3594334: Add a module and theme install command
Extension uninstall #3594335: Add a module and theme uninstall command
Database update #3594333: Add a database update command
Database update status #3594340: Add a command to display database update status

To be triaged

#3594336: Add a command to list modules and themes on a site
#3594339: Add a command to display configuration status
#3594342: Update install command to allow installing using any database driver
#3587722: Consider what `dr` CLI command should do if it cannot bootstrap Core
#3587723: Consider a specific logger channel for CLI commands
#3594184: CLI cannot discover commands in subdirectories that have a period in the name
#3606645: Add Laravel Prompts as a dependency for CLI app

Comments

quietone created an issue. See original summary.

quietone’s picture

Title: CLI entry point roadmap to stable » [meta] CLI entry point roadmap to stable
Issue summary: View changes
quietone’s picture

Issue summary: View changes
quietone’s picture

Issue summary: View changes
quietone’s picture

quietone’s picture

Issue summary: View changes
quietone’s picture

Issue summary: View changes

In committer slack Gábor and catch suggested, sql:drop

ressa’s picture

I pulled some stats from local machine and server with history | grep drush | cut -d' ' -f4- | cut -d' ' -f 1,2 | sort | uniq -c | sort -nr

The development and deployment commands are different of nature, since they are different scenarios, but these were the top Drush Drupal core commands:

  • drush cache:rebuild
  • drush config:status
  • drush config:import
  • drush config:export
  • drush core:cron
  • drush core:status
  • drush pm:install
  • drush pm:uninstall
  • drush sql:query
  • drush site:install
  • drush updatedb
  • drush user:login
  • drush watchdog:show

Changes in Issue Summary:

  • I have renamed the commands in the Issue Summary to match their full Drush command name, for less ambiguity.
  • I have ordered them alphabetically.
  • I have added these to the list, where sql:query is more or less the only way to unban an IP address or user id (Drush issue). I have never used sql:drop:
    • config:status
    • core:cron
    • sql:query
    • user:login
    • watchdog:show

The current list of 14 Drush commands are required for basic Drupal maintenance, I would think.

Slightly more niche commands, maybe to be included in a second round?

  • drush config:get
  • drush config:set
  • drush locale:import
  • drush migrate:import
  • drush migrate:rollback
  • drush migrate:status

PS. The spreadsheet is using system:cron and system:status, which should probably be core:cron and core:status.

mradcliffe’s picture

Component: other » CLI system

I updated the parent issue for command issues that are mentioned in the issue summary to this issue.