>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #319724. --> >>> <p>This feature request is a continuation of <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/content_taxonomy/-/work_items/315959" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/content_taxonomy/-/work_items/315959</a></span>. I'm aiming for the same outcome here, but I hope I'm using more reasonable methods to accomplish it.</p> <p>Content_taxonomy fields have a hard time living with taxonomy vocabularies when it comes to node edit forms. The current behavior is to unset the form elements for all taxonomy vocabularies when any field has the 'hide_taxonomy_fields' property set TRUE. This has the undesirable side effect of unsetting terms in vocabularies that have nothing to do with content_taxonomy fields. For new users of content_taxonomy who are trying to learn about the module, this causes data loss when they edit existing nodes that have existing term selections but are of a content type which has content_taxonomy fields. To accommodate content_taxonomy's all-or-nothing methods of avoiding conflicts and collisions, we must create a content_taxonomy field for each vocabulary we want to use on a content type.</p> <p>I find the module's primary purpose to be:</p> <ul> <li>To define the nature (or 'type') of a term's relationship to a node. Taxonomy module requires us to imply the nature of these relationships basically at the theme layer.</li> <li>To allow a node to have multiple typed relationships with the same node. Taxonomy module supports one type of generic relationship between terms and nodes.</li> </ul> <p>The module also provides other benefits:</p> <ul> <li>Terms are stored in CCK tables, so CCK can come to bear when the field is used in views. Sorting and grouping are a bit more robust.</li> <li>Widgets. Rather than simple select and autocomplete text fields, we can use different configurable widgets than what taxonomy module provides</li> <li>Scope. A hierarchical vocabulary can be sliced and diced into separate fields by limiting a field's scope to a particular parent term so that field options come from only that term's children rather than the whole vocabulary.</li> <li>This list is not meant to be exhaustive! But there are cool things to do with CCK field permissions and stretching a vocabulary's domain of content types so we can include the a vocabulary on node types not allowed by the core taxonomy.module vocabulary settings.</li> </ul> <p>This patch allows content_taxonomy module to be more delicate and precise in its avoidance of conflicts and collisions when a node is saved. Let me review the major changes.</p> <h2>hide_taxonomy_fields</h2> <p>This property is removed from field options. If content_taxonomy isn't going to unset all taxonomy fields, we will want to allow a node form to have taxonomy.module vocabularies and fields based on a subset of those vocabularies. If you have vocabularies showing up that you don't want on your node form, use taxonomy module's vocabulary edit form to disable that vocabulary for the node type.</p> <h2>_content_taxonomy_array_cleared</h2> <p>The $_content_taxonomy_array_cleared in the presave op of content_taxonomy_field needs to track individual vocabularies that have been cleared rather than just the node whose entire taxonomy term selections have been unset. The variable previously was global when I think it should have been static. This variable needs to be kept because multiple content_taxonomy fields might want to also store values in the term_node table, but the fields are saved sequentially. We don't want a second field instance of a vocabulary to unset the terms saved by the first field instance's presave operation.</p> <h2>$node-&gt;taxonomy can also contain term objects not just arrays indexed by vocabulary ID</h2> <p>The CCK field 'presave' operation is called whenever a CCK field is saved. CCK fields can be saved without ever being passed through a node form. Actions in cronjobs for example. Nothing bad happens when you ignore the possibility that terms might be objects, but the database key constraints are violated when taxonomy_node_save tries to insert the same row twice.</p> <h2>content_taxonomy_form_alter</h2> <p>Previously, this function would unset all taxonomy form elements on node forms with content_taxonomy fields. Now this function simply accumulates a list of vocabulary IDs that are used in fields so these form elements can be unset.</p> <h2>_content_taxonomy_taxonomy_unset</h2> <p>This new function takes either the values of $form['taxonomy'] or $node-&gt;taxonomy and an array of vocabulary IDs. If the node or form contains any terms from these vocabularies, they are unset because those values are either (a) being presented on the node form in a content_taxonomy field or (b) might be saved into the term_node table when the field is saved. When tags are encountered, the function calls itself again so that tag vocabularies are safely unset when they are used as fields.</p> >>> [!note] Pre-migration files - [content-taxonomy-careful-unset.patch](https://www.drupal.org/files/issues/content-taxonomy-careful-unset.patch) >>>