concretecms / console Goto Github PK

View Code? Open in Web Editor NEW

11.0 11.0 3.0 137 KB

A command line utility for working with Concrete CMS.

License: MIT License

PHP 99.53% Hack 0.46% Batchfile 0.01%

console's Introduction

Concrete Console

A command line utility for working with Concrete CMS.

Installation

As a PHAR file

The latest version of the console cli tool is available at the following address:

https://github.com/concrete5/console/releases/latest/download/concrete.phar

Installation on Posix Systems

You simply have to download it and make it executable:

curl -L -o /usr/local/bin/concrete https://github.com/concretecms/console/releases/latest/download/concrete.phar
chmod +x /usr/local/bin/concrete

Installation on Windows Systems

You can download the concrete.phar file in a directory listed in your PATH environment variable (for example: C:\Windows\System32), and create a concrete.bat file in the same directory with the following contents:

@php "%~dpn0.phar" %*

With composer

The concrete console cli tool can also be installed globally with composer

composer global require concretecms/console

If you haven't already, make sure to add the global composer bin directory to your PATH.

export PATH="$(composer global config bin-dir --absolute --quiet):$PATH"

Note: This command will update the PATH environment variable only for the current session. In order to make it persistent you can add the line

export PATH="$(composer global config bin-dir --absolute --quiet):$PATH"

To the $HOME/.profile file (for the current user only), or to /etc/profile (for any user)

Running Commands

You can run commands just like this

concrete info

Which should get you something like:

# Location
Path to instance: /path/to/my/project/public
# concrete5 Version
Installed - Yes
Core Version - 8.5.4
Version Installed - 8.5.4
Database Version - 20200609145307

If you want to run a command against a different site, or if you've installed the console utility globally, any command that operates against a particular Concrete instance also has an --instance option (or -I for short.)

concrete info --instance=/path/to/my/site

Returns

# Location
Path to instance: /path/to/other/site/web
# concrete5 Version
Installed - Yes
Core Version - 8.5.0
Version Installed - 8.5.0
Database Version - 20190301133300

Roadmap

The most important items we want to currently focus on are:

~~Add the ability to dump sites, configurations, files and more into a standardized backup archive.~~
~~Add the ability to restore a Concrete site from one of these standardized backup archives, by passing a file to a given concrete restore my_backup.gz command.~~
Improved stability of backup and restore
Restore into an uninstalled concrete5
Backing up a version 6 site

After that, we'd be happy to add as many features as you'd like. Should this tool include the ability to create boilerplate block or package code? Absolutely! Should we move code sniffer and code fixing functionality from the core console command to this tool? Yes, please.

FAQ

Why is this tool not built into the core?

We wanted a unified, standardized place to offer a devops and developer's toolkit. The core didn't seem like a great place for it. We want to be able to iterate on this quickly, which means not tying releases of this console utility to releases of the core.

Is this tool meant to replace the concrete5 utility that ships with the core?

I don't know yet. Perhaps in the long term, yes – but that seems like an awful lot of work. Let's just focus on making this tool augment and improve the tools around Concrete CMS, and slowly sunset the original console utility that's built into the core.

console's People

Contributors

Stargazers

Watchers

Forkers

mlocati korvinszanto dimger

console's Issues

bin entrypoint structure

At the moment, bin/concrete is pretty useless: it's only role is to call bin/concrete.php

What about:

deleting bin/concrete
renaming bin/concrete.php as bin/concrete. making it executable, and setting its shebang as #!/usr/bin/env php?
add a Windows entrypoint bin/concrete.bat like we have in the core repo?

Commands and --instance option

At the moment, every command accepts the --instance option.

BTW not all commands may implement the InstallationAwareInterface interface,

For example, here's the output of concrete help self-update:

Usage:
  self-update

Options:
  -h, --help               Display this help message
  -q, --quiet              Do not output any message
  -V, --version            Display this application version
      --ansi               Force ANSI output
      --no-ansi            Disable ANSI output
  -n, --no-interaction     Do not ask any interactive question
  -I, --instance=INSTANCE  Specify the concrete5 directory [default: "."]
  -v|vv|vvv, --verbose     Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Help:
  Update concrete.phar to the latest version.

IMHO we should add the --instance option only to commands implementing InstallationAwareInterface (not sure about how this can be done though).

Create backup:restore command

Create backup:restore command that can take a Concrete archive as created by backup:backup and restore it over an existing, running site. Useful for devops.

Publishing the project as a phar?

What about this approach?

We create a GitHub Action that listen to tags creation.

When a new version-like (/^(v\.?)?\d+.\d+.\d.*$/) tag is pushed, the action would create a phar containing the whole project, create a release, and attach the phar to it.

