Git Product home page Git Product logo

oxid-console's Introduction

OXID Console

Build Status

OXID Console is php console application for OXID Shop. It provides an API for writting various commands.

By default there are following commands included:

  • cache:clear - Clear OXID cache from tmp folder
  • db:update - Updates database views
  • fix:states - Fixes modules metadata states
  • g:migration - Generate new migration file
  • g:module - Generate new module scaffold
  • list - (default) List of all available commands
  • migrate - Run migration scripts

This OXID Console repository has Migration Handler and Module State Fixer included.

Which version to get?

OXID Version OXID Console version Source Code link Download link
<4.9.0, <5.2.0 1.1.X Source Code Download ZIP
=>4.9.0, =>5.2.0 1.2.X Source Code Download ZIP

Installation

This package is following a structure which OXID introduced with their update packages.

  • Copy contents of copy_this to your OXID eShop project
  • Check the difference between your OXID eShop files and files which are in changed_full and update files according to the difference

Getting started

The entry point of console application is php oxid. It will execute default command which is list. To call a specific command run php oxid [command]. If you need help about specific command run php oxid [command] -h or php oxid [command] --help

Defining your own command

  • Commands get autoloaded from application/commands/ and [module_path]/commands/ directories. But you can always add or remove commands with add() or remove() methods of console application
  • You can access console application $this->getConsoleApplication() and input object $this->getInput() in your command class
  • Command filename must follow [your_command]command.php format
  • Class name must be the same as filename, e.g. CacheClearCommand
  • Class must extend oxConsoleCommand abstract class
  • You must set name of your command on configure() method

Template for your command:

<?php

/**
 * My own command
 *
 * Demo command for learning
 */
class MyOwnCommand extends oxConsoleCommand
{

    /**
     * {@inheritdoc}
     */
    public function configure()
    {
        $this->setName('my:own');
        $this->setDescription('Demo command for learning');
    }

    /**
     * {@inheritdoc}
     */
    public function help(oxIOutput $oOutput)
    {
        $oOutput->writeLn('This is my help output');
    }

    /**
     * {@inheritdoc}
     */
    public function execute(oxIOutput $oOutput)
    {
        $oInput = $this->getInput();
        if ($oInput->hasOption(array('demo', 'd'))) {
            $oOutput->writeLn('You typed in --demo or -d also');
        }

        $oOutput->writeLn('My demo command finished');
    }
}

Working with arguments and options

First of all You must know that -abc is the same as -a -b -c and it is a good practice to have long version of option too, e.g. -a is the same as --all. Console Input provides you with various methods to work with options. There is nothing better than a good example:

Command class

<?php

/**
 * My own command
 *
 * Demo command for learning
 */
class MyOwnCommand extends oxConsoleCommand
{

    /**
     * {@inheritdoc}
     */
    public function configure()
    {
        $this->setName('my:own');
        $this->setDescription('Demo command for learning');
    }

    /**
     * {@inheritdoc}
     */
    public function help(oxIOutput $oOutput)
    {
        // TODO: Implement help() method
    }

    /**
     * {@inheritdoc}
     */
    public function execute(oxIOutput $oOutput)
    {
        $oInput = $this->getInput();

        var_dump($oInput->hasOption(array('a', 'all')));
        var_dump($oInput->hasOption('b'));
        var_dump($oInput->hasOption('not-valid'));

        var_dump($oInput->getOption('word'));

        var_dump($oInput->getOptions());
        var_dump($oInput->getArguments());

        var_dump($oInput->getArgument(2));
    }
}

php oxid my:own -o cat --all tree -bzg house --word=nice dog

bool(true)
bool(true)
bool(false)

string(4) "nice"

array(6) {
  'o'    => bool(true)
  'all'  => bool(true)
  'b'    => bool(true)
  'z'    => bool(true)
  'g'    => bool(true)
  'word' => string(4) "nice"
}
array(5) {
  [0] => string(6) "my:own"
  [1] => string(3) "cat"
  [2] => string(4) "tree"
  [3] => string(5) "house"
  [4] => string(3) "dog"
}

string(4) "tree"

Migrations

OXID Console project includes migration handling. Lets generate sample migration by running php oxid g:migration add amount field to demo module.

Console application generated migration/20140312161434_addamountfieldtodemomodule.php file with its contents:

<?php

class AddAmountFieldToDemoModuleMigration extends oxMigrationQuery
{

    /**
     * {@inheritdoc}
     */
    public function up()
    {
        // TODO: Implement up() method.
    }

    /**
     * {@inheritdoc}
     */
    public function down()
    {
        // TODO: Implement down() method.
    }
}

Migration handler can run migrations with your given timestamp (if no timestamp provided than it assumes timestamp as current timestamp). Inside it saves which migration queries were executed and knows which migration queries go up or go down.

Once we generated this file we run php oxid migrate

Running migration scripts
[DEBUG] Migrating up 20140312161434 addamountfieldtodemomodulemigration
Migration finished successfully

Now lets run the same command a second time

Running migration scripts
Migration finished successfully

Note: No migration scripts were ran

Ok, now lets run migrations with given timestamp of the past with php oxid migrate 2013-01-01 command

Running migration scripts
[DEBUG] Migrating down 20140312161434 addamountfieldtodemomodulemigration
Migration finished successfully

It ran our migration query down because on given timestamp we should not have had executed that migration query.

Example

Here is a quick example of migration query which adds a column to oxuser table

<?php
// FILE: 20140414085723_adddemoculumntooxuser.php

class AddDemoCulumnToOxUserMigration extends oxMigrationQuery
{

