Integrate with Organic Groups

Reasonable request. However, seems like there is not much demand for it...?

Well, we have a conceptual barrier for this, because guestbooks are tied 1:1 to user ids currently. That means, guestbook id 0 is a site's guestbook, and guestbook id > 0 is a user's guestbook. However, for OG integration, I'd understand that each group might have an own guestbook, not tied to a specific user...?

If that was the desired feature, we would have to remove this hard id relationship first. Basically, this would also mean that a user could have more than one guestbook, or there could be more than one site guestbook. However, I do not see a use-case for this on regular sites... so we might want to investigate whether there are other potential solutions to support external guestbook ids.

Please note that Guestbook 2.x does not differ that much from 1.x -- it's mostly a clean-up release, but also ships with Panels and User Display API integration - as well as integration with Notifications (already on the way). I do not think that modularization helps in any way - we'd still have the barrier of hard-tied guestbook ids with sub-modules, and the core module would have to know what to do with a guestbook id in any case.

There have been discussions about turning guestbooks into nodes in another issue. However, using nodes has some other caveats, too (outlined in the other issue).

Next to ids, there are some other things to consider: Who's the owner of a group guestbook, resp. who gets administrative access?

I understand that a complete feature-set including an upgrade path for existing users might be too complex for what you need currently. However, it would be great if you would not create another project for that module, because having two projects providing almost identical features would confuse all Drupal users. Instead, everyone could learn and would benefit most from a proof-of-concept implementation, which can be integrated into Guestbook module in the long run. Please bear in mind that I've taken over the Guestbook project just a short time ago and the module will advance, too - maybe in other areas, but maybe also in a similar fashion.

I hope you did not misunderstood my previous comments: I'm absolutely open to work with you on the concept and whole task, to find a solution that fits best to Guestbook's future, i.e. planned enhancements. Your idea of separate sub-modules was not bad and I could imagine that not everyone who needs user guestbooks likes to have a site guestbook - however, I guess that most people who want user guestbooks would also want OG guestbooks, so we'd still have the id clash problem...

I couldn't wait, so I went ahead and wrote this. It's very simple, and I haven't tested it to see if it works. But if it does work, it will work on all nodes.

All it does is add two blocks to the system (plus a settings page and a permission). One block allows adding messages to the node's guestbook, and the other displays the latest messages. At this time, there is no way to see more messages than are displayed in the block. The module adds one database table.

The idea is that the two blocks will be added to the content area on group pages. (Enter this code in the visibility section of the block configuration):

Also, at this time the module doesn't work for user profiles. There is a To Do list at the top of the .module file (which doesn't include either making this work on user profiles or adding a page to view all the messages for a group, although those should be added).

Obviously, change the extension from .tar_.gz to .tar.gz before extracting.

I worked on my code again today and it's much more polished now. And everything actually works, for any node. Here's my to-do list:

I decided I'm not going to make this work with user profiles. So, that means there's no reason this can't be its own module. I tend to agree with you that Guestbook does as much as it needs to do, and there's not any great reason to expand the codebase for so many users that don't need it. And I still feel like entirely refactoring the Guestbook codebase is more work than writing another module. While I feel like for Drupal in general it's usually better to have API-based modules - you've said yourself Guestbook is pretty much parallel to comments on nodes, and so in most cases there's no reason to use a Guestbook API for anything other than users. And it does its job with users. The module I've written is for the special case where comments are disabled on node types; and it does its job there, too, albeit less fancily.

So unless you can think of another use case for a Guestbook API, I think it would just be duplicating node/comment code for little reason. (For admin-only use, there are already other modules that let you "take notes" on the site, or one could use unpublished comments.)

Hm. 7 of 8 points of your todo list in #11 are or will be duplicated features of Guestbook (or the envisioned Guestbook core/API module). Also, I intentionally listed guestbook_node and guestbook_og as separate modules, because I think that integration with OG needs to account for different or at least additional conditions than a plain node integration. FWIW, there are other use-cases for having a guestbook core - for example, guestbook_site could provide a guestbook for each Drupal site on a multi-site setup, and/or could be enhanced with a guestbook_domain module that integrates with Domain Access to provide a guestbook for each domain.

All in all, it seems to me that you got stuck with that node_guestbook module and you rather want to scratch your own itch than expanding on the features of the existing project. To be honest, I do not have time nor will to convince you any further, but I want to say thank you for inspiring me to #306450: Split module into core and integration modules. All I ask you is to not create a project for node_guestbook on d.o, because this will definitely lead to confusion among end-users in the end.

I would like to know a little more about the conceptual requirement for this and use case. I don't get why this would be needed and if needed wouldn't it create more complications for users?
1. Groups have different levels of permissions open, moderated, invite and closed. What happens when guestbook is made available for each types?

2. Can only group members write to guestbook? or anyone member of a site (but not necessarily member of group) is expected to write in the users guestbook?

There are already existing features which can implement guestbook style functionality and comes free with all bells and whistles of groups (notifications, RSS etc).
e.g A story can be created in group, made it for group only and named guestbook so only members can publish there.
Or that story can be made public so any site member (even if they are not member of group) can write entries on that page. I use this configuration successfully in production now. OG allows only this page designated as guestbook can be made public and everything else can be kept private to groups members if you wish.

There are all kinds of combinations possibles using existing features of OG to implement guestbook. A group can have multiple guestbooks (each with different permission setting if required) or even multiple groups can share one common page as guestbook etc.
With OG panel page, you can have the guestbook in its own tab or differnt panel etc. And because it is real node-comment set you can use views.

SO I am little curious what you are trying to achieve that is currently not possible in existing OG feature set (other than it is not called guestbook)?

@ajayg: From my understanding, the difference would be that users of a community would not need to "hi-jack" any given functionality. After creating a group the group admin(s) would be able to decide whether they want to add a guestbook, and who will have read/write access to it. Of course, you can always "think your way around systems" (like I did) and that might work out for technology-oriented communities, but it certainly won't for sites that are used by regular end-users who "don't know and break the system".

People just expect Guestbooks to be there if they want them, end of story, without having to think about what's involved in adding a (private) story, enabling comments on it, and putting the comments and comment-submission-form in panels on the group page. I mean, adding a panel is complicated enough in the first place, and a lot of people don't enable OG Panels. If you took a standard Facebook user, for instance--that user would create the group "OMG I LOST MY PHONE I NEED NUMBERS NOW" and you'd end up with a thousand forum topics with a single ten-digit (U.S.) number in each one, unless you had a Guestbook enabled without previous configuration.

subscribing

Did this get implemented??

Thanks for taking the time to report this issue.

However, marking as duplicate of #72607: Use entities for guestbooks and guestbook entries. You can follow up on that issue to track its status instead. If any information from this issue is missing in the other issue, please make sure you provide it over there.