We should include a Lando file for easier development.

Currently you can download modules, themes, etc., but there's no way to specify a specific version. We could add an option for that...

Despite the fact that the watchdog-show command help text says of the wip argument:

If not provided, a listing of most recent 10 messages will be displayed.

It only shows the 10 earliest commands, not the latest. I think we need to sort the data before printing...

I don't have one.
Somebody please help with bat file to make it work on windows machines. )

Currently, the core-status command displays the following information about a Backdrop site:

 Backdrop CMS
 Backdrop root
 Database driver
 Database host
 Database name
 Database username

Here's the equivalent info from a Drupal site with Drush:

Drupal version
Site URI
Database driver
Database hostname
Database username
Database name
Database
Drupal bootstrap
Drupal user
Default theme
Administration theme
PHP configuration
PHP OS
Drush script
Drush version
Drush temp directory
Drush configuration
Drush alias files
Install profile
Drupal root
Drupal Settings File
Site path
File directory path
Temporary file directory path

I think we can add a bit more info to b...

b accepts --root, --drupal, --debug and a few other options. These are not mentioned by b help.

Set condition to respect --root option for b dl command.

When running b cron I got the following error:

stat(): stat failed for /tmp/update-cache-38df50e0
	/app/www/core/includes/stream_wrappers.inc:836

The code in question is this:

// Suppress warnings if requested or if the file or directory does not
// exist. This is consistent with PHP's plain filesystem stream wrapper.
if ($flags & STREAM_URL_STAT_QUIET || !file_exists($path)) {
  return @stat($path);
}

In reading up on the @ symbol before the function call, I found this:

If you have set a custom error handler function with set_error_handler() then it will still get called, but this custom error handler can (and should) call error_reporting() which will return 0 when the call that triggered the error was preceded by an @.

