concrete5-community / cli

Unofficial concrete5 CLI Tool

Unifficial concrete5 Command Line Interface tools

You may also be interested in the official CLI tool, available at https://github.com/concrete5/console

---

concrete5 wrapper

This repository contains two shell scripts (c5 for POSIX shells, c5.bat for Windows) that you can place in a directory of your path (for example /usr/local/bin for POSIX shells, or C:\Windows\System32 for Windows).

Once you do it, you can run the concrete5 CLI commands by simply invoking c5 from your shells. In order to detect the location of concrete5, the current working directory can be any of the following:

• the concrete5 webroot
• any sub-directory of the concrete5 webroot
• the parent directory of the concrete5 webroot (provided that the concrete5 webroot is a folder named public or web)

For example, if concrete5 is installed in /var/sites/example/public, c5 will detect concrete5 if the current directory is any of the following locations:

• /var/sites/example
• /var/sites/example/public
• /var/sites/example/public/packages
• /var/sites/example/public/packages/my_package/blocks/my_block

(the same principle applies to Windows)

POSIX-specific details

Running concrete5 as a different user

You can let c5 execute the concrete5 CLI commands as another user by using the C5_SUDOAS environment variable. It requires that the sudo command is available.

For example:

C5_SUDOAS=www-data c5 c5:info

Sourcing the script

Instead of copying the c5 script to a directory of your path, you can also source it (that is, preload it), for example in your shell initialization script (~/.bashrc for bash):

. /path/to/c5

Once you have reloaded your shell, you'll have the c5 function available.

Windows-specific details

At least under Windows 7, the c5 script is recognized when in C:\Windows\System32 but it doesn't necessarily work for the composerpkg script (see below for details about composerpkg)

The first issue is that the script might be locked by the system.

Click on the composerpkg script and bring up the properties screen. At the bottom you should see an option to unlock it if it's locked.

Generally speaking, it is probably better to put both your scripts in a custom folder, make sure neither composerpkg or c5 are locked by the system, and add your custom folder to your path.

For instance:

• Add c5, c5.bat, composerpkg and composerpkg.bat to C:\Dev\Util\Bin (create the folder)
• Then add your folder C:\Dev\Util\Bin to your path.

You can find out how to add a folder to your Path on this page (it's Java specific but the process is the same for any folder)

composer wrapper for package dependencies

When writing packages for concrete5, you may require composer libraries. When using a composer-based concrete5 installation, this is not a problem, since composer will handle flawlessly your dependencies, and create an autoloader for you.

Problems arise when your package is going to be installed without composer, and you need to provide the composer libraries together with your package.

For example, let's assume that you have in your package composer.json file these requirements:

{
    "require": {
        "concrete5/core": "^8.5.1",
        "some_vendor/some_package": "1"
    }
}

This is totally legal: you are telling composer that your package requires concrete5 version 8.5.1 (or any later 8.x version), and that you need the some_vendor/some_package package. By the way, if you run a composer install because you want to distribute your package, composer will download concrete5 and install it in your vendor directory, which of course you don't want to.

Another problem arises when your package requires (directly or indirectly) a library that's already included in concrete5 vendor directory. That leads to having to having two running copies of the same library (one in the concrete5 vendor directory, and one in your package vendor directory). This is a waste of space, and the actual version being used may be undetermined.

To avoid these problems, you can run the composerpkg command included in this repository (for Windows users, you'll also need the composerpkg.bat file - to be saved in the same directory as the composerpkg file). composerpkg accepts the same arguments accepted by the plain composer command, but when you install/update the dependencies, you won't have duplicated stuff in your vendor directory.

By default, composerpkg will run Composer by invoking the composer command. If you need to customize it, you can use the COMPOSERPKG_BIN environment variable. For example:

# On Linux & Mac
COMPOSERPKG_BIN='/path/to/your/composer' composerpkg ...
# or
COMPOSERPKG_BIN='/path/to/your/composer'
export COMPOSERPKG_BIN
composerpkg ...

# On Windows (with cmd.exe)
set COMPOSERPKG_BIN="C:\path\to\your\composer"
composerpkg ...

# On Windows (with PowerShell)
$Env:COMPOSERPKG_BIN='C:\path\to\your\composer'
composerpkg ...

You can make composerpkg verbose by setting the COMPOSERPKG_VERBOSE to 1.

cli's Issues

Is there someone taking care of this repository?

Pull requests are left unreviewed for months...

Minimum PHP version

We have loose plans to make this tool manage legacy sites. If we want to do that, we may want a minimum PHP version of PHP 5.3 and lowering it in the future is going to be hard.

Do we want to support PHP 5.3, or should we just support the maximum legacy version, which is PHP 5.6?

test

test

This project is archived. Please https://github.com/concrete5/console instead.

https://github.com/concrete5/console is where active development on a Concrete console is taking place.

Plan initial functionality

The broad stroke list is:

1. Globally installed
2. Manages concrete5 instances v7+
3. Imports commands from the concrete5 instance
4. Has most or all of the features of the current core CLI tool