In a forum, users expect to be able to subscribe to a thread. The user expects to be able to find a 'subscribe' link and when clicked the 'subscribe' link turns to an 'unsubscribe' link and you are now subscribed to the thread.

Additionally, I think there should be a settings option that allows you to place the 'subscribe'/'unsubscribe' link in the links for each of the comments as well. My users require this because they do not want to go looking if they decide they want to subscribe to a thread while reading it.

I build this functionality for the old subscriptions, but things got really complicated with the new version and I am not sure how to put this functionality together for my users with this version. If you can provide me with any guidance to get me going I can put together some code for this functionality...

Cheers...

Comments

michelle’s picture

Would it be possible to turn off the existing UI by node type? Not the ability to subscribe to that node type, but just the UI part. So say you have a site with blogs and forums and other stuff and you want the whole kit and kaboodle for most of your types but not in the forums. So you say don't show the UI there. Then I could include the more simplified subscribe link in the advanced forum code and it would just use that for any forum enabled node types. Does that even make sense? Sorry if it's crazy... I haven't looked deeply at subscriptions.

Michelle

salvis’s picture

@swill: Great — feel free to assign this to yourself! Give me some time to put the information together...

@Michelle: Hehehe, welcome to the complexities... Since D6 forums can hold a number of node types, but these node types can also exist outside of forums, node type may not be the right selection criterion. Maybe residing in a forum (blog? guestbook?)? Or having a specific vocabulary or term?

michelle’s picture

Well, I think at some point you just need to make assumptions. AF assumes that if you put a node type in the forum, you want it to look like a forum post. If you put your blog types in the forum, you're going to get forum looking blog posts. So far no one has complained. ;)

So I think going by node type would be enough. I don't think the UI needs to be complex. You already determine which node types could be subscribed to. It would just take an extra one that says "hide the UI on these node types". Once the UI is hidden, it's up to the admin to provide the UI for that type whether through their own code or a different module. So AF could provide a UI for subscriptions on forum nodes. Maybe some other module would provide one for blogs. This gives flexibility in how the subscriptions UI is presented without you doing all the work. All you need to know is if the included UI module should be showing the options on that type or not.

Michelle

salvis’s picture

I think using a hook would provide better control and scalability. Each UI module could state how badly it wants to provide its interface to the node in question, and the one with the greatest weight would win. This way the module-to-be-developed could provide a simplified "forum UI" for nodes inside a forum and leave the standard UI for the same node types when they're not in a forum.

michelle’s picture

Ah, a hook is a great idea! For some reason I always forget that contrib modules can provide them and tend to think of them as a core thing. I really need to switch to some client work but will try to dig into this some more and see what it would take to get AF working with a subs hook to get the UI swill and I are looking for.

Thanks!

Michelle

salvis’s picture

@swill: Thread subscriptions are records in the {subscriptions} table of the form

sid  module 	field  value  recipient_uid  send_interval  author_uid  send_updates  send_comments
SID  node   nid    NID    UID            1              -1          1             1

Just query for node/nid/NID/UID to check whether a given node is subscribed, and insert/delete this record (SID is an auto-increment field).

(edited to add UID)

swill’s picture

StatusFileSize
new3.12 KB

My module is currently only for D5.

I have built it to be basically the same as Subscriptions UI. The assumption is that someone will use either Subscriptions UI (SUI) or Subscriptions Simple UI (SSUI) (my module). I have tried to make my module distinct enough that theoretically it could be used with another UI module, but I have not written that in specifically.

Because I wanted to allow for someone to use EITHER SUI or SSUI, I made a small change to the Subscriptions module so that if you enabled the SSUI module you do not get the warning about the dependencies.

The changes I made are:
In subscriptions.admin.inc -> subscriptions_settings_form() I made the following change...

// From this...
if (variable_get('subscriptions_show_install_info', 1) && (
        !module_exists('subscriptions_ui') ||
        !module_exists('subscriptions_mail') ||
        !module_exists('subscriptions_content') ||
        !module_exists('subscriptions_taxonomy') ||
        !module_exists('html_to_text')))

// To this...
if (variable_get('subscriptions_show_install_info', 1) && (
	(!module_exists('subscriptions_ui') && !module_exists('subscriptions_simple_ui')) ||
        !module_exists('subscriptions_mail') ||
        !module_exists('subscriptions_content') ||
        !module_exists('subscriptions_taxonomy') ||
        !module_exists('html_to_text')))

