First, a belated THANK YOU for writing this module. It rocks -- this is the module I would write, if I could write modules.

I would like to suggest integrating support for the node moderation module to track the popularity of nodes based on moderator votes. My reasoning reflects the 'social software' facet of Drupal. I run a site where registered users are encouraged to post stories to the front page. The difficulty in this is that sporadic participation makes it difficult to persuade users (outside of simply telling them outright) that their contributions to the site are appreciated. There is nothing quite as deflating as putting in the effort to submit content only to find that nobody has actually commented on it.

Drupal's ability to count reads offsets this, slightly, since it allows a rough estimate of node popularity using HOF, but the inclusion of node popularity based on moderator votes might provide a more accurate reflection of reader response, since Drupal does not actually track unique views based on IP or anything (I'm debating submitting this functionality as a feature request, but honestly, how many people have successfully configured Drupal to even rate comments in a meaningful way? ;)

I'd considered just opening up HOF and hacking this in on my own, but I figured since this was pretty closely aligned with what you'd already done, this might be a feature you'd like to consider adding on your own (and then I don't have to worry about patching hof every time i update Drupal)...

Comments

syscrusher’s picture

syscrusher commented

Hello, Max, and thanks for the kind words about the HOF module.

I find what you suggest interesting. I will admit that my ignorance of comment-based moderation prevents me from fully understanding the significance of what you propose, but that doesn't mean I'm opposed to the idea. As you know, we all use Drupal in different ways; in my particular case, the comments and forums modules are incidental to the site rather than being a main feature.

I deliberately built HOF with separate pages and with a way to dynamically integrate them into the permissions system and the module's internal table of contents, with the idea that the module could eventually be extended to include other statistics. Since the site owner can individually enable or disable each subsection of HOF, there is little harm in adding more as long as the quantity doesn't get totally out of hand.

All that being said, I can see two ways forward: First, if your idea depends only on things that are in core Drupal, I would definitely consider adding it into the base HOF module. If it depends on non-core modules, but the non-core features are extremely popular (as image.module is), I might still consider it for HOF's base feature set, with module_exist() logic around it as I've already done with some other features.

If your idea uses external modules that aren't in that category, then I'm still interested. One feature that I have already planned is to allow HOF to be extended with auxiliary ".inc" files, along the lines of the way flexinode.module works. In fact, what I'd like to do is to implement a global hook {module}_hofapi(), akin to {module}_nodeapi(), that allows any module to define a module-specific HOF page. Unfortunately, I'm deeply embedded in some other Drupal development right now and don't have time to work on HOF other than bug fixes.

If you've got the time to code up what you propose, I am certainly willing to consider the patch. For that matter, if you want to take a crack at the generic extension interface, feel free to go for it. I do recommend that we exchange email addresses (use my "contact" page to send yours, and I'll reply back to you by email so you'll have mine) before you spend a lot of time coding, so that we can sync up on architectural planning. One thing that I feel strongly about is the desire to keep HOF (at least, its base features) compatible with Drupal 4.5 and 4.6, so that I don't have to maintain two code bases. Right now, 4.5 and 4.6 versions are totally identical except for their respective CVS "$Id$" lines.

Thanks again for your comments and your suggestion. It sounds like a good one.

Scott

syscrusher’s picture

syscrusher commented

By the way, I don't want to replace the existing popularity-by-read-count computations, because for my own sites that's exactly what I need. I run one site that has over 3000 nodes online, and a grand total of just a couple hundred comments over a 2.5 year lifespan. If I tried to have that site rate nodes' popularity by comment count, it would be a flatline. But our reads per node range from just a few dozen all the way up to several thousand.

I'll admit this falls in the category of "scratching my own itch", but that's kind of what Open Source is all about, and also, I can't imagine that my site is the only one of its kind in the world.

I'm not meaning to imply that you proposed replacing the existing feature; I wasn't 100% sure, though, and thought it best to clarify. Let's add your feature as an additional option.

Scott

syscrusher’s picture

syscrusher commented
Assigned: Unassigned » syscrusher

Hi, Max

I'm sorry not to have gotten back to you sooner. I didn't realize this issue was still open.

I think I've actually been working on this one as part of another issue, without realizing they were connected. Please take a look at issue #28898 (http://drupal.org/node/28898) and see if the part about checking the "moderate" bit will also meet your request on this issue. If so, I'll close this one and continue to work under the other issue.

Note (per #28898) that the new code isn't quite done yet; I will hopefully have another patch in a few days to finish the selection/tallying logic for moderated nodes.

Scott

Max Bell’s picture

Max Bell commented
Status: Active » Closed (fixed)