Exposed Filter Filtering on Unpublished Revision

Question

I have a content type with a massive number of fields. The primary way this data is seen is through a view with several exposed filters (looking at the fields) which provides a list of matching records. I have installed the revisioning module in order to provide drafts.

The issue I'm running into is that the filters are looking at the most recent (unpublished) revision which doesn't match the published data.

The exact problem I'm running into:

There is a published product which is marked as energy star compliant (field on a node). The new version of this product is not energy star compliant, but it has not been released yet (unpublished revision under moderation).

When users filter for only energy star compliant products (using the exposed filter) this product is not displayed. When they do not filter the product is displayed, and it is shown as energy star compliant.

What I've tried:

I haven't made much headway. I've discovered that drupal is saving the unpublished field data in the "field_data_field_..." tables, which is what I expect the filter works off of. The published data is in the "field_revision_field_..." tables.

The node table stores the vid of the most recent revision, not the published one.

I logged all of the SQL and saving the unpublished revision updates the field_data tables and saving the published revision does not.

Deleting and creating a new revision does not fix the issue.

Creating a new published and a new unpublished revision doesn't help.

The issue occurs on multiple nodes not just one.

I cannot find any settings in views, the view, revisions, or any other location that appear relevant.

What I suspect:

I'm guessing I have interference happening between modules. There are so many modules on this site that I do not have time to trace through the code and figure out what is actually happening, and there are over 60 modules enabled. My next step would be to start disabling modules but I did not build the site and I do not have the time-budget to figure out what all of these modules do and get the site working well enough without them to test if this behavior is the same.

My linux background says that this is a permissions issue (it's always a permissions issue).

My option at this point is to write a script outside of drupal (I'm not seasoned enough to know how to do this in drupal) that goes into the database and puts the correct data in there manually from the revision table. I don't want to do this, it's a bad idea and would be hell to maintain.

Any insight into what to try next would be very helpful.

Answer 1

After figuring out the magical combination of keywords (it's "views filter exposed content revision") I found someone with the same problem:

"Unpublished data belongs to the latest revision of a content type is accessible for querying by the Views module"

https://www.drupal.org/node/2098211

Drupal user fbrooks replied:

lavms,

I don't think modifications to the Revisioning module are necessary to address this.

I was dealing with, what I believe is, a similar issue. I have a content type with a boolean field used in a filter in a view such that a node will appear if the field if set to true. When you create a node revision under moderation that has the boolean field set to false, the node would be filtered out of the view before the revision is published.

I was able to address this by recreating the view and selecting "Content revisions" instead of "Content" from the "Shows" drop down list on the new view page. This results in node_revision instead of node being used as the base table, and automatically adds a join between the node_revision and node table on vid. When selecting fields for display or filtering I used the ones that begin "Content (historical data)", which results in the values from the field_revision_* instead of field_data_* tables being used. All these things combined resulted in the correct revision being used by the filter.

Hope this helps.

Frank

This is the "core view" of the site and is quite entrenched so recreating it will not be simple, but it has turned from an unknown problem to a known and solvable one.

Thanks sareed for your help.