Contrib.social

Taxonomy Index for unpublished entities

Open on Drupal.org →
Created on 4 November 2010, about 14 years ago
Updated 12 August 2024, 3 months ago

Problem/Motivation

Identified problem detailed in #962664-9: Taxonomy Index for unpublished entities → :

It is possible to query by field value in views. One of the drawbacks is, by default, you can only query by TID, not Term Name. Having the values in the taxonomy_index table gets around this issue.

And #962664-47: Taxonomy Index for unpublished entities → :

In Drupal prior to 7.x there was an easy way to get all the terms associated with a particular node. In 7.x and beyond, it is very difficult, if not impossible, to get that list of terms. I maintain the tac_lite module, which controls access to nodes based on the terms they are tagged with. Currently there are edge cases where tac_lite cannot learn all the terms a node is tagged with.

And described in #962664-50: Taxonomy Index for unpublished entities → :

So a relationship bewteen the contents and taxonomy terms is only recognized within a view, when the contents are published, which looks like a bug to me though. I didn't want my contents to be available as separate pages, but only as the source for the view(s). Since there is the filter criteria "Content: Published (Yes/No)" for views, they seem to be designed to support the output of the not published contents as well, so I think the relations to taxonomy terms should work for such not published contents as well.

Please note that a contrib module was also introduced to fix this in #962664-16: Taxonomy Index for unpublished entities → :

I have written http://drupal.org/project/taxonomy_entity_index in the meantime to index all entities regardless of published or not. I've opened an issue to add views integration for it.

So users needing a solution for taxonomy terms should consider using the contrib module instead of the rerolls from this issue!

Per #962664-27: Taxonomy Index for unpublished entities → :

Well, I think leaving out unpublished nodes was a design feature to reduce overhead, since this table can get crazy-big on a large site. Technically you could use the EFQ to look up unpublished nodes by taxonomy--fetch a list of all fields, look for taxonomy fields, look up which bundles have these fields, and loop to query against values in all these fields. But that's kinda wild.

Drupal 7 version of this issue: #2878046: D7 Taxonomy Index for unpublished entities →

Steps to reproduce

I believe this edge-case is defined in #962664-50: Taxonomy Index for unpublished entities → best:

So a relationship bewteen the contents and taxonomy terms is only recognized within a view, when the contents are published, which looks like a bug to me though. I didn't want my contents to be available as separate pages, but only as the source for the view(s). Since there is the filter criteria "Content: Published (Yes/No)" for views, they seem to be designed to support the output of the not published contents as well, so I think the relations to taxonomy terms should work for such not published contents as well.

Proposed resolution

Proposed change should update the taxonomy index for unpublished entities. Example use case is where editors manipulate the taxonomy terms of unpublished nodes to be used by a view that searches unpublished nodes by taxonomy term name (as opposed to tid, which can be search by taxonomy_field_name_instance).

Remaining tasks

See #962664-179: Taxonomy Index for unpublished entities → :

We need to check the views query on taxonomy/term/{term} pages before and after the patch (with a lot of records in the index table), and compare the before/after EXPLAIN.

And per @xjm on Slack:

  • the taxonomy API, and Drupal overall, is very, very different than it was when this issue was proposed, so we really need people to think seriously about whether it makes sense anymore

User interface changes

@tbd

API changes

@tbd

Data model changes

Change record as seen in #962664-159: Taxonomy Index for unpublished entities → : https://www.drupal.org/node/3133343 →

Release notes snippet

@tbd

✨ Feature request
Status

Needs work

Version

10.3 ✨

Component
Taxonomy  →

Last updated 22 minutes ago

  • Maintained by
  • 🇺🇸United States @xjm
  • 🇬🇧United Kingdom @catch
Created by

🇺🇸United States ngmaloney

Live updates comments and jobs are added and updated live.
  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

  • Needs subsystem maintainer review

    It is used to alert the maintainer(s) of a particular core subsystem that an issue significantly impacts their subsystem, and their signoff is needed (see the governance policy draft for more information). Also, if you use this tag, make sure the issue component is set to the correct subsystem. If an issue significantly impacts more than one subsystem, use needs framework manager review instead.

  • Needs framework manager review

    It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

  • Security

    It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

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.

  • Comment almost 2 years ago →
    🇺🇸United States smustgrave

    Moving to NW as @catch requested in #179 what still needs happen (per the IS).

    Thanks!

  • Comment almost 2 years ago →
    🇺🇸United States xjm

    In addition to profiling, we need to rethink whether this table even makes sense as-is anymore. Does it make sense to have this index table? Should it instead be implemented at the entity relationship level in Entity Reference's APIs? Should it use EFQ or an abstracted storage model instead of plain DB queries? Etc. We should answer those questions before rerolling this on and on. Thence the framework and subsystem maintainer review tags.

    For now, I think the contrib module is sufficient for the immediate needs of taxonomy-related contrib or custom code. In the long term, IMO we need an entity-reference-level approach.

  • Comment over 1 year ago →
    🇺🇦Ukraine eugene.brit Kyiv 🇺🇦

    The #185 patch has not applied for 10.0.8
    re-roll this patch.

  • Comment over 1 year ago →
    🇧🇪Belgium herved

    I also got bit by this issue today.
    Similar to #150 when we unpublish a translation, the records in the taxonomy_index table get removed by taxonomy_node_update(), even though the original translation is unchanged.
    This is an issue in my case when using the "Has taxonomy term ID" contextual filter in views which adds an inner join to the query.
    The patch seems to resolve it.

  • Comment about 1 year ago →
    🇫🇮Finland joey-santiago

    I also got here looking for the bug mentioned in #150: when an unpublished translation of a node is saved, the entry for that is removed from the taxonomy_index table.
    In my case, the module Permissions by Term is using the taxonomy_index table to gather all the nodes a user is entitled to view. So suddenly nodes are removed from listings when unpublished translations are saved.

    From what i have tested, the patch works well. I especially like the fact that the database is updated putting back in place all the entries from unpublished nodes. The patch applies #198 to 10.1 too.

  • Comment 11 months ago →
    🇺🇸United States RichardDavies Portland, Oregon

    Can someone please reroll the patch for Drupal 10.2.0?

  • Comment 11 months ago →
    shweta__sharma

    Re-rolling patch for 10.2.0 version.

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update 11 months ago
    Patch Failed to Apply
  • Comment 11 months ago →
    🇺🇸United States RichardDavies Portland, Oregon

    @shweta__sharma Thank you, but the patch won't apply for me with 10.2.0:

  • Comment 11 months ago →
    🇩🇪Germany kreatIL

    The patch cannot be applied due to at least one issue: In Version 10.2.x, Line 228 (which corresponds to Line 208 in Version 10.1.x) has been modified. It now reads:
    keys(['nid' => $node->id(), 'tid' => $tid, 'status' => $node->isPublished()])
    It's important to note that the function is "keys" in Version 10.2.x, as opposed to "key" which was used in Version 10.1.x.

  • Comment 11 months ago →
    🇺🇸United States RichardDavies Portland, Oregon

    Updated @shweta__sharma's patch and changed key() to keys(). Patch now cleanly applies for me in 10.2.0.

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update 11 months ago
    Build Successful
  • Comment 10 months ago →
    🇺🇸United States tommyddp

    Tried the patch for 10.2.x and it applies cleanly for me but does not fix the issue and I still only see published content in my view.

  • Comment 4 months ago →
    🇨🇳China lawxen

    Reroll #206 for 10.3.1

  • Comment 4 months ago →
    🇩🇪Germany Anybody Porta Westfalica

    @quietone, @_nod and others: What do you think about the points made in #197 by @xjm?

    I agree with this in general terms, and I think it would be beneficial for the entity system in general. For Taxonomy terms (and other entity types) it might make sense to solve it in contrib with http://drupal.org/project/taxonomy_entity_index

    So I'd suggest to maybe close this and instead start with a fresh issue to solve this in general for entities as framework and not for taxonomy terms specifically?

  • Comment 4 months ago →
    🇩🇪Germany Anybody Porta Westfalica
  • Comment 3 months ago →
    🇨🇳China alfababy

    Reroll #208 for 10.3.2

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024