Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By teneighty on
I created a new module called "Story List" for my site, and I'm wondering if there's any interest in it making it available for others to use.
The purpose of the module is to provide functionality similar to Slashdot's story browser. It displays a list of stories, showing only the first 150 characters. The user can choose to only view stories associated with a specific term.
A sample of it in action can be seen here: http://classfivenews.com/story_list (it is normally accessed on my site by clicking the "old stories" link located in the upper part of the right column).
Comments
This seems to be very
This seems to be very similar to the already existing articles module(as seen here) in many ways; although you can apply more than one taxonomy to it, which is what limits the articles module.
Although I can see why someone might chose your story browser; its inherent funtions are slightly different. What sort of back end configuration is there? Can we chose what taxonomies to display? Can we chose a depth of taxonomy to display?
----------------
I R Admin Monkey. Damn those users. Damn them with Zim like hyperbole
Taxonomy Depth
Right now, the code just assumes that each vocabulary is flat (i.e. the vocabulary is just a set of terms) since this is how my site is set up.
However, I would be happy to modify the code to deal with taxonomies with any depth - and I can see this would be neccessary for general usage.
There are no admin hooks at this time, but again that's a feature I could easily add. If one wanted to limit the vocabularies to display, then I guess that would imply that you would want to filter out any stories associated with those vocabularies so they never get displayed on the story_list page?
Please submit patch to existing module
It's great that you've written something useful and that you're sharing it--thanks! But if you're thinking of making this part of the drupal.org hosted contributions repository, you should really start with the existing module that does much of what you propose. As contributors, the onus is on us to make sure we first try to improve existing modules. Otherwise, we get a proliferation of slightly different modules that do the same basic thing, leading to duplication and, especially, confusion for users.
Is there a demand for this?
I'm cautious about the idea of patching the existing articles module, because I don't think it would be appropriate for me to change the functionality of that module just because I happen to want some specific features - i.e. there may be specific reasons for the current article module's functionality that I'm not aware of.
I think it would be better to have some more input from people that currently use the articles module, to see if they want this functionality as part of the articles module or not.
why not?
Why not? Can this be done as a configuration option that extends the current article module? If so, then submit the patch and see what the responses are. The worst that could happen would be a polite no, the best would be feedback and an extension of the existing one with more developers focusing on it.
Or perhaps if this could be done as an add on module that requires the articles module. Similar to how image_filter extends image.module
-sp
---------
Test site...always start with a test site.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide