Term Change

Term change is a module that provides functionality for sites that need to change term references in content.

The modules helps making the replacement of terms:

• Extensible: support various ways terms appear in content (taxonomy fields, WYSIWYG, link fields, config entities, etc).
• Reliable: via a queue-based, resumable system that avoids partial changes or data loss.
• Transparent: by tracking progress and allowing rollbacks or audits.
• Complete: by handling translations of content as well.

Plugins

The module introduces a TermChangePluginManager, for discovering and managing plugins that define how and where terms should be changed. Each plugin should:

• Find entities/config that reference the given source term(s).
• Handle the change to replace source values with the specified target.

Plugins should be placed in the src/Plugin/TermChange directory and implement
the TermChangeInterface. There is a base plugin class that can be used as a
starting point to help with the heavy lifting: TermChangeBase.

The module ships with the following plugins:

• Entity Reference: The replaces any reference to a source term with a reference
  to a target term.

Tracking term changes

The module creates lightweight term_change_job and term_change_job_item
entity types.

The term_change_job entities keeps track of:

• The source term that should be changed.
• The values of the source term that should be changed (to allow reverting the
  change).
• The target term for the change.
• The status of the job (created / in progress / completed / reverted).
• The time the job was created.
• The user that created the job.

The term_change_job_item entities keeps track of:

• The related term change job.
• The plugin ID that should handle the job item.
• Extra configuration that the plugin requires.
• The result of the job item (which fields were changed, which translations, if
  the target term already exists, etc).
• The status of the job item (created / in progress / completed / reverted).
• The time the job item was created.
• The user that created the job item.

Queue-based processing

When a term_change_job entity is created, we first create a
term_change_job_plugin queue item for each plugin and the job, using the
job ID and plugin ID.

When processing the term_change_job_plugin queue items:

• The plugin should find entities or config.
• For each item found by the plugin we would create a term_change_job_item
  entity and a term_change_job_item queue item.

For the term_change_job_item queue items, we pass the term_change_job_item
entity ID.

When processing the term_merge_job_item queue items:

• The queue item updates the entity or config using the related plugin.
• Updates the progress for the term_merge_job_item entity.
• When all items are processed, the term_merge_job entity is marked as
  completed.

Term change job UI

An overview of all the jobs that were created can be found at
/admin/structure/taxonomy/term-change.

The overview shows the following information for each job:

• The source term.
• The target term.
• The job status.
• The amount of related job items.
• The date the job was created.
• The user that created the job.
• The actions that can be taken for the job.
  • View all job items.
  • Revert the job.
  • Execute the job again.
  • Delete the job.

Integrations

Term Merge: Term change can be used to merge terms.