Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
If this is VBO, feel free to move it.
I would like to have a node revisions count (much like comment count).
Comment | File | Size | Author |
---|---|---|---|
#46 | views-node_revision_count-959048-38.patch | 5.57 KB | joelpittet |
| |||
#41 | views-node_revision_count-959048-41.patch | 5.58 KB | pyry_p |
#38 | views-node_revision_count-959048-38.patch | 5.57 KB | rooby |
#36 | views-node_revision_count-959048-36.patch | 5.6 KB | rooby |
#31 | views-node_revision_count-959048-31.patch | 5.71 KB | rooby |
Comments
Comment #1
dawehnerThe 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.
Comment #2
NancyDruThat's what I was asking the maintainers to do. If I understood Views code, there would be a patch attached.
Comment #3
esmerel CreditAttribution: esmerel commentedMoving this to a task - if someone wants to make a patch for it, have at it.
Comment #4
dawehnerHere is a patch
Comment #5
DarrellDuane CreditAttribution: DarrellDuane commentedHi 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:
Comment #6
dawehnerCan you export your view, please?
In general this patch needs work.
Comment #7
DarrellDuane CreditAttribution: DarrellDuane commentedHere it is. I'll see if I can get some time to debug it shortly.
Comment #8
dawehnerPlease test this version of the patch.
Comment #9
dawehnerThis is still the old one.
Comment #10
dawehnerhttp://drupal.org/node/959048
Comment #11
DarrellDuane CreditAttribution: DarrellDuane commentedThis 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.
Comment #12
bojanz CreditAttribution: bojanz commentedEdit: No, I was wrong.
Comment #13
bojanz CreditAttribution: bojanz commentedComment #14
merlinofchaos CreditAttribution: merlinofchaos commentedQuick 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?
Comment #15
dawehnerWhat about make a configuration whether the current version should be included or not.
Comment #16
NancyDruWell, 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, ...
Comment #17
merlinofchaos CreditAttribution: merlinofchaos commentedEvery 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.
Comment #18
dawehnerIf you make the first entry configurable you can achieve afaik every configuration together with the math expression field.
Comment #19
NancyDruAs 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.Comment #20
DarrellDuane CreditAttribution: DarrellDuane commentedI 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.
Comment #21
merlinofchaos CreditAttribution: merlinofchaos commentedI 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.
Comment #22
dawehnerHere is a rerole. Renamed everything to version_count.
Comment #23
Alex Andrascu CreditAttribution: Alex Andrascu commentedNice one...this isn't working for views filters yet isn't ?
Comment #24
dawehnerRight this would require quite some other work.
Update version as this will not happen on 6.x-2.x
Comment #25
DarrellDuane CreditAttribution: DarrellDuane commentedI have tried applying this patch to Views 6.x-2.16 but it breaks in two places:
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.
Comment #26
dawehnerYou should use patch -p1 when appying a patch.
Comment #27
rooby CreditAttribution: rooby commentedHere is a drupal 7 version of the patch in #22
Comment #28
rooby CreditAttribution: rooby commentedHere is a version that also has a sort handler.
Works for my brief testing.
Comment #29
rooby CreditAttribution: rooby commentedWhen 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.
Comment #30
rooby CreditAttribution: rooby commentedIs 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.
Comment #31
rooby CreditAttribution: rooby commentedHere 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.
Comment #33
rooby CreditAttribution: rooby commented#31: views-node_revision_count-959048-31.patch queued for re-testing.
Comment #35
rooby CreditAttribution: rooby commentedNot sure what the deal with that is.
I will check it out a bit later when I re-review this patch
Comment #36
rooby CreditAttribution: rooby commentedThis 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.
Comment #38
rooby CreditAttribution: rooby commentedTry this one.
Comment #39
cecrs CreditAttribution: cecrs commentedPatch #38 worked beautifully for me, thanks Rooby!
Comment #40
lohithsunchu CreditAttribution: lohithsunchu commentedPatch #38 worked for me, its sexy & awesome , thanks Rooby :-)
Comment #41
pyry_p CreditAttribution: pyry_p commented#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.
Comment #42
Leeteq CreditAttribution: Leeteq commentedIdeally, 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.
Comment #43
rooby CreditAttribution: rooby commentedGenerally 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.
Comment #44
colanWe'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.
Comment #45
colanComment #46
joelpittetReuploading 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.
Comment #48
colanThanks! 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.
Comment #49
dawehnerIn Drupal 8 we ideally implement that generically for any entity type.
Comment #52
catchComment #56
awm CreditAttribution: awm commented@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?