silverleague / silverstripe-console Goto Github PK

When looking up an injector resolution the module name returned is that of the owner of the input class name, but it should probably be the result class name:

$ ssconsole object:lookup "SilverStripe\Security\BasicAuthMiddleware"
SilverStripe\Security\BasicAuthMiddleware resolves to CWP\Core\Control\CwpBasicAuthMiddleware
Module: silverstripe/framework

Expected: cwp/cwp-core
Actual: silverstripe/framework

Raised in #37

We need example documentation for all commands in the console.

Silverstripe framework will shortly (alpha.5) be merging in a rewritten Config API.

We will need to check and update our config: commands to conform.

"type": "silverstripe-module" causes it to be installed into /console - it should live in vendor/silverleague/console and have vendor/bin/ssconsole available.

The command object:lookup seems to fit more naturally under injector:lookup instead.

We could introduce this as a command alias initially to preserve backwards compatibility for the 1.x line.

Currently the commands are temporarily added in the Scaffold class.

It should load a YAML file and add them from that instead.

For example:

ssconsole dataobject:delete [ClassName] [ID or URL route]
# Specific: ssconsole dataobject:delete Page /path/to/my/bad/page

Are you sure you want to delete this object? [yes]
[ClassName] #[ID]/with route [URL route] deleted.

It's not a SilverStripe module, so there's no real need to follow the vendor/silverstripe-package convention.

Let's simplify this by making the repository URL, the readme title and the composer package name all silverleague/ssconsole.

SilverStripe 4.2.x-dev, latest dev-master for ssconsole

PHP Notice:  Undefined index: SERVER_PROTOCOL in /Users/robbieaverill/dev/releases/release-cwp_cwp-recipe-kitchen-sink-2.1.0-rc1/vendor/silverstripe/framework/src/Control/HTTPResponse.php on line 125
PHP Stack trace:
PHP   1. {main}() /Users/robbieaverill/.composer/vendor/silverleague/ssconsole/bin/ssconsole:0
PHP   2. SilverLeague\Console\Framework\Scaffold->__construct() /Users/robbieaverill/.composer/vendor/silverleague/ssconsole/bin/ssconsole:23
PHP   3. SilverLeague\Console\Framework\Scaffold->bootstrap() /Users/robbieaverill/.composer/vendor/silverleague/ssconsole/src/Framework/Scaffold.php:68
PHP   4. SilverLeague\Console\Framework\Bootstrap->initialize() /Users/robbieaverill/.composer/vendor/silverleague/ssconsole/src/Framework/Scaffold.php:161
PHP   5. SilverLeague\Console\Framework\Bootstrap->findSilverStripe() /Users/robbieaverill/.composer/vendor/silverleague/ssconsole/src/Framework/Bootstrap.php:23
PHP   6. SilverStripe\Control\HTTPApplication->handle() /Users/robbieaverill/.composer/vendor/silverleague/ssconsole/src/Framework/Bootstrap.php:60

Notice only, doesn't break functionality, but would be nice not to have it there.

As a developer I should be able to add my own commands for the console.

They may live in a user directory, e.g. ~/silverstripe-console/src or in a SilverStripe application folder, e.g. /var/www/silverstripe-console/src

Any configuration YAML files should be merged into the main configuration file before commands are loaded.

We could also search through all vendor/ folders for a ssconsole.yml file to be able to pick up multiple modules installed with composer.

The user directory configuration (e.g. ~/ssconsole.yml) should take priority over custom modules, which should be loaded on top of core commands.

I don't imagine any way initially of being able to modify the core ssconsole behaviour, although we could probably use symfony console events to provide some level of abstraction if we need to.

When using member:create we could present better error messages in some cases, for example when a member with the same email address already exists in the database.

Currently:

  [SilverStripe\ORM\ValidationException]                                                        
  Can't overwrite existing member #112 with identical identifier (Email = [email protected]))

Instead, we could $output->writeln('<error>A member with the email <info>' . $email . '</info> already exists!</error>'); or something similar

• cache:list: list all cache IDs as well as some information about them
• cache:dump: Dump the contents of everything in the cache, or by ID
• cache:flush: Clear the entire cache manifest
• cache:view: View the contents of specific cache entries by key This can be incorporated as an argument of cache:dump
• cache:remove Remove specific cache entries by key

I'm not sure that the ConfigManifest will actually let us do these:

