Node Count for D7 Version (patch included)

Good job Schnitzel! it works! thanks

this works, but when depth is used the count doesn't include children. "display descendants" was the setting in d6, but d7 does not have this yet #785892: D7 API Changes

This patch assumes that every node will have the same node access permissions. More often then not this isn't the case and the counts will be different between users depending on permissions and roles. This is the underlying problem regarding this issue and it's why I'm hesitant to commit anything related to it.

i don't think that drupal 6 accounted for the "counts (being) different between users depending on permissions and roles." This is a great idea though! Perhaps you should just release it with the basics for now, then open up a new issue to add Counts Per User Access.

Another extension could be to limit counts by specific node types (for ex. you have an online store that uses the same taxonomy as your training & resources content type. Stores would generally only link to the actual products through the taxonomy pages, while using the resources for supplemental materials. Only counting products is ideal in this situation.)

To make all these features work best we would probably want to allow multiple instances of taxonomy menus per individual taxonomy (the path mechanism will come in handy here for a more feature-filled party).

http://drupal.org/project/menu_token Menu Token may be the best way to achieve a lot of this. Menus are generally static, but this module changes that.

Tokens
1) Count Overall
2) Count Per User Access
3) Count Per Content Type(s) (May be combined with #1 or #2)

___EDIT__
The count should also take into account the depth of the taxonomy. Maybe have 2 options
- count of term only
- count of term & children

so the potential types of counts include
1) Access Counts (overall OR per user access)
2) Depth Counts (term OR term + children)
3) Content Counts (overall OR per content type(s))

This would make a lot more tokens, since these can create a vast # of combinations. Though these tokens would be very valuable to use throughout the site. Maybe make it a sub or a new integrated module: Taxonomy Term Counts (or tokens), then just use the basic method listed at the top of this thread in the taxonomy menu core & force users to download another module to extend it

Subscribing.

Just curious if testbot will queue this or not.

Changed patch paths...

Wouldn't be easier to use term_node_count tag in the query?

Example:

  $query = db_select('taxonomy_index');
  $query->condition('tid', $term->tid);
  $query->addTag('term_node_count');
  $count = $query->countQuery()->execute()->fetchField();

This is the way core uses, and IMO it's better for performance.

Oh wow. I didn't realize how cool the addTag method is... this opens up some doors. Also, I just noticed that line 120 of modules/taxonomy/taxonomy.tokens.inc in core provides a token. The suggestion in #5 is extremely viable.

subscribing

- The query should probably use EntityFieldQuery to support other field storage backends like MongoDB. If it doesn't, it could also well query the taxonomy_* tables directly.

- Also, the $display_num appending code is duplicated in the i18n related code, which is being fixed in #1228294: i18n support broken taxonomy_menu_translated_menu_link_alter errors. Either this issue or the other one needs to be updated depending on which gets commited first.

patch from #10 working like a charm from a purely functional stand point, thank you!
+1 commit for now IMO

The patch in #10 works for me.

Any way to get it to sort by count?

@16
Have a look at http://drupal.org/project/tagadelic for weighted presentation of taxonomy terms. The module comes with an API.

hth
Frank

subscribe

Hi, thank you for your work. Unfoturnately, the patch doesn't seem to be working for me. All the items are displaying (0), despite being tagged.

Re. patch #10.

Counts go up when adding nodes with attached terms, but counts don't go back down when deleting and unpublishing nodes.

@kolafson, this is exactly why node count is a bad idea. Menu items don't update as nodes are published and unpublished.

In general, we wouldn't want them to, in fact, the menu would have to rebuild itself after every post event. Similarly, counts won't change depending on different node access.

@kolafson,Perhaps this should be done as a Views display (or in menu block) :
- Views summaries/glossary shows a node count.
- There already exist Formats 'jump menu', (un)formatted list.
Perhaps you can create a hierarchical list (a la menu), an put it in a menu block, or even as a normal submenu.
Now this submenu is regenerated every time (so some caching is preferrable..).

@dstol, we do use a hook_node_insert(), perhaps a hook_node_publis exists?

@johnv, I'm thinking the best way to implement this would be to leverage menu token.

@dstol I'm not familiar with the menu token module. Could maybe elaborate how that would work? I have this problem right now as well.

I tried this patch but it didnt worked any other solutions or. working patch ?;/

What is the status of this patch?
IMO node count works in current -dev version.
The issue of "node count being one to high" (reported by Schnitzel, kolafson) when removing a node is solved with a one-line patch which is included in this patch, but also separately in #1509542: Node count not correct when moving node in hierarchy from A to B (count of A is not updated).

Schnitzel, Berdir,
does this patch fix/provide other issues?

I concur with johnv. Counts appear to be working as expected in the current -dev version.