+ if (\Drupal::moduleHandler()->moduleExists('filter') && $this->configuration['filter_autop']) {
+ $text = _filter_autop($text);
+ }
The snag here is it would silently fail if filter module is not enabled. imo better if it would at least kick a notification. Or a better notice on the option like "Filter module must be enabled, or this step will be skipped silently." Some tweak of that nature. That's the only issue which jumps at me right now. Thanks so much for hashing this out to work cleanly!
+ '#description' => 'Converts line breaks into <p> and <br> in an intelligent fashion.',
Thanks ndf I put this on the description page for this module to lead people over there.
Thank you everyone! Will release a new version on this important fix.
Thank you Jay Jangid!
HongPong → made their first commit to this issue’s fork.
Thanks Jay Jangid!
HongPong → made their first commit to this issue’s fork.
Thank you Jay Jangid, Jasjeet Kaur Brar and Anmol_Specbee !
Brought this to slack drupal #migrate and mikelutz gave useful info. i think this is the 'plugin derivatives' / plugin derivers' idea. Thus we should transition these migration config entities to 'derivers' when possible. (I think thats the same as derivatives.)
related examples:
https://www.drupal.org/project/entity_timeline/issues/3281990 →
https://api.drupal.org/api/drupal/core!lib!Drupal!Component!Plugin!Deriv...
https://www.sitepoint.com/tutorial-on-using-drupal-8-plugin-derivatives-...
https://drupal.stackexchange.com/questions/293667/how-do-i-create-a-deri...
https://api.druphelp.com/api/drupal/core%21lib%21Drupal%21Component%21Pl...
https://www.drupal.org/docs/drupal-apis/plugin-api/plugin-derivatives →
https://manifesto.co.uk/drupal-plugin-api-examples-tutorial/
https://www.hashbangcode.com/article/drupal-9-creating-category-menu-usi...
https://www.adamfranco.com/2018/11/13/creating-a-drupal-plugin-system/
mikelutz: The quick and dirty fix here, without refactoring to derivatives is to put something in the template plugin for that key like migration: wordpress_comment so the plugin can load and pass it’s checks. It doesn’t quite matter much, it’s getting overwritten in the dynamically generated config entities anyway, but something needs to be there in the plugin template itself so it can be loaded and used to create the config entities.
The problem isn’t in the importer. You are generating valid config entities there. The module is trying to dynamically generate migrate_plus config entities using the migration plugins in the /migration folder as templates. It’s really not the right approach. If you want to derive multiple migrations from a template, you should use a plugin deriver similar to the way core derives node plugins by content type. The issue here is that your template migrations has https://git.drupalcode.org/project/wordpress_migrate/-/blob/8.x-3.x/migr...
pid:
plugin: migration_lookup
source: comment_parent
# migration ID generated dynamically
Despite the fact that this migration is only supposed to be a template, it’s a real valid plugin. And any version of createEntityFromPlugin creates an instance of this plugin to read the template from. Creating an instance of the plugin checks the dependencies. Checking the dependencies of the plugin scans it for migration lookup processes and adds the migration that you are looking up against to the dependencies. And it can’t because there is an undefined offset ‘migration’.
For anyone else debugging such stuff. with devel and symfony dumper turned on:
Adding the following to web/core/modules/migrate/src/Plugin/Migration.php circa line 745:
if (in_array($plugin_configuration['plugin'], ['migration', 'migration_lookup'], TRUE)) {
if (!isset ($plugin_configuration['migration'])) {
ddm('---- migration is not set on this plugin_configuration!');
ddm($plugin_configuration, 'findmigrationdependencies plugin_configuration');
ddm($process);
ddm('--end---');
} else {
ddm('---- OK: migration is set on this plugin_configuration');
ddm($plugin_configuration, 'findmigrationdependencies plugin_configuration');
ddm($process);
ddm('--OK end--- \n');
}
$return = array_merge($return, (array) $plugin_configuration['migration']);
}Getting closer to this!
WIP added to issue fork with extracted comment entity generator function. https://git.drupalcode.org/issue/wordpress_migrate-3390754 . then reroll after 📌 remove createPluginEntityFromPlugin in WordPressMigrationGenerator Needs review is committed.
That does not fix the problem but does isolate it within a much smaller function.
HongPong → created an issue.
WIP posted. I think it is probably alright. https://git.drupalcode.org/issue/wordpress_migrate-3390755/-/tree/339075...
adding more checks and exceptions for the other ones as well (attachments comments etc)
HongPong → created an issue.
thank you Mykola Dolynskyi . (accidentally did not see this was open, and opened 🐛 Undefined array key "migration" in findMigrationDependencies() Active .
HongPong → created an issue.
This catches the exceptions - both EntityStorageException and generic exception. so it is not a fatal error. However then there is a spew of missing XML file, ( Warning: XMLReader::open(): Unable to open source data in Drupal\migrate_plus\Plugin\migrate_plus\data_parser\Xml->openSourceUrl() (line 177 of modules/contrib/migrate_plus/src/Plugin/migrate_plus/data_parser/Xml.php). )
so i think the following lines after the exception need to be changed - they should not run i think .
// Go to the dashboard for this migration group.
$form_state->setRedirect('entity.migration.list', ['migration_group' => $cached_values['group_id']]);
parent::finish($form, $form_state);
}add something like this - catch and log exception https://www.drupal.org/node/2932520 →
exceptions docs - https://www.drupal.org/docs/develop/coding-standards/php-exceptions →
transaction rollback - $transaction->rollBack(); - https://drupal.stackexchange.com/questions/311933/how-to-properly-log-cu...
core migrate exceptions https://api.drupal.org/api/drupal/core%21modules%21migrate%21src%21Migra...
migrate executable class handle exceptions -https://api.drupal.org/api/drupal/core%21modules%21migrate%21src%21Migra...
examples of caught migrate exceptions #2969551: Migrate messages from caught exceptions need file and line details →
more about managing migration exceptions https://www.phase2technology.com/blog/migration-making-it-all-work
FYI it appears that GitlabCI pipelines can be activated on issue fork repos. However I had to push .gitlab-ci.yml to the 'main' / default branch, rather than the issue branch within the issue fork repo, before it would 'see' that gitlabCI should be available. After that it works fine.
replaced old out of date info re gitlabci with the link to the doc page.
Reverting to allow 3.x ctools per advice from community.
HongPong → created an issue.
Updating URLs. significant out of date language I noticed. The drupalci.yml has changed in structure a bit since the version in this doc. It is no longer true "The Assessment stage is broken up into two phases, 'validate_codebase' and 'testing'" so this needs some attention - i am not sure best approach currently, not an expert here. I recommends someone more familiar update with https://git.drupalcode.org/project/drupal/blob/HEAD/core/drupalci.yml code and structure.
Can anyone else check this one out and give it RTBC? Thank you!
If this recurs with version alpha6 + migrate_plus:6.0+ and latest migrate_tools please re open. Thank you for including the sample wxr xml file!
HongPong → made their first commit to this issue’s fork.
see also #3123393: Users are duplicated → re usernames
If anyone gets this working feel free to open again.
Same idea as #3248042: Add XML Lint to check the WordPress exports → consolidating there. Still got edge cases!
Out of date with current migrate_tools version.
With the big variety of galleries now, this would be sprawling...
This sees to be quite a lot better now.
It does have revisions these days but the export file does not provide them.
Closing this as too far back to work on... Thanks all.
Something similar updated for the latest Drush would be nice as well. Missed this patch.
This was never done with Drupal 7 but the Drupal 10 version is more aligned with this idea.
Without further data we should mark this closed - the cause is not clear.
After 11 years calling it postponed. If anyone gets a patch going in the current branch compatible with Drupal 10 open it up again!
Marking this one as outdated since we have feature parity right now I'm fairly sure.
Closing this as outdated - use migrate_plus 6 and the latest migrate_tools from here on out.
now on migrate_plus 6.x with alpha6 release.
This has been resolved with alpha6 release up to Drupal 10 now. Thank you for helping us out!
We are now recommending migrate_plus 6.x after alpha6.
We are not actively supporting Drupal 7. However it will work on Drupal 9+10.
Hello oknaru please try with migrate_plus:6.x and wordpress_migrate:3.0.0-alpha6 . migrate_upgrade appears to recommend 4.x but I am not familiar -- that is for upgrading old Drupal sites, not Wordpress sites, so maybe it is causing a conflict. If the problem recurs I suggest filing a new issue rather than on this old one, to avoid confusion.
Drupal 10 and ctools issues resolved with alpha6 release today 🐛 Drupal9 compatibility error Active
Resolved with alpha6 release for ctools v4 . 💬 can't install with ctools 4.0 in composer Fixed
Just noting migrate_plus v6 is now recommended, a new alpha6 version of this module released tonight . May help with that error notice.
Hello oknaru,
I have posted a new version alpha6 → with ctools v4 and migrate_plus v6, can you give that a try? If the issue recurs please file a new issue.
Hello @djassie,
I have posted a new version with ctools v4 and migrate_plus v6, can you give that a try? If the issue recurs please file a new issue.
Patched version alpha6 released → . thank you all!
we are switching to ctools 4 with ✨ Drupal 10 compatibility RTBC now committed:
https://git.drupalcode.org/project/wordpress_migrate/-/commit/31fdfafe7f...
Revamp summary with more links to documentation and clarify key elements
Thank you gausarts for the prompt response. I also tried using jQuery to remove the padding-bottom from the element's properties in a custom JS file. However I am not sure how to listen for the ready event of the slider's initialization, so the jQuery runs too early. I see there is a window.Splide javascript object, however I could not determine how to listen for the ready state in an outside script. ( I would rather not simply add a timer to 'wait' for it) . Best regards.
HongPong → created an issue.
adding better info on required theme hooks formatting in theme suggestions and avoiding hyphens
suggest update readme.md link to :
https://git.drupalcode.org/project/site_audit/-/blob/8.x-3.x/README.md
In the DrupalCamp NJ session I just asked where is the best place to find out how to add a test to a contrib module. In my case I think it might be nice to have a migrate-related module let the admins know that the module can safely be disabled once the migration is complete. Was not sure where to look to find out how to do this. (this appears similar: https://www.drupal.org/project/unused_modules → )
HongPong → created an issue.
via #3293825: Update Chaos Tool Suite (ctools) module compatibility from ^3.1 to ~3.0 || ~4.0 → a similar more complicated issue. have not checked if there is an API change yet for ctools 4.x functions we use.
....
To test ctools ~4 add the following in the require part of the root composer.json file for the project:
"drupal/ctools": "4.0.0 as 3.8"
Change for testing only.
re ctools v4 please test the patch here, thank you 💬 can't install with ctools 4.0 in composer Fixed
re ctools please test the patch here, thank you 💬 can't install with ctools 4.0 in composer Fixed