[FEATURE]: Use native Eloquent migration

[dimitriBouteille]

trafficstars

Replace robmorgan/phinx by custom migration tool. The migration system should ideally take over the same logic and functionality as what is proposed by Laravel.

• Create migration
• Run migration
• Execute one migration
• Show migration status
• Rollback migration

In order to make the system configurable, it is necessary to provide :

• The migration directory configuration - probably via filter or constant
• The migration table name configuration - probably via filter or constant

[rafaucau]

Maybe this would be a code inspiration on how it can be done in WordPress:

• https://github.com/roots/acorn - using Eloquent migrations
• https://github.com/deliciousbrains/wp-migrations - not using Eloquent migrations, but could be used as dependency to this library

[dimitriBouteille]

Hi @rafaucau

Thanks for sharing the links, the goal of dbout/wp-orm is to avoid overusing third party dependencies in order to reduce problems. I think to start on a migration system as simple as possible with wp-cli.

I already started working on the subject by checking that the Dbout\WpOrm\Orm\Schemas\WordPressBuilder class works well: https://github.com/dimitriBouteille/wp-orm/pull/96

This new migration system is probably the last topic before releasing the v4 :)

[dimitriBouteille]

@rafaucau

For information, I updated the ticket with the desired features. If you have ideas, do not hesitate to suggest :)

[rafaucau]

I could create a Pull Request for this when I find some time. Here's my vision for it:

• Add a setup method that would handle WP-CLI command registration. It could also register facades (#64). The mu-plugin / plugin would then call this method.
• The WP-CLI commands would proxy all necessary Laravel commands, for example:
  • php artisan make:migration create_some_table ➡️ wp orm make:migration create_some_table
  • php artisan migrate ➡️ wp orm migrate
  • and so on...

And this is what the setup method could look like:

Dbout\WpOrm\Orm::setup([
    'migrations' => [
        'directory' => WP_ORM_MIGRATIONS_DIR,
        'table' => apply_filters('my-plugin/migrations-table', 'my_plugin_migrations'),
    ],
    'commands' => [
        'enabled' => true,
        'prefix' => 'orm',
    ],
    'facades' => [
        'enabled' => true 
    ]
]);

This approach would enable the use of WordPress filters and custom constants, allowing the library to be used across different independent plugins without conflicts. Plugins could define their own constants and filters. Note: When multiple independent plugins use this library, they should use tools like Strauss to prefix namespaces and other things to avoid version conflicts.

What do you think about this approach?

[dimitriBouteille]

Hi @rafaucau

Thanks for the proposal, I have a little less time than expected to work on this feature, thank you for your help:)

I think the approach is good, just a little remark for the facades. In my own projects I use the Laravel facade system with a custom container, so it should be possible to pass its own container when initializing the DB facade.

Dbout\WpOrm\Orm::setup([
    ...,
    'facades' => [
        'container' => new MyContainer(),
        'enabled' => true 
    ]
]);