    /**
     * {@inheritdoc}
     */
    public function up()
    {
        if ($this->_columnExists('oxuser', 'OXDEMO')) {
            return;
        }

        $sSql = "ALTER TABLE  `oxuser`
                 ADD  `OXDEMO`
                    CHAR( 32 )
                    CHARACTER SET utf8
                    COLLATE utf8_general_ci
                    NULL
                    DEFAULT NULL
                    COMMENT  'Demo field for migration'";

        oxDb::getDb()->execute($sSql);
    }

    /**
     * {@inheritdoc}
     */
    public function down()
    {
        if (!$this->_columnExists('oxuser', 'OXDEMO')) {
            return;
        }

        oxDb::getDb()->execute('ALTER TABLE `oxuser` DROP `OXDEMO`');
    }
}

Migration Query Law

  • Filename must follow YYYYMMDDHHiiss_description.php format
  • Must extend oxMigrationQuery abstract class
  • Class name must be the same as description with Migration word appended to the end of the name

Note: It is better to use generator for migration queries creation

Module state fixer

Current problem

When you change information of module in metadata you need to reactivate the module for changes to take effect. It is a bad idea for live systems because you might loose data and it bugs out developers to do this all the time by hand.

Solution

oxModuleStateFixer which is an extension of oxModuleInstaller has method fix() which will fix all the states.

We have provided you with fix:states command to work with oxModuleStateFixer. Type in php oxid fix:states --help for more information.

Credits

This project was inspired by Symfony/Console component.

oxid-console's People

Contributors

4fb avatar alfredbez avatar ddpkts avatar ellisv avatar keywan-ghadami-oxid avatar kipperlenny avatar svenbrunk avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

oxid-console's Issues

Does not work with 6.0

oxid-console does not work with OXID eShop version 6.0 (which is not released atm)

  • some folders are uppercase now e.g. application is now Application
  • core/interface is now Core/Contract
  • sConfigKey isn't defined in oxconfk.php anymore (it's here now)
  • oxModuleInstaller@_addModuleSettings doesn't exist anymore, instead you have to use the new SettingsHandler (example)

Migration cache should stored in database.

Hi,

very cool project! But I have one problem:

I have shops in multiple environments:
development
testing
staging
production

Each environment has it's own database and my deploy software (http://typo3.org/additional-products/surf/) restore the current live database and create a new installtion of the shop:

releases/201410011000/
releases/201410012000/
releases/201410013000/
releases/201410014000/
releases/201410013000/previous -> releases/201410013000/
releases/201410014000/current -> releases/201410014000 <- thats active the root dir of vhost

The problem:

I deploy a new feature with new database tables and columns but the deployment restore the database. The columns and tables are deleted. Now I run "oxid migrate" and all migrations are executed.

So I think a table is the best solution to resolv this problem.

It would be nice to have this features:

  • commands and migrations in modules.
  • oxid-console as real oxid module with composer compatibility.(put "oxid" in composer bin-dir and symlink "oxid" in the source dir and put the functions.php contents in "oxid") https://getcomposer.org/
  • setup command to install via shell

If you want I could create some pull-request for it.

Cheers, Robin

Fix module states, remove non existing modules

php oxid fix:states -a
[DEBUG] Working on shop id oxbaseshop
..
[DEBUG] testmodule1 does not exist - skipping
[DEBUG] Fixing testmodule2 module
..

why not to remove non exiting modules?

oxMigrationHandler and RecursiveDirectoryIterator

I am a happy OXID Console user, but I had some issues while migrating DB migrations on some linux machines, smth like described here https://bugs.php.net/bug.php?id=48881 - it depends on some locale or whatever system settings.

The problem that migration files are loaded in wrong order in oxMigrationHandler (RecursiveDirectoryIterator) and the whole process fails when ran migrations are being loaded and ran once again.

I have a quickfix on my environment, that sorts files by filename, as you migration files start with timestamp. If this others are having this issue I could provide ar PR on this or maybe there is another better way to load files correctly in RecursiveDirectoryIterator.

screenshot 2016-01-04 16 36 58

Please add an example for a migration task

Hi,

I just stumbled over your very nice project. I am very interested in it, particularly in the migration tasks. We are using simple sql files for migrations in combination with capistrano at the moment (just the up way). Your solution is maybe a better approach to that, but I actually cannot imagine how a implemented migration task would look like. Is it db-schema and data changes in php code? And how do you test it in development?
Maybe you could add an example for that in your readme file?

Thanks
Stephan

cache:clear doesn't remove oxCache (EE Edition)

There must be a possibility to remove oxCache with cache:clear command. This must be patched in both 1.1 and 1.2 releases. Also we may need a flag --files-only to support clearing files only because some setups may rely on that.

Alias / DB-Sync like drush for Drupal

Hi,

drush console for Drupal has the cool feature of aliases so you can for example run sql-sync

drush sql-sync @prod @self

to export the database on your production instance and import locally without having to ssh into the remote by hand and run mysql, gzip, scp and so on. Is it possible to get something like this into the oxid console ?

Why not as a module?

Is there a reason why the oxid-console ist not released as a module? It makes source control much easier and cleaner (i pull external modules as git submodules).

One could easily put some kind of auto-activation in the oxid-entry point. I just did that and converted the structure to a module, which works fine for me.

If not as a module, i really think this should be in the oxid core. It is an essential function for automatic deployments...

module:enable command

It would be great to have module:enable command to enable or disable specific or all modules on base, specific or all (sub-)shops

Enhance module generation

Enhance module generation with more things to be generated and ask in between if you want to generate this or that.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.