Since the patch has been applied to 2.1.x dev branch; can use a second set of eyes to smoke test one more time before formally adding a new stable release.
Updating issue status to "Needs review"
Since the patch has been applied to 2.1.x dev branch; can use a second set of eyes to smoke test one more time before formally adding a new stable release.
Updating issue status to "Needs review"
Patch applied to 2.1.x dev branch; can use a second set of eyes to smoke test one more time before formally adding a new stable release.
Noting here this issue is a duplicate of the automated Drupal 10 Compatibility update bot issue at https://www.drupal.org/project/adobe_launch/issues/3285992 📌 Automated Drupal 10 compatibility fixes Fixed . The patch / update has been rolled into release 2.1.0
No changes in functionality to the module.
Formally closing issue
For my use case, I realized our customer did not have unique term names, and as a result parent term matching failed based solely on "name".
Since the import processes in order, and our source data assigned parents based on the last known match by term name (newest added term with that name), I added a field to the import form to force creating new terms for each row of data and updated parent matching to be last match identified (which still works in the case all term names are unique).
In addition, I cleaned up some of the debug logging. Updated patch attached for testing and review.
As an update to the refactoring next steps I recommended in the prior comment:
1. In order to achieve the form error messages suggested originally in this ticket here, it assumes the XML file is uniform for every row (my source data omitted blank fields)- hence the parsing of custom fields on a per record/row basis in the patch.
2. include instructions/documentation about how to configure your XML file to support custom fields (namely, the keys must match machine names of fields) which would address https://www.drupal.org/project/taxonomy_import/issues/3392992 📌 Document importing custom fields Active
3. testing and refactoring for CSV to parse/respect custom fields as well.
I encountered confusion with the menu links for this module and submitted a patch under https://www.drupal.org/project/taxonomy_import/issues/3394715 📌 Consolidate Administrative Menu Links into one Taxonomy Import parent menu item Needs review
If that patch is adopted/approved, it should be noted that the additional request on this original issue ticket "As well, admin/structure/taxonomy/manage/TAXONOMY/overview should have a link to admin/structure/taxonomy/manage/TAXONOMY/import which gives an import form for the taxonomy." is not reflected there. Perhaps, that should be a separate feature request.
see https://www.drupal.org/project/taxonomy_import/issues/3393030#comment-15... 🐛 "Field field_* is unknown" exception when importing Active with a patch that should add support back to Dev branch for importing custom fields from XML source files.
I ran into an issue trying to import custom fields via an XML source file (in that, the latest dev version was totally ignoring custom fields).
As a result, I wrote this patch that currently includes a lot of debug logging to check and log what custom fields were matched with the taxonomy, and which will be omitted.
The patch could use a review/testing and can then be further refactored to:
1. achieve the form error messages suggested here.
2. include instructions/documentation about how to configure your XML file to support custom fields (namely, the keys must match machine names of fields) which would address
https://www.drupal.org/project/taxonomy_import/issues/3392992
📌
Document importing custom fields
Active
3. testing and refactoring for CSV to parse/respect custom fields as well.
Patch created that consolidates the two links into a parent "Taxonomy Import" menu item under Content Authoring.
In the process, I renamed the labels for the two menu items.
ansonwhan → created an issue.
I also encountered this problem, but did not think it was necessarily Gin Admin theme related. For my case, we were able to resolve doing the following:
- We exported the redirects table from the MySQL database.
- Uninstall the redirect module
- Reinstall the redirect module
- Import the backed up redirects table into your database.
- Export and commit back to your repo all config related to the redirects module
- language.content_settings.redirect.redirect.yml
- views.view.redirect.yml
- redirect.settings.yml
- system.action.redirect_delete_action.yml
We have not experienced the issue since reinstalling and resyncing config.
We encountered the same exception while doing a cache clear from the UI after upgrading to this version, running Core version 9.4.8. This was without the patch.
Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service "extension.list.module", path: "extension.list.module -> config.factory -> high_contrast.overrider -> theme.manager -> theme.registry". in Drupal\Component\DependencyInjection\Container->get() (line 146 of /mnt/www/html/mccloskeymr/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php).
The error is not encountered when running cache clear via Drush.