Exclude from display on some nodes

Created a patch. Please review and make it better. This works for me, but I have very simple needs as far as excluding from nodes by the number. Someone may want to add wildcards to the mix.

You can currently do this by using block visibility rules. Another way of doing this is to use addthis theme function. I try to keep the module quite simple and light weight since it's just doing a very simple task. I'll have a look at this feature, but since there already are many ways of doing this I'm not yet convinced about adding this to the module.

I am not using the addthis block and therefore cannot use the block visibility rules. Using a theme function would be great but there was not any documentation on that, at least none that I found. It's nice to know that there is a theme function, but I would think that there are many people that don't know what theme functions are and many people that do not know how to use them. There should be a simple way to exclude your addthis by using the interface. Yes, I understand you want a simple module, but more importantly it needs to be usable to the average and below-average user.

Also, I wouldn't consider two ways to do something many. Only one of them would actually work in my case.

I would also like to have control over which nodes the addthis button appears on.

any chance you could do something like a "disable addthis" option on the node edit form?

@jdwfly - thanks for the patch... it would be nice to have an option built into the module itself.

This small addon module allows you to set where the AddThis buttons is or is not displayed.
It works for me but is not tested beyond that...
Once installed and enabled there should be an extra setting in the settings menu 'Extended AddThis'.

with small bugfix

I have been thinking at this and there are quite a few different requests on this. Most likely the best way to do this would be implementing this on node level following same logic that rest of workflow settings do. This means visibility would be set on content type level by default, but could be overwritten on node level if user has the permission to do so.

That is definitely a great plan. Are you going to work on it or do you want one of use to contribute a patch for it?

I actually already implemented something like this for my own purposes, I used the block visibility settings in conjunction with some more hook functions and form alters. Here I will attach the updated module...LOL I have to warn you, it may not be the most elegant way to do it, but this was my first drupal module editing experience. Hope this helps =) BTW the module now puts a menu on each node to enable the link, it also adds radio buttons to choose which place to put the button. If you use block setting, make sure that you have the addthis block setup. I have not thoroughly tested this module but for my purposes using the block settings and enabling the links that way, seems easy enough for anyone to do and has not produced any bugs yet.

subscribing - I currently hack this using a cck field and hook_link_alter(). It's not perfect though, since the css and js still gets added to the page.

This is a surprisingly complex issue. I want to make sure we are not adding too much overhead for such a simple module in order to implement this. There are already many ways of doing this (block visibility, theming, hook_link_alter...). I want to keep this module simple and light weight enough so that it will still be usable even for very large sites.

Implementing this on node level would mean that we need to save some custom data structure for overwriting per content type default values and check for them on each node display. If this will result in yet another SQL query for each node it sounds like an overkill to me. Any ideas or patches on how to implement this with minimal overhead are welcome.