One problem with presenting import operations through the UI is that core Drupal does not provide a good, reliable way to perform lengthy (perhaps hours-long) operations through the UI. For developers, running migrations through Drush is an option (and strongly encouraged), but that is not directly available to someone simply wanting to import their WordPress blog. wordpress_migrate attempts to address this by allowing configuration at the server end (through setting appropriate variables manually) to run imports by execing Drush in the background. We need to put this, or some equivalent, background import ability into Migrate itself. This is essential for supporting large imports for non-technical users.

It will require some server-side setup - an administrator will need to set a variable through drush, pointing to where drush is installed, for the capability to be enabled. We should (in the presence of this variable) have a configuration page for setting up notifications generated by the drush process.


bdone’s picture

@mikeryan, can you elaborate on any steps needed to help you achieve this goal?

i'm embarking on a solution similar to the one you've implemented in wordpress_migrate. is the submit handler as seen in wordpress_migrate_import_form_submit() something you'd advocate for custom migrations?

mikeryan’s picture

I will be transferring the wordpress_migrate implementation into migrate itself in the near future, in the wizard_api branch. It will be based on the wordpress_migrate_import_form_submit(), but I hope to simplify it a bit.

mikeryan’s picture

Issue tags: +Migrate 2.6

Tagging feature requests I'd like to get into Migrate 2.6.

mikeryan’s picture

Status: Active » Fixed

This has been committed to the wizard_api branch.

Automatically closed -- issue fixed for 2 weeks with no activity.