To reflect this change in the print out, I also made the following change:
In subscriptions.install.inc -> _subscriptions_install_information() I made the following change...

// From this...
drupal_set_message($t('Note: for standard Subscriptions functionality you need to enable the following modules:')
                     .'<ul><li>'. $tr('Subscriptions UI')
                     .'</li><li>'. $tr('Subscriptions Mail ')
                       .'<ul><li>'. $t('!mail_edit (required)', array('!mail_edit' => l($tr('Mail Editor'), 'http://drupal.org/project/mail_edit', array('target' => '_blank')))) .'</li>'
                       .'<li>'. $t('!HTML_to_text (strongly recommended)', array('!HTML_to_text' => l($tr('HTML to text'), 'http://drupal.org/project/html_to_text', array('target' => '_blank')))) .'</li></ul>'
                     .'</li><li>'. $tr('Content Subscriptions')
                     .'</li><li>'. $tr('Taxonomy Subscriptions')
                     .'</li></ul>');

// To this...
drupal_set_message($t('Note: for standard Subscriptions functionality you need to enable the following modules:')
                     .'<ul><li>'. $tr('Subscriptions UI'). " or ". $tr('Subscriptions Simple UI')
                     .'</li><li>'. $tr('Subscriptions Mail ')
                       .'<ul><li>'. $t('!mail_edit (required)', array('!mail_edit' => l($tr('Mail Editor'), 'http://drupal.org/project/mail_edit', array('target' => '_blank')))) .'</li>'
                       .'<li>'. $t('!HTML_to_text (strongly recommended)', array('!HTML_to_text' => l($tr('HTML to text'), 'http://drupal.org/project/html_to_text', array('target' => '_blank')))) .'</li></ul>'
                     .'</li><li>'. $tr('Content Subscriptions')
                     .'</li><li>'. $tr('Taxonomy Subscriptions')
                     .'</li></ul>');

At this point you can enable either SUI or SSUI and you are good to go without getting any user warnings...

There is one more minor issue in the Advanced Forum (AF) module that needs to be addressed in order for SSUI to work with AF. I have laid out in that thread how to solve that problem...

I think that is it. I am attaching my current version of the module. If you have comments or suggestions for improving the module please let me know...

Cheers...

swill’s picture

Don't use the module or method described in #7... I am changing some things and improving the modules integration with Subscriptions so that you can choose which UI you want to use depending on Content Type.

More too come soon...

swill’s picture

I have written a new version of my D5 Subscriptions Simple UI module.

My module no longer requires any changes to the Subscriptions module. It currently depends on a minor issue in Advanced Forum if you are using that module, but in that issue I have described how to solve the problem.

From the previous version I have added the following:
- Now Subscriptions UI (SUI) and Subscriptions Simple UI (SSUI) will work side by side. However, salvis has not exposed an override hook yet, so both subscription methods will show up for all of the Subscriptions Simple UI configured content types unless Subscriptions UI is disabled.
- SSUI will work fine without SUI enabled (turn off the warning at the top of 'admin/settings/subscriptions').
- SSUI now requires you to select the content types that you would like to use the SSUI interface with. This is selected in the 'Subscriptions Simple UI - Display Settings' at 'admin/settings/subscriptions'.
- With SSUI, it is now impossible to subscribe to pieces of content that comments are not enabled for.

I think that is it for now. Let me know what you guys think...

Cheers...

websites-development.com’s picture

this is a great module.
I would love to see an additional feature: subscribe to forum (not just thread), as a separate link,

sterwa’s picture

wanted to repor that the module in #9 works (and I am using AFK -- the issue described by swill has been patched up by them)

chrism2671’s picture

Any chance of turning this into a project/making a D6 release?

salvis’s picture

Status: Active » Needs work

If we had a D6 version and JS operation (with non-JS fallback), I'd be happy to add this to Subscriptions...

At some point we'll need a D7 version to start. As with core, the latest version must always come first — we can't have users upgrading to a newer version lose functionality.

vuil’s picture

Issue summary: View changes

10 years without update, set the issue's status to Closed (outdated).

vuil’s picture

Status: Needs work » Closed (outdated)