Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

The problem is that this data is not in the database so you would have to write a field handler and count the amount of revisions.

NancyDru’s picture

That's what I was asking the maintainers to do. If I understood Views code, there would be a patch attached.

esmerel’s picture

Category: feature » task

Moving this to a task - if someone wants to make a patch for it, have at it.

dawehner’s picture

Status: Active » Needs review
FileSize
1.92 KB

Here is a patch

DarrellDuane’s picture

Hi Dereine,
Thanks so much for setting this up. It seems to be working well for me, but when I add or edit the revision count field that I created, I get this error message:

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') GROUP BY nid' at line 1 query: SELECT nid, COUNT(vid) as count FROM node_revisions WHERE nid IN () GROUP BY nid in /sites/all/modules/views/modules/node/views_handler_field_node_revision_count.inc on line 14.
Backtrace:
trigger_error(array)[database.mysqli.inc:128];
._db_query(array:a:1:{i:0;s:80:"SELECT nid, COUNT(vid) as count FROM node_revisions WHERE nid IN () GROUP BY nid";})[database.mysql-common.inc:42];
..db_query(array:a:1:{i:0;s:82:"SELECT nid, COUNT(vid) as count FROM {node_revisions} WHERE nid IN () GROUP BY nid";})[views_handler_field_node_revision_count.inc:14];
...pre_render(array:a:1:{i:0;a:0:{}})[view.inc:857];
....render(array:)[views_plugin_display.inc:1880];
.....preview(array:)[view.inc:945];
......preview(array:a:2:{i:0;s:7:"default";i:1;a:0:{}})[admin.inc:387];
.......views_ui_preview(array)[?:?];
........call_user_func_array(array)[menu.inc:348];
.........menu_execute_active_handler(array:)[index.php:18];
..........index.php
dawehner’s picture

Status: Needs review » Needs work

Can you export your view, please?

In general this patch needs work.

DarrellDuane’s picture

FileSize
15.85 KB

Here it is. I'll see if I can get some time to debug it shortly.

dawehner’s picture

Status: Needs work » Needs review
FileSize
1.92 KB

Please test this version of the patch.

dawehner’s picture

Status: Needs review » Needs work

This is still the old one.

dawehner’s picture

Status: Needs work » Needs review
FileSize
1.96 KB
DarrellDuane’s picture

This new patch in #10 is working nicely for me, dereine. Thanks! I suggest that if it works well for someone else that they mark it as reviewed & tested by the community.

bojanz’s picture

Status: Reviewed & tested by the community » Needs review

Edit: No, I was wrong.

bojanz’s picture

Status: Needs review » Reviewed & tested by the community
merlinofchaos’s picture

Status: Needs review » Reviewed & tested by the community

Quick question: Should the revision count include the current revision:

If there are no revisions, there will be 1 revision.

If there is the original revision and the current, there will be 2 revisions. Is this the number we want to display?

dawehner’s picture

What about make a configuration whether the current version should be included or not.

NancyDru’s picture

Well, if we look at core, then consider that until a revision is actually made, there is no revision tab on the node. However, once that is made, there are two rows displayed, which includes the current one. So, depending on how one counts, an option makes sense to me. Personally, I would skip one as a possible count: 0, 2, 3, 4, ...

merlinofchaos’s picture

Every possible scenario I can think of is going to be confusing:

Saying there is 1 revision when, in fact, it is only the initial revision is definitely confusing.
WHen there are 2 entries in the table, either 1 or 2 is going to be depending on what you expect; if you expect it to count entries, then 1 is confusing. If you expect it to count the number of times the content has been revised, then 2 is confusing. Whee!

Will spend some time pondering which way is better. Weigh in if you have thoughts. I have a thing for consistence, so counting 0, 2, 3, ... just feels wrong as well, but it might be the right way to go.

dawehner’s picture

If you make the first entry configurable you can achieve afaik every configuration together with the math expression field.

NancyDru’s picture

As shocking as it may sound, I agree with Earl. I am not saying that core is the ultimate in consistency, just pointing out how it works.

Perhaps the root problem is is my original wording of "revision count." The original node is the 0th revision; the next one would be the 1st revision. However, the original node is the 1st version and the next is the 2nd version. So, perhaps the solution is to identify the field as "version count" rather than "revision count." This would allow a simple SELECT COUNT(vid) FROM {node_revisions} WHERE nid = %d (Views-ized, of course) to provide the field value.

DarrellDuane’s picture

I started to post something like NancyDru #19, and stopped because I thought that Drupal, in general, talks about revisions and not versions of nodes. But I'd rather see this thought of as a Version count, or at least be given the option to choose between Versions and Revision count display.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Needs work

I agree with #19. If we call it 'version count' then things work well. Moving to 'needs work' on that basis, but it should be an easy reroll.

dawehner’s picture

Status: Needs work » Needs review
FileSize
1.99 KB

Here is a rerole. Renamed everything to version_count.

