Provide a way to filter by content type

Thank you for the suggestion.

It is not possible to do this at the moment, but it is a very good suggestion and we will consider adding it to our next release. Would you want this to be the same for all services, or might you want a different set of content types for each service (viewed, email, etc)?

Another vote for this feature. Drupal 7 version of it is much anticipated.

filter by different content types, would be an ideal feature

hi , what would be great if the blocks would have views support. With views support you can than filter by contenttype or give it an argument.
My usecase is filter On the taxonomy term and show in this block only the popular nodes relad to the tem at hand.
Greetings, Martijn

That's also a good suggestion, though we'd have to think carefully about how the views integration would work (passing params and such).

In our next release, we are hoping to allow multiple Most Popular blocks each with their own configuration, and planning to add hooks to allow different types of content (nodes, taxonomies, etc) to be configured for each block. I believe this combination of new features would fulfill the use case, although a more dynamic solution, such as using views to render the content, may be preferable.

Hi Andrew, That sounds awesome allready!
Looking forward to that release! Hopefully also already argument based, so when the url is taxonomy/term/10 [tid=10] then the block will be triggered to shwo the popular nodes related to tid 10?

greetings, Martijn

Currently, the Most Popular widget downloads all of the most popular items from the various services as part of a cron job, and caches them in the system. Only the maximum number of items needed to display in the block are stored.

In order to support dynamic URLs within the block, we would have to know when the cron runs which terms we may be filtering on and fetch just those items, or download all items that may potentially match any of these terms and then filter on the fly. The latter would mean caching much more data than we might ever display. It would also mean we'd have to store filter criteria along with the items themselves, or at least have a simple way to join with the appropriate tables. This would add a great deal of complexity and would be much more difficult to configure...

Hi,
May be moving to views removes lots of the complexity, but I am not a good enough programmer to tell.
Thanks for your quick update!
greetings, Martijn

+1 for views support

+1, please update D6 version too with this feature!

+1 on Views support

Our recently-released Drupal 7 version of the Most Popular module adds support for any type of entity. Each time you configure an analytics service, you can specify which types of entities and bundles you would like returned from that service. You can also now add a service more than once; each with different configurations.

However, while full entity support adds a great deal of flexibility in mapping to your site's unique structure, it also makes views integration more difficult. While it is possible to join a particular Most Popular item to a particular entity table, it is very hard to do in the aggregate, because entity records can be stored in any table. So any views integration would pretty much have to be limited to the mostpopular_item table.

But please check out the new Drupal 7 version of the module and let us know what you think.

Martijn,

Going back through this thread, I realized this still does not resolve your particular use case, though. It appears that you would like to fetch metrics for all the most popular nodes and display the top N that are tagged with a particular taxonomy. The way we've built this out, it fetches the top N nodes as part of a cron job, but discards metrics about the other, less popular nodes. To make it work the way you'd like (or the views integration with arguments mentioned elsewhere in this thread), it would basically need to store metrics for every node or entity in the system. We could expand it to do this, but would likely hit API limitations on the number of requests within a given period of time. Plus, we would still need to have a way to join the most popular metrics with the table for any entity. I'll think about this some more...

any development on content type filtering on D7?