Assuming that we "rename" the entrypoint as ccm (see #6), that way we'd be able to fetch the whole project as a single executable file, with something like:

curl -L -o /usr/local/bin/ccm https://github.com/concrete5/console/releases/latest/download/ccm.phar
chmod +x /usr/local/bin/ccm

I do really prefer this approach: installing it via composer global require is slower, and global composer.json may contain requirements that are incompatible with this project.

Adding composer.lock to the repository

What about adding to the repository the composer.lock file? That way we are sure about the dependencies being used.

Rename the bin entrypoint to ccm?

What about renaming bin/concrete as bin/ccm? It's shorter 😉

Configure composer to assume PHP 7.1

What about forcing the PHP version in the composer.json file? (ie config.platform.php = 7.1)

Since I think this tool will be mostly used as a phar, and since the phar must support the lowest php version, that makes sense imho...

psalm does not detect errors

We currently have a github action that uses docker://vimeo/psalm-github-actions to run psalm

But that action doesn't seem to be working correctly: when I run psalm locally I get a ton of errors, whereas the github action sees no issues.

Running backup command with phar command doesn't work

I received this error when I attempted to run the backup command on a site:

/usr/share/concretecms-console/concrete.phar backup:backup  --dir=/home/testto_hceu_o2qg/backups/ --instance=/home/testto_hceu_o2qg/public_html/
PHP Fatal error:  Declaration of Symfony\Component\Console\Output\NullOutput::write($messages, bool $newline = false, int $options = self::OUTPUT_NORMAL) must be compatible with Symfony\Component\Console\Output\OutputInterface::write($messages, $newline = false, $options = 0) in /usr/share/concretecms/concrete-cms-9.1.1/concrete/vendor/symfony/console/Output/NullOutput.php on line 124
Whoops\Exception\ErrorException: Declaration of Symfony\Component\Console\Output\NullOutput::write($messages, bool $newline = false, int $options = self::OUTPUT_NORMAL) must be compatible with Symfony\Component\Console\Output\OutputInterface::write($messages, $newline = false, $options = 0) in file /usr/share/concretecms/concrete-cms-9.1.1/concrete/vendor/symfony/console/Output/NullOutput.php on line 124
Stack trace:
  1. Whoops\Exception\ErrorException->() /usr/share/concretecms/concrete-cms-9.1.1/concrete/vendor/symfony/console/Output/NullOutput.php:124
   | array(1) {
   |   [0]=>
   |   string(258) "Declaration of Symfony\Component\Console\Output\NullOutput::write($messages, bool $newline = false, int $options = self::OUTPUT_NORMAL) must be compatible with Symfony\Component\Console\Output\OutputInterface::write($messages, $newline = false, $options = 0)"
   | }

  2. Whoops\Run->handleError() /usr/share/concretecms/concrete-cms-9.1.1/concrete/vendor/filp/whoops/src/Whoops/Run.php:486
   | array(0) {
   | }

  3. Whoops\Run->handleShutdown() [internal]:0
   | array(0) {
   | }

concrete command: symfony error

Hello,

i installed the concrete5-console package via composer, and export PATH=~/.composer/vendor/bin:$PATH is in my .zshrc file.

But concrete info returns:

Fatal error: Cannot redeclare dd() (previously declared in /Users/expl0it/.composer/vendor/symfony/var-dumper/Resources/functions/dump.php:35) in /Users/expl0it/.composer/vendor/concrete5/console/helpers.php on line 7

How can i fix that?.

Add a PHP coding style checker/fixer command

Referring to concretecms/concretecms#9852 (comment): what about moving the c5:phpcs CLI command (and all the related code) from the core to this project?

Running backup complains about Phar errors

I didn't have this on my local machine, but when testing something out in a docker container I can't get backup to complete. It's dying somewhere in the PharData routine.

root@ce9769bb7461:/usr/share/concretecms-console# /usr/share/concretecms-console/vendor/bin/concrete backup:backup  --dir=/home/testto_hceu_o2qg/backups/ --instance=/home/testto_hceu_o2qg/public_html/
Exporting database: testto_hceu_o2qg
Database backed up to file: /root/.config/concrete/tmp/tmpdir_62c9866473d54/db/db.sql
Adding files from storage location: 'Default' (/home/testto_hceu_o2qg/public_html/application/files)
Exporting application/ directory...
Exporting packages/ directory...
Exporting concrete/ directory...
Compressing directory: backup_concrete_site_2022-07-09-06-45-11
Removing temporary directory...

In BackupCommand.php line 337:
                                                                                                                                                                         
  tar-based phar "/home/testto_hceu_o2qg/backups/backup_concrete_site_2022-07-09-06-45-11.tar" cannot be created, header for  file "manifest.json" could not be written

Create backup:backup command that dumps database, copies files, and can optionally include the core and/or configurations.

Rename `--instance` to `--path`

We currently use --instance to specify which concrete path to use. This works great but it's a little too focused on the concrete instance aspect and would require additional options for things like package path if running the console tool against a package.

Instead of using --instance let's switch to the more generic --path so that we can reuse this option for all things base-path related.

Strict types?

I'm a big fan of strongly typed languages.

What about adding declare(strict_types=1); to the files, and adding parameter/return types whenever possible?

Unable to connect to concrete 5.7+ sites using concrete.phar

Since modern concrete versions unregister the phar stream wrapper, we currently can't distribute this project as a phar.

See:

~~We have these alternatives:~~

~~patch the core versions to disallow disabling phar~~
~~avoid using concrete/bootstrap/start.php~~
~~avoid distributing the console app as a phar~~

I found the solution: #34

Downloading the phar with the recommended script can have odd results.

Github is likely blocking certain user agents and so I end up getting Not found as the content of my phar instead of the actual phar:

main@cli:/app$ cat /usr/local/bin/concrete 
Not Found

It'd be nice to either fail the curl if we get this result and also to figure out what's causing it.

Phase out composer global based install in favor of Phar

There are a few nails in the coffin for composer global based install:

Phar works well already and is the preferred method of install today.
Supporting both phar installation and composer based installation causes pain in dealing with dependencies.
Installing with composer global can lead to dependency collisions with other globally installed tools

The steps we need to take to get rid of phar as I see it are:

Add phar CI actions. We do run tests on the composer repo but I think we need to do at least some testing on the built phar before drafting a release or merging a pull.
Remove concrete5/console from packagist.org, or update it in a way that makes it obvious that someone should install using phar

Trait variables are accessed in a way that isn't null-safe

The problem is we don't have either:

A way to guarantee that $this->output is not null
The ability to use PHP 8 null safe operator like $this-output?->foo()

so ideally if we wanted this to be type safe we'd use getter methods on traits to access variables in a way that guarantees an object is returned and not null.

Originally posted by @KorvinSzanto in #22 (comment)