Content type -specific settings for received energies
guardian - April 16, 2008 - 02:36
| Project: | Radioactivity |
| Version: | 5.x-1.1 |
| Component: | Documentation |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
i would have liked to have a decay profile per content type
that would allow me to build a view that lists all the published node from a reduced set of content types and compute their radioactivity then pick the 5 more radioactive ones thanks to sorting by descending radioactivity
with the current way the module is done, this would mean create 1 decay profile per content type concerned, 1 view per content type concerned, and finally a union of the views sorted by descending radioactivity

#1
#2
I'm not sure I understand correctly your wishes, but... Can't you just use "Node Type / One of" filter in your view to accomplish that? And then sort by descending radioactivity?
The decay profile is really intended for different decay rates.
#3
#4
i want to have in the same view, nodes from different content types, sorted by descending radioactivity
at the moment, it's possible to do it but all the nodes will be applied the same decay profile whereas i wanted something like: "make article nodes more radioactive than blog posts so that they stay longer in the top of the list" in other words "make article nodes radioactivity decay slower than blog posts radioactivity"
see what i mean ?
#5
#6
ok i gave a try at a patch that in fact enables to add different amounts of energy depending of the content type inside the same profile
once applied, you'll see on the decay profile admin page that there are now 3 amounts (view, comment_insert, comment_publish) per content type displayed
by having different amounts of energy for different content types, i manage to achieve that an article stays radioactive longer than a blog post because there is more energy added to it. according to me, it makes sense to have article staying radioactive longer because the period of time while they are valid is larger than blog posts.
anyway, now that i'm writing this, i feel like half-life and cut-off could also be made per content type, inside a same profile (and this could be part of a second patch if you find this one useful)
tell me what you think
cheers, g
please note that this patch also contains my two other fixes: http://drupal.org/node/251651 and http://drupal.org/node/251656
#7
attached screen shot of the new decay profile admin screen for energy settings
#8
Thanks for the patch. I think it needs an extension for two reasons:
we serve mostly cached pages.
So, I'm thinking about having a flag that enables/disables content type specific settings per energy profile. That should suit for your and my requirements.
I'm going to make a new patch in a day or two.
#9
wonderful, indeed having a flag to enable / disable this makes a lot of sense
i think the flag needs to be attached to the decay profile though so that one decay profile can use the same values for all the content types while another profile can be tuned more accurately
#10
Please try the attached patch. I renamed the title, because this issue is about received energy per content type, at least currently.
If I get positive testing feedback I'll commit this patch. Please, could you tell whether you have tested also comments or only views.
#11
works for me
maybe you could always display the form elements for the per content type settings and make them collapsed by default (the way i did it first)
with your new "by content type" checkbox, values won't apply until there is a check mark
what do you think ?
#12
i only tested views btw
#13
I think I'll prefer keeping it the way it is, because this way we get reasonable defaults when toggling 'Content type specific settings' checkbox. However, we could think of making the whole energy settings fieldset collapsible, but then there are few usability issues in when to make it collapsed by default and when not. But perhaps that's another issue.
Committed radioactivity-module-247212-10.patch:
http://drupal.org/cvs?commit=114772
Guardian, thanks for the help to make this module better!
#14
you're very welcome, was a pleasure
#15
Automatically closed -- issue fixed for two weeks with no activity.