(source: https://www.php.net/manual/en/language.operators.errorcontrol.php)

We do indeed set a custom error handler, which outputs error messages regardless. I think we should wrap the error output in a check to make sure error_reporting() is not '0' so that suppressed errors won't be shown.

Please add equivalent of drush pm-info (alias drush pmi) command to Backdrop Console.

There are a few issues with the formatting of the README file that should be fixed.

The pm-info command was added in #55 but still needs tests...

I thought it would be nice to have multiple callbacks per one command but then there is not clear behaviour when you do b en project_name

there are two callbacks:

• module.b.inc
• theme.b.inc

Each one check if there is module (theme) like project_name and if yes, it enables it.

But if there is no such a project, then there is no message about it.

It’s a result of not really clean architecture.

Have no clue yet which direction to go:

• allow only one handler by command name: then this handler will message 'no project like this'
• somehow detect if no one command reacted and write message 'something is wrong here'
• something else

Splitting to different modules sounds cool to me because we can have separated code to do:

• b en layout_name (—layout related options)
• b en module_name
• b en theme_name (—admin to set as admin —default to set as default)

Backdrop has layouts. They required different approach (enable mean attach layout template to layout)

If we choose to have only one handler per command, then we have to add:

• theme-enable (ten alias?)
• layout-template-enable (lten ?)

and then what to do with pm—list (pml)?
It does not make sense list modules, themes and layouts there then.

Also, I think about commands name. They should be similar to drush. To make migration process as easy as possible.

Guessing this was left over from before the name change...?

if there is an existing backdrop installation in the same directory as the command b dl backdrop is issued, then it tries to overwrite the existing install.

We should:

1. Check if there is already a directory called backdrop and inform the user.
2. Optionally allow the user to download to a sub directory like:
   • b dl backdrop --dir={my-backdrop}
     • where of course {my-backdrop} is replaced by the dir the user wants to use.

I had Views Slideshow and Views Slideshow: Cycle installed. Using b to disable Views Slideshow did not disable the Cycle plugin.

Disabling a module should also disable any modules that depend on it.

b_render() is looking for render structure returned by callback.

site_install_b_callback return TRUE and it get rendered as 1.

Need to be fixed.

Castle:b gor$ php b.php si --root="/www/bd1.2/" --db-url="mysql://root:@127.0.0.1/bd"
Installing Backdrop. This may take a moment...
 [o]   Backdrop installed successfully.

1

Will fix it when @serundeputy finish major cleanup to do not get into merge issues.

As per the title, it seems that the correct parameter should be langcode (see install_begin_request for example).

Also, the example given in the help text says 'en-GB', whereas everywhere else the default/example is 'en'...

I'm sorry, but I have to ask: is b_init_blobals() (in b.php) a typo or a joke?

I'm honestly not sure, since it could be a typo of b_init_globals() (since 'g' and 'b' are next to each other on the keyboard), or it could be a joke based on 'Globals' for 'Backdrop console'...

If a typo we should change it. If a joke, we should probably still change it... 😉

The README says: "Make b.php executable". I forgot this step and started using it, and it worked fine. So is this step actually necessary?

I ask because I'd like to contribute to this project, but changing the file permissions of b.php makes it show up in git as a change which I have to remember not to commit... 🙂

Or, is it possible to make it executable and then commit that to the repo, then it's one less step for people to do themselves, right?

In b.php if the database cannot be connected to (e.g. no valid settings.php file found), it displays this warning:

BackdropCMS is not installed yet.

This is particularly confusing in a multisite setup as Backdrop is installed, just elsewhere in the /sites/* directory.

We should either:

• Re-word this message to be more helpful
• Only display this message if debug is turned on

When using b pm-info on a core module like system or file the output produces errors:

gff ~/code/backdrop-ops/backdrop (1.x) 
└─ $ ∴ lando.dev b pm-info system
Undefined index: project
	/app/vendor/b/commands/PM/modules.b.inc:519
Undefined index: timestamp
	/app/vendor/b/commands/PM/modules.b.inc:535
date_timezone_set() expects parameter 1 to be DateTime, boolean given
	/app/core/includes/common.inc:2396
date_format() expects parameter 1 to be DateTimeInterface, boolean given
	/app/core/includes/common.inc:2418
 Name        : System                                                 
 Type        : module                                                 
 Project     :                                                        
 Description : Handles general site configuration for administrators. 
 Package     : System                                                 
 Version     : 1.15.x-dev                                             
 Date        :                                                        
 PHP         : 5.3.2                                                  
 Status      : enabled                                                
 Path        : core/modules/system                                    
 Files       : none                                                   
 Requires    : none                                                   
 Configure   : admin/config/system                                    
gff ~/code/backdrop-ops/backdrop (1.x) 
└─ $ ∴ lando.dev b pm-info file
Undefined index: project
	/app/vendor/b/commands/PM/modules.b.inc:519
Undefined index: timestamp
	/app/vendor/b/commands/PM/modules.b.inc:535
date_timezone_set() expects parameter 1 to be DateTime, boolean given
	/app/core/includes/common.inc:2396
date_format() expects parameter 1 to be DateTimeInterface, boolean given
	/app/core/includes/common.inc:2418
 Name        : File                       
 Type        : module                     
 Project     :                            
 Description : Defines a file field type. 
 Package     : Fields                     
 Version     : 1.15.x-dev                 
 Date        :                            
 PHP         : 5.3.2                      
 Status      : enabled                    
 Path        : core/modules/file          
 Files       : none                       
 Requires    : field                      
 Configure   : none 

We should fix that. There are some coding standards errors too that we should clean up, but we'll probably pick those up in #73

Hi @serundeputy!

Do you have any plans to continue or you abundant it in favour to drush ?

I want to move it forward.
Also I was thinking about name and 'console' looks more as purpose related.

What do you think ?

It appears that modules can implement their own b commands: https://github.com/backdrop-contrib/b/blob/1.x-1.x/includes/command.inc#L240

This should probably be documented in the README (under a new 'Developers' section).

Per Olafski's recommendation I'm copying the forum thread to the project's issues.

Starting to work with Backdrop Console, I find its command line shorthand b convenient, yet little bit odd and not so appealing. I believe making it slightly longer, but self-explanatory at first sight, would serve for the Backdrop community members' convenience. 

For example, b could become two the letter abbreviation of Backdrop Console bc, or three letter abbreviation bdc or, in Drupal Console's manner, the full word backdrop. But I do believe the most striking and appealing command would be just brush!

Despite some users might find the word brush used as a command-line tool little funny, its verb definitions suit to and are descriptive what Backdrop Console should also be about:

brush (verb)

1. remove (dust or dirt) by sweeping or scrubbing.

2. touch lightly and gently.

The brush command would also be easy to differentiate and switch for those who are coming with Drupal 7 background are used to drush.

Any thoughts on this?

Rename _enable_project() to _enable_module() in commands/PM/modules.b.inc to match corresponding function in themes.b.inc. And remove references to 'themes' in docblock.

Do the same for the _disable_project() function.

This is either a result of missing functionality, or incorrect documentation.

The watchdog command says:

Arguments:
wid : Optional id of a watchdog message to show in detail. If not provided, a listing of most recent 10 messages will be displayed. Alternatively if a string is provided, watchdog messages will be filtered by it.

However giving a string produces an error message. Indeed, the code has no check for a string value. So we should either write code to allow for strings to match the documentation, or just change the documentation.

We need tests!

When trying to download the search_krumo module b complains there is no release and offers to download git version instead:

docker@cli:/var/www/docroot/modules$ b dl search_krumo
There is no release for backdrop-contrib/search_krumo
Do you you want to download *git* version instead? (y/N): 

however as https://github.com/backdrop-contrib/search_krumo/releases shows there is in fact a release tagged as 1.x-1.0.0.

Have I done something wrong when creating that release per instructions on https://help.github.com/en/articles/creating-releases or it's b's issue? I did not upload binary files, but the instruction page says that field is optional.

Currently if the option --db-url is not provided b bails out with message that it is required.

If --db-url is not provided drop into interactive mode and prompt the user for the needed information to install backdrop.

Currently the following symbols are used in messages:

• o: status
• v: success
• !: warning
• x: error
• -: log

Most of these are ok, once you get used to them (and the colours certainly help too), but some aren't obvious to start with and can be confusing. E.g. I guess v is meant to be a check mark...?

In setting up tests for this project, I noticed that PHPUnit's TestDox output uses nice symbols in the command line. They have:

• ✔: passed
• ✘: error/failure
• ↩: skipped
• ☢: risky
• ∅: incomplete
• ⚠: warning
• ?: unknown

Those (the first two at least) are clear and un-ambiguous. I was thinking we could use the same/similar symbols for ours... Something like:

• ●: status
• ✔: success
• ❗: warning
• ✘: error
• ⚑: log

B has no way to say b --root /var/www/backdrop --url www.example.org to select sites/example.org/settings.php instead of /var/www/backdrop/settings.php.

After some time of silence here, we now have several options:

@jlfranklin's PR: #21
@indigoxela's PR: #35 Deprecated in favour of #37
@BWPanda's PR: #37

Currently, if you run b from one Backdrop installation but specify --root to point to another Backdrop installation, you'll get this message:

Current directory and --root don't match. Please change to a directory under --root or remove --root option.

We should re-word this message to be more understandable, or work out how to handle this situation better (e.g. require --url if --root is specified?).

On DreamHost, running b --root $HOME/example.tld cron blows up with Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/myaccount/bin/backdrop_console/includes/render.inc on line 285

Actual line number will vary by install.

Currently, a success message is displayed regardless of whether cron actually runs when using the b cron command. We should check the return status of backdrop_cron_run() and display a message appropriately.

When testing enabling, disabling and uninstalling a module repeatedly, I had an issue where the module wasn't being enabled, and there was no output from the command.

I tracked it down to the fact that the DB didn't have a record of the module, even though it existed in the file system (and the DB is where the code checks for modules to enable).

The watchdog-show command has a documented --extended option, but it doesn't work. There's no mention of 'extended' anywhere in the code other than the help text. We should therefore remove it.

Right now there is an active issue with looking for contrib b.inc files.

There is need to properly define stages of script and required level of backdrop_bootstrap for that.

I tried to download a module from within the modules directory and it didn't work:

docker@cli:/var/www/docroot/modules$ b dl devel
 [x]   Please change directory to BackdropCMS root or specify --root option. 
 [x]   Failed to detect destination directory.                               

However, doing the same from the root directory worked fine:

docker@cli:/var/www/docroot/modules$ cd ..
docker@cli:/var/www/docroot$ b dl devel
 [v]   devel downloaded to /var/www/docroot/modules/devel! 

We are all used to drush way of being able to download contributed Drupal modules from within any sub-directory under Drupal setup's main document root, so it would be nice to have the same convenience with Backdrop Console.

Output default username and password after using b si with defaults.

When you're in a Backdrop site and run b dl backdrop, what should happen?

Currently it downloads Backdrop inside itself. E.g.:

backdrop
  core
  files
  ...
core
files
...

I suggest preventing this and displaying a message saying that you can't download Backdrop within Backdrop. You should run b dl backdrop outside of an existing Backdrop installation, or use the --root option to specify the download location.

The download command (dl) has a root option: https://github.com/backdrop-contrib/b/blob/1.x-1.x/commands/PM/download.b.inc#L22

Considering the main b command has this option, does dl need it too? What's the purpose/benefit of declaring it twice?

Need to know as a PR I'm working on adds a url option to the main command, and I need to know whether to add it to dl too (though it seems to work without it...)

Since pm-list is a type-agnostic command (applies to modules, themes and layouts), then it shouldn't be in module.b.inc. We should move it to download.b.inc (where pm-download is also type-agnostic) and rename that file to pm.b.inc.

What I had in mind was something like the if($type == 'log' && !b_is_debug()) filter in includes/common.inc (around line 84) that would similarly filter out status, success and log messages.

The goal is to have the --quietoption either suppress all output (like drush) and note success or failure through the return value in $?, or they reduce the output, removing the progress and status messages, but leaving any warnings or errors. Some commands (mplayer, for example) support multiple levels of quiet, like multiple levels of -v for verbosity.

For example using b to trigger cron is a common use case. The current version of b will print out a success message if everything works, which when run through cron creates a lot of emails.

We should add a --quiet (-q) option that doesn't print out any of the success or log messages, just the errors and warnings. Perhaps two -q options could suppress the warnings, too.

I was having trouble getting the Site Install command to work properly, but don't want to hold myself up with it, so making this issue for future reference.

Need to make sure Site Install works (inc. all the arguments/options), and then write tests for it.

It'd be nice to have a login/password reset command (like Drush's uli) for those times where you run the automatic install but forget to note down the generated admin password 🙄

When running b updb on a site with pending contrib updates, it starts the update process but then sits there indefinitely with no errors or output.

I tracked this down to the updatedb_status() function where it has this line:

// Ensure system module's updates run first.
$start['system'] = array();

The fact that this is being set as an array is the problem, as other values of $start are integers of the first update to run.

We need to find another way to get System updates to run first. Maybe checking the $start array before return for system and moving it to the beginning...?

When downloading a module (or other project), it'd be nice to see where it was downloaded to. This is particularly useful with multisites.

Current output:

[v] webform downloaded!

Ideal output:

[v] webform downloaded to /modules!

Hello @jlfranklin

Thanks for all your great ideas and work in the b issue queue!
Would like to be a maintainer for b, that way you don't have to be blocked by Gor and I and as you introduce these features you can merge yourself?

If you don't have time or are not interested that is fine, but if you are I'd be happy to add you in and have you aboard the b project!

Let us know.

thanks,
~Geoff

Now that Travis CI checks the code against Backdrop's coding standards, we should fix the code to adhere to them 😄

There are lots of implementations of hook_b_command(), but no official documentation for it. We should create a b.api.php file and document hooks and their parameters there.