Alex Andrascu’s picture

Nice one...this isn't working for views filters yet isn't ?

dawehner’s picture

Version: 6.x-2.11 » 6.x-3.x-dev

Right this would require quite some other work.

Update version as this will not happen on 6.x-2.x

DarrellDuane’s picture

I have tried applying this patch to Views 6.x-2.16 but it breaks in two places:

patch -p0 < 959048-revision_count_1_0.patch 
patching file b/modules/node.views.inc
Hunk #1 FAILED at 403.
Hunk #2 FAILED at 702.
2 out of 2 hunks FAILED -- saving rejects to file b/modules/node.views.inc.rej
patching file b/modules/node/views_handler_field_node_version_count.inc

This is a helpful patch just for supporting fields, it would be great if it could be fixed for 6.x-2.16 and tested and rolled into Views even if we didn't have filters support.

dawehner’s picture

You should use patch -p1 when appying a patch.

rooby’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
FileSize
2.22 KB

Here is a drupal 7 version of the patch in #22

rooby’s picture

Here is a version that also has a sort handler.
Works for my brief testing.

rooby’s picture

When I get a chance I will also add a filter as it would be useful to be able to restrict based on number of revisions.

I must say I'm not a huge fan of the use of version instead of revision.
I guess it makes sense it's just my mind doesn't like it not being revision like everywhere else.

rooby’s picture

Is there a reason this field is done in the rendering phase?

The reason I ask is that when you want to do some more comples things in views preprocess functions, the values for this field are not in the $view->result array.

rooby’s picture

Assigned: Unassigned » rooby
FileSize
5.71 KB

Here is a new version that also includes a filter handler.
So now we have field, filter and sort.

I've just been chipping away at it when I need it but I will do a proper review soon, including investigating #30.

Status: Needs review » Needs work

The last submitted patch, views-node_revision_count-959048-31.patch, failed testing.

rooby’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, views-node_revision_count-959048-31.patch, failed testing.

rooby’s picture

Not sure what the deal with that is.

I will check it out a bit later when I re-review this patch

rooby’s picture

Status: Needs work » Needs review
FileSize
5.6 KB

This patch changes the field implementation to override the query instead of the rendering.
This means users hooking into other views hooks and preprocessors can see the value in the results.
It also means I could add click sorting.

I have also now tested this on a clean Drupal install and it works fine.

Status: Needs review » Needs work

The last submitted patch, views-node_revision_count-959048-36.patch, failed testing.

rooby’s picture

Status: Needs work » Needs review
FileSize
5.57 KB

Try this one.

cecrs’s picture

Status: Needs review » Reviewed & tested by the community

Patch #38 worked beautifully for me, thanks Rooby!

lohithsunchu’s picture

Patch #38 worked for me, its sexy & awesome , thanks Rooby :-)

pyry_p’s picture

#38 works when the field handler in view is in view entity type node.
When using this code from the patch in view thats base entity type is something else it breaks.

I have bit of edge case, but patch doesnt seem to count possibility of base entity is something else than node.

My use case setup:
View for profile2 where uid is contextual filter.
Getting "parent_nodes" from entity reference field in the profile.
Getting all child nodes referencing the parent_node.

Check if child has more than one revision.

This contains slight modification to #38.

Leeteq’s picture

Assigned: rooby » Unassigned

Ideally, this should be entity agnostic. Given the central role of Views in almost all projects, it would be practical if this feature enable us to count revisions on any entity.

rooby’s picture

Generally speaking I would agree with you that we should make things more generic but in this case I think we should make it work in the same way views already works.

That is, keeping node revisions separate and in views and doing any generic entity solution in the Entity API module.

colan’s picture

We've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.

If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.

We apologize for the trouble, and appreciate your patience.

colan’s picture

Status: Reviewed & tested by the community » Needs work
joelpittet’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
5.57 KB

Reuploading previously RTBC'd #38. #40 attempt to make it more generic still has nid, which would fail beautifully if the base table was not node. Ripe for a follow-up if you want to DRY it up.

  • colan committed 22d2ebc on 7.x-3.x authored by rooby
    Issue #959048 by rooby, dawehner, joelpittet, pyry_p: Added a revision...
colan’s picture

Title: Revision count » Views revision count
Project: Views (for Drupal 7) » Drupal core
Version: 7.x-3.x-dev » 8.1.x-dev
Component: node data » views.module
Category: Task » Feature request
Status: Reviewed & tested by the community » Patch (to be ported)

Thanks! Please open any follow-up issues in the core D8 queue, not the D7 one. Features can be back-ported to D7 once complete in D8.

dawehner’s picture

In Drupal 8 we ideally implement that generically for any entity type.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

catch’s picture

Status: Patch (to be ported) » Needs work

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

awm’s picture

@dawehner, I came across this issue and was going to start working on porting this to d8 for nodes until I saw your comment. Do you have any advice on a proper approach to make the field generic for all entity types?

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.