"Field field_* is unknown" exception when importing

Created on 10 October 2023, about 1 year ago
Updated 18 October 2023, about 1 year ago

Problem/Motivation

If you try to import into a vocabulary that does not have a custom field that is included in the import file, it will raise:

InvalidArgumentException: Field field_FIELD_KEY is unknown

Steps to reproduce

Create a CSV import file, add the column field_test, and import it into a vocabulary that does not have a field called field_test.

Proposed resolution

At the start of the import process, check for all custom fields used in the import file. If any do not exist in the selected vocabulary, set a form error message about this, listing all the missing fields.

Remaining tasks

Decide on wording of error message. Implement.

User interface changes

Improved error message.

API changes

None

Data model changes

None

πŸ› Bug report
Status

Active

Version

2.0

Component

User interface

Created by

πŸ‡¨πŸ‡¦Canada Liam Morland Ontario, CA πŸ‡¨πŸ‡¦

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @Liam Morland
  • πŸ‡ΊπŸ‡ΈUnited States ansonwhan

    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.

  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 10.1.4 + Environment: PHP 8.2 & MySQL 8
    last update about 1 year ago
    1 pass
  • πŸ‡ΊπŸ‡ΈUnited States ansonwhan

    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.

  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 10.1.4 + Environment: PHP 8.2 & MySQL 8
    last update about 1 year ago
    1 pass
Production build 0.71.5 2024