Hey there,
The project itself includes a detailed description on its goal and how it relates to other products while it does differ. Please see the sandbox: http://drupal.org/sandbox/Funke-Tom/1133180
- Related modules:
http://drupal.org/project/prev_next
http://drupal.org/project/custom_pagers
I'd appreciate any feedback and hope to see this become a full project.
Cheers,
Tom.
| Comment | File | Size | Author |
|---|---|---|---|
| previous-next.jpg | 25.29 KB | trothwell |
Comments
Comment #1
trothwell commentedSorry i forgot to mention that the Coding Module, may return a critical error due to the way I've included a variable within the query to act as a modifier (< >). This shouldn't be an issue.
Comment #2
joachim commentedAs you state on the sandbox page there are two projects already that provide this sort of thing -- custom pagers and previous/next API.
You've also given a number of reasons for developing this, but I'm not sure they're all valid:
1) This supports Multiple sites, if a node is only accessible on one domain it wont display a link to it unless you're browsing on that domain.
2) Cron isn't required.
3) Published nodes only - The Previous/Next API module has a bug open. #1074338: Unpublished nodes are treated as published.
4) Easy to use and style.
5) Allows additional CCK fields to be outputted via the tpl file.
1) is a missing feature in either of the two existing modules.
2) sounds like a design flaw to be fixed
3) is a bug to be fixed -- that's never a reason to start a new project.
4) likewise.
5) I don't really understand.
Comment #3
trothwell commentedHey thanks for the reply and taking the time to look at the project.
1) True, these other modules don't support this. This was the main reason why i developed the module. I believe making the module not rely on Domain Access and still run on single sites appeals to more users.
2) Cron isn't needed to index and node listings as a direct query against the node table is done, I wouldn't personally consider this a design flaw. But i'm open for suggestions?
3) Very true, probably should reconsider the description on the project page so it's not aimed at bugs within other modules.
4) Always a great feature of any module. It's obvious users want to be able to customize the output the way they want.
5) A good example with this point is:
You have a standard image gallery on your website using the Image Content Type. You install this module which adds previous and next functionality but you want a little bit more outputted such as the image of the next and previous node next to the links. Other examples could include custom teaser text or a custom link, these would of course all vary based on what's available within that content type.
Cheers.
Comment #4
joachim commentedMy point is that missing features can be added, and bugs can be fixed, and theming capability can be improved.
> You have a standard image gallery on your website using the Image Content Type. You install this module which adds previous and next functionality but you want a little bit more outputted such as the image of the next and previous node next to the links
That's already doable with Custom Pagers.
> 2) Cron isn't needed to index and node listings as a direct query against the node table is done, I wouldn't personally consider this a design flaw. But i'm open for suggestions?
You're saying your module doesn't need cron. To me that implies you consider use of cron a design flaw in the other module. Design flaws can be fixed.
Comment #5
trothwell commentedThanks for the fast reply...
All true, I've added all this functionality feeling as though It was needed as a base to support previous/next on Domain Access, theres functionality mixing from both Custom Pagers and Previous/Next API. I guess you could say I'm trying to grab the best from each and provide even more features.
While bugs can be raised not all tickets are actioned within a time needed which is understandable, no one can dedicate the majority of their time purely to a single module. The maintainers of the module also need to consider suggestions if they feel they are valid to add to the project theres always a chance of rejection.
This is what I required and i feel that i should share and maintain it with the community.
I wouldn't consider Cron a design flaw at all, theres different ways to go about achieving a goal, mine just happened to be not using Cron. (While most users would have this functionality enabled on their server some may not).
As i said before i should probably reconsider the description on the project.
Comment #6
trothwell commentedI've updated the description of the module to not be aimed at other modules missing functionality and/or bugs. I've also provided an example.
http://drupal.org/sandbox/Funke-Tom/1133180
Comment #7
joachim commentedI took a look at the actual code of this recently, and it turns out this module is doing way less than Custom Pagers. That lets you use Views to order your nodes in any way you want.
In your module, you're limited to node ID and creation date:
This seems terribly limited to me.
Comment #8
trothwell commentedThanks Joachim for taking a look, appreciate it.
I don't want to appear rude but if I may quote yourself:
You're right it is limited... this would be a good enhancement I could work on in the future.
Cheers,
Tom
Comment #9
trothwell commentedFixed an error that would occur when not using the Domain module. Please see commit: http://drupalcode.org/sandbox/Funke-Tom/1133180.git/commit/0ddfa6b
Thanks! Hoping the module will still be considered for approval as I'm about to start enhancements within the coming days.
Comment #10
trothwell commentedOnce again i've updated the project description to include examples of a site running Domain Access with the use of the Domain Previous/Next module.
http://drupal.org/sandbox/Funke-Tom/1133180
Comment #11
joachim commented> theres functionality mixing from both Custom Pagers and Previous/Next API. I guess you could say I'm trying to grab the best from each and provide even more features.
My take on this remains that this module is reproducing functionality that's available is a more generic module that has wider support and more flexibility. Drupal as a whole is better served by effort being put into the more reusable system rather than everyone working in their separate corner.
Comment #12
trothwell commentedI've taken into account your view and created issues within both modules to see if the contributors believe the functionality should be added.
http://drupal.org/node/1189870
http://drupal.org/node/1189868
I'd be more than happy to contribute code towards these modules, this could potentially mean this work doesn't goto waste or at least the idea.
Cheers.
Comment #13
attiks commented@Funke-Tom: a quick tip, do motivate the module owners to consider your request, you can right a patch to implement it, it looks like you have the right skills it needs.
Comment #14
trothwell commentedThanks attiks, definitely considering it when i have a spare moment.
Comment #15
misc commentedThe applicant has been contacted to ask if the application is abandoned.
Comment #16
misc commentedThe application has been closed. If you would like to reopen it, you are free to do so.
See http://drupal.org/node/894256