oxid-professional-services / oxid-console
the oxid professional services console for oxid
Installs: 65 535
Dependents: 1
Suggesters: 0
Security: 0
Stars: 7
Watchers: 16
Forks: 5
Open Issues: 7
Requires
- php: ^7.1
- ext-json: *
- oxid-esales/oxideshop-ce: ^v6.0.0
- dev-master
- 6.0.1
- 6.0.0
- 6.0.0-beta10
- 6.0.0-beta9
- 6.0.0-beta8
- 6.0.0-beta7
- 6.0.0-beta6
- 6.0.0-beta5
- 6.0.0-beta4
- 6.0.0-beta3
- 6.0.0-beta2
- 6.0.0-beta1
- 5.3.0
- 5.3.0-beta1
- 5.2.0
- v5.1.0
- 5.0.29
- 5.0.28
- 5.0.27
- v5.0.26
- 5.0.25
- 5.0.23
- 5.0.22
- 5.0.21
- 5.0.20
- 5.0.19
- 5.0.18
- 5.0.17
- 5.0.16
- 5.0.15
- 5.0.14
- 5.0.13
- 5.0.12
- 5.0.11
- 5.0.10
- 5.0.9
- 5.0.8
- 5.0.7
- 5.0.4
- 5.0.3
- 2.0.x-dev
- v1.2.6
- v1.2.5
- v1.2.4
- v1.2.3
- dev-php7.0
- dev-change-log-level-to-debug
- dev-readme-grammar-update
- dev-fix-php-warnings
- dev-feature-implemented-module-migration-feature
- dev-exit
- dev-remove-fix-states
- dev-fix-controller-class-already-used-by-module
- dev-dev-6.0-wip
This package is auto-updated.
Last update: 2024-10-19 00:41:06 UTC
README
OXID PS Console is a Symfony console application for OXID eShop. It is community and project driven with write and read access like in a public wiki (like Wikipedia).
The following commands are available:
cache:clear
- Clear OXID cacheviews:update
- Regenerate database viewsmodule:activate
- Activate module in shopmodule:generate
- Generate new module scaffoldmodule:fix
- Fix the module chain based on the metadata contentsmigration:generate
- Generate new migration filemigration:run
- Run migration scripts
For backwards compatibility the following commands are still available (but are deprecated):
db:update
- Updates database viewsg:migration
- Generate new migration fileg:module
- Generate new module scaffoldlist
- (default) List of all available commandsmigrate
- Run migration scripts
Which version to get?
Installation
Use Composer to add the console to your project
composer require oxid-professional-services/oxid-console
Getting started
vendor/bin/oxid list
Defining your own command
- Class must extend
Symfony\Component\Console\Command\Command
class - Add the following in the services.yaml json of your module (composer package)
services: oxid_community.moduleinternals.module.fix.command: class: OxidCommunity\ModuleInternals\Command\ModuleFixCommand tags: - { name: 'console.command' }
Template for your command:
<?php use Symfony\Component\Console\Command\Command; use Symfony\Component\Console\Output\OutputInterface; use Symfony\Component\Console\Input\InputInterface; /** * My own command * * Demo command for learning */ class MyOwnCommand extends Command { /** * {@inheritdoc} */ public function configure() { $this->setName('my:own'); $this->setDescription('Demo command for learning'); $this->addOption('demo', 'd', InputOption::VALUE_NONE, 'run demo'); } /** * {@inheritdoc} */ public function execute(InputInterface $input, OutputInterface $output) { if ($input->getOption('demo')) { $output->writeln('You typed in --demo or -d also'); } $output->writeln('My demo command finished'); } }
For more examples please see https://symfony.com/doc/current/components/console.html
Migrations
Warning current implementation does not trigger the oxid core migration "oe-eshop-doctrine_migration"
OXID Console project includes migration handling. Lets generate sample migration by running vendor/bin/oxid migration:generate "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 vendor/bin/oxid migration:run
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 vendor/bin/oxid migration:run 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