Prevent references fields from creating duplicates

Created on 16 November 2017, about 7 years ago
Updated 10 February 2024, 11 months ago

Problem/Motivation

I have a node, that consists of a term reference with the following deltas.

  1. Honda
  2. Tesla Motors
  3. Tesla
  4. Audi

Now I like to merge the term "Tesla" into the term "Tesla motors".
After having done the merge, I would end up with the following data for the node.

  1. Honda
  2. Tesla Motors
  3. Tesla Motors
  4. Audi

Basically I solved one problem and created another, meaning not just a implicit duplicate but a explicit one.

Proposed resolution

One straightforward solution would be to jump into TermManager->migrateReference() and check, if $toTerm->id() already exists in the $values array.

  • If it already exists: Remove the currently processed value, so that the reference will be removed
  • If it not exists: Update the reference like it currently does

I see that the behavior is depending on your existing data model and for most merges it might be a quite edge-case, because the $fromTerm will often not be part of the same reference field data as $toTerm.

I haven't thought much about negative side-effects of preventing reference duplicates, but maybe you will find a use-case where such a problem could lead to unwanted effects?

TODO: Decide if that duplicate prevention

  • is not needed (Won't fix)
  • should be part of the TermManager by default
  • or needs to be configurable in the MergeTerms form

I'm looking forward for a feedback.

Feature request
Status

Closed: outdated

Version

1.0

Component

Code

Created by

🇩🇪Germany szeidler Berlin

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • he proposed resolution suggests modifying the TermManager->migrateReference() method to check for duplicates and handle them accordingly.

    Before implementing such a change, there are a few considerations and steps you may want to take:

    Impact Analysis:

    Understand the current use cases and scenarios where merging terms might occur.
    Identify potential negative side effects of preventing reference duplicates. It's essential to consider various content types, taxonomies, and use cases within the Drupal instance.
    Community Discussion:

    Discuss your proposed resolution on Drupal forums or community channels to gather feedback from other developers and site administrators.
    Check if others have faced similar issues or if there are alternative solutions that have been proposed.
    Backward Compatibility:

    Ensure that the proposed changes do not break backward compatibility with existing modules, themes, or custom code.
    If the change is significant, consider providing migration paths or tools for existing installations.
    Configuration vs. Default Behavior:

    Determine whether the duplicate prevention should be a default behavior or configurable. Some site administrators may have specific use cases where allowing duplicates is acceptable.
    Documentation:

    Update documentation to reflect the changes, explaining the new behavior and any configuration options.
    Provide clear guidelines on how site administrators can manage term merging and avoid potential issues.
    Testing:

    Implement thorough testing to ensure the changes work as expected in various scenarios.
    Test with different Drupal configurations, including diverse taxonomies and content types.
    Security Considerations:

    Evaluate the security implications of the proposed changes.
    Ensure that the modifications do not introduce vulnerabilities or security risks.
    Drupal Core Contribution:

    If the changes are deemed beneficial and well-received by the community, consider contributing them to the Drupal core.
    Remember that any changes to core functionality should be approached with caution, and thorough testing and community input are crucial to ensuring a robust and widely accepted solution. I did same things for a blog that was covering tesla car charging topic on his.

Production build 0.71.5 2024