• cache:enable: Enable the global cache (if disabled)
• cache:disable: Disable the global cache (if enabled)

ssconsole (version 0.1.0 and 0.2.0 equally; installed locally or globally) fails as shown in the transcript below (transcript was made with local installation). As shown, there is definitely a SilverStripe installation, because sake dev/build just ran successfully.

…
 * UserDefinedForm_EmailRecipient
 * UserDefinedForm_EmailRecipientCondition
 * SubmittedForm
 * SubmittedFormField
 * SubmittedFileField

 Database build completed!

╭─[email protected] ~/Project/docroot  ‹develop› 
╰─➤  vendor/bin/ssconsole dev:build --flush
A SilverStripe installation could not be found. Please run ssconsole from your SilverStripe root.
╭─[email protected] ~/Project/docroot  ‹develop› 
╰─➤  

The host system is FreeBSD 10.3-RELEASE-p4 amd64 running PHP 5.6.32 and mariadb Ver 15.1 Distrib 10.1.30-MariaDB.

If you're running this globally with Composer it's currently using symfony/console 3.x. SilverStripe 4.x uses symfony/console 4.x if you have Behat installed. For some reason parts of this API are autoloaded before the global console library, so you end up with this error when running ssconsole:

ERROR [Emergency]: Uncaught Error: Call to undefined method Symfony\Component\Console\Helper\QuestionHelper::getInputStream()
IN GET /
Line 911 in /Users/robbieaverill/.composer/vendor/symfony/console/Application.php

Source
======
  902:             $inputStream = null;
  903: 
  904:             if ($input instanceof StreamableInputInterface) {
  905:                 $inputStream = $input->getStream();
  906:             }
  907: 
  908:             // This check ensures that calling QuestionHelper::setInputStream() works
  909:             // To be removed in 4.0 (in the same time as QuestionHelper::setInputStream)
  910:             if (!$inputStream && $this->getHelperSet()->has('question')) {
* 911:                 $inputStream = $this->getHelperSet()->get('question')->getInputStream(false);
  912:             }
  913: 
  914:             if (!@posix_isatty($inputStream) && false === getenv('SHELL_INTERACTIVE')) {
  915:                 $input->setInteractive(false);
  916:             }
  917:         }

Trace
=====
Symfony\Component\Console\Application->configureIO(, Symfony\Component\Console\Output\ConsoleOutput)
Application.php:145

Symfony\Component\Console\Application->run()
Scaffold.php:82

SilverLeague\Console\Framework\Scaffold->run()
ssconsole:24

We should probably update to console 4.x. There may still be conflicts with other libraries (like silverstripe/cow) which require symfony/console 3.x, but they can deal with that.

A system:check command could perform a series of automated checks on your environment. This wouldn't necessarily replace things like the silverstripe/environmentcheck module, but more basic checks that would be required for SilverStripe to operate (NB: it's possible that the command itself may not run if that were the case):

• PHP version support
• php-intl installed
• dotenv is available
• Permissions across various folders (read everywhere, local write on assets)
• Database is reachable

cc @silverleague/console for feedback

To allow us to measure the coverage change over time as this module nears dev complete.

As per the title.

A bit like the SilverStripe Seeder, but better

If I literally extend Page, I'd like a way of showing all descendant classes of Page.

As a developer, if I want to quickly create a module I should:

• Enter the module name, e.g. "mymodule"
• Ask for the desired vendor/package namespace
• Have it create a shell composer.json including PSR-4 autoloading
• Have the console prompt me to choose any Objects to extend, and create empty Extensions classes and YAML configuration for each. This should repeat until no more are required.
• Have the console prompt me for any custom DataObjects to create, and whether they need an accompanying template
• Initialise a readme
• Create simple configuration unit tests to ensure that the extensions have been applied to the desired class

Multiple people have written their own implementation of a SilverStripe console.

I would much rather see a single implementation, than the current option of choosing a single one that almost does what is wanted.

@micmania and @axyr have their own implementations. It would be good to get the three options together and look at the pros and cons and take the best of each instead of keeping on trucking the way the current console implementations are all going their separate path of priority

Some of other packages uses symfony/console:^5.0.
Would love to see if this package can be installed along with other packages which uses symfony/console:^5.0.

For example: dataobject:dump [ClassName] [ID or URL route]

A pretty printed JSON object might be a nice output type.