No reroute to choice form

Please give me a screen shot of your admin overview page.

Also, you need to understand that user 1 is by default exempt from making handshakes and will see the standard profile page, as will those with the 'administer handshakes' permission. The settings for these are on the "Misc settings" tab.

If this is not your problem, then we can proceed once you post a screen shot. Feel free to add other screen shots if you think they are relevant.

In regards to your comment about offering to contribute documentation, to what were you referring? The README is quite large as it is. Were you talking about adding info related to this issue, once resolved? Or were you talking about repackaging it somehow? Please explain.

Hi Ryan,

Thank you for your prompt reply. I was in no way suggesting the existing documentation is inadequate, but I could perhaps contribute a trouble shooting guide based on some of the issues that users have faced to date (including my own).

It is always easy to say RTFM, but in my situation, I have been through that several times and still no luck...

I have produced some PDFs, one includes screenshots, the others show configuration details of my current system.

best regards,
D

First of all, publishing the profile nodes defeats the purpose of having a handshake module at all since anyone can search for and find those nodes. So change your profile content type to default to unpublished. I don't recall whether users can change that at node creation or not, but you may want to consider means to prevent them from publishing those nodes. Pageroute module does that. Also, you could probably use some kind of moderation or workflow thingy to do it.

Second, looking at your profile_node-profile.pdf, try playing with those values. To be honest, I use the handshake module in conjunction with my registration mod module which disallows the first checkbox, the second checkbox, and all of the display settings. So change one at a time and see if that does anything for you. And you didn't comment about which user is trying to do this - based on your settings it cannot be user 1, not any with the 'adminster handshakes' permission.

Third, CCK should be fine as you have it. So should the others, I think. I don't think you need nodefamily.

Looking at system_setup_screenshots.pdf, I'm going to lean to the settings I mentioned in point two as the problem. If you remove the display of the profile nodes from the profiles, then perhaps things will work out. I do not know whether something is now in place that will prevent you from reverting to a working state, or if the settings I mentioned must be done from the start or not.

Does that make sense?

Hi Ryan,

Thank you for your response, I shall try your suggested settings and then introduce your registration mod module if that fails.
I will give feedback tomorrow as I am tied up for the rest of this evening (UK time).

For the record, I am using userA and userB on the system, both have profiles and neither user is admin (user 1) or granted 'adminster handshakes' permission, so they should be fine for testing.

Thanks once more for your advice.

best,
D

I'm having the same problem, and have tried what you (rconstantine) suggested with no success.

When I set the node to be Unpublished, only users with the Administer Nodes permission can see it at all (other users get an Access Denied error). Never at any point does any Handshakes interface show up. I've messed around with the Node Profile Display Settings as you suggested but they do exactly what they say they do without affecting Handshakes.

I would very strongly prefer not to have to use another module to get this to work (and I'm not even sure which module that would be) but I need this functionality...

Thanks.

I'll see about posting my own screen shots soon, but if your settings differ from those above, I'd like to see them. The nodes all need to be unpublished because this module uses the data from the nodes, but never displays the nodes themselves. This module does not grant permission to view the nodes and the nodes should not be accessible to users that aren't their creator or node-admins. This module presents data in a tabular format and allows users to share data fields on a per-user basis which would not be possible by viewing the nodes. In fact, I may have code that checks for the published state of the node and rejects any that are published.

On the nodeprofile tab - deselect all checkboxes and set the radio to the first option of 'don't display...'

Yeah, that's what I assumed. I did what you've just suggested earlier and it didn't work, but I'll try it all again when I have more time (very likely this weekend, but possibly sooner). Thanks for helping in the mean time.

For the record, I've also taken a look at the code, and although I'm really not any good at PHP or JS, I couldn't see anything that was noticeably "wrong." There's probably one crucial setting somewhere that I'm missing.

It's not working. I don't know what else to do...

I'm going to email you some login information.

HI Ryan,

I have tried the suggestions you have made for tweaks to my own configuration to no avail. Still no joy.

I have now followed your install instruction to incorporate the registration_mod module and all of its dependencies in the hope that there was an undocumented dependency that would fix my problem.

I now have the registration_mod stuff working, but I have not fully implemented Nodefamilies as my profile uses a single content type at this time.

I have successfully created a single step pageroute, and I am happy with the data it is creating (all correctly not published).

The Handshake stuff is still stubbornly refusing to appear.

I will send you login credentials for my system in the hope you have time to have a look.

all the best,
D

I'm fairly certain (after some testing) that Nodeprofile 1.3 interacts with Handshakes in exactly the same way that 1.1 does. That doesn't mean Nodeprofile isn't the problem, but it means that differences in versions isn't.

I think the problem may have something to do with the fact that I'm not actually using the relevant content type as the user's profile. For example, when I search users using the User Search at user/1/nf_handshake/search it shows their My Account page but not their ProfileInfo (the name of the content type I'm using with Handshakes and Nodeprofile).

Also, I've confirmed that the inviting interface at least works by going to user/nf_handshake/initiate$uid (but this only extends a handshake to user 1 and I can't figure out how to change that). I can't check that the hide/show works though because once upon a time I set user 1's ProfileInfo to Published and now it won't let me change it back. All other users' ProfileInfos are unpublished, with the exception of a few admin.

The content type used to collect the data should not be seen on the user's account page. You should not even see the account page, but should get the intercepted handshake interface. I don't recall who I mentioned this to as it was in an email, but make sure that this module is weighted heavier than all core modules as it should be modifying things after they've finished.

EDIT: That last sentence is my prime suspect at the moment as it may also be the cause of what I mention below regarding the search function.

To see what a URL should look like for two users to handshake, check out the various links in the text of the code. I believe your example should have read user/nf_handshake/initiate/uid_of_initiator/uid_of_recipient with the appropriate numeric substitutions.

I noticed on someone's install where I was given access, that the user search tab on the handshake interface didn't work. As this works fine in all of my installs, I'm wondering why this wouldn't work for that install. It is basically a copy of the standard user search. I'll look around that area of code to see if it gives me any clues as to that problem, and maybe I'll find something related to this as well.

I'm grasping at straws here, but what are the system configs for those having this problem? Give me PHP, MySQL, Apache, Drupal and any other relevant version numbers.

Drupal 5.5 (but didn't work on 5.2 also), PHP 5.2.5, MySQL 5.0.45, Apache/2; tried on Firefox 1.5 and 2, IE 5, 6, and 7, Opera 9, and Safari; FF2, IE7, and Opera were tested on Windows Vista while the others (FF1.5, IE5/6, and Safari) were tested on a Mac.

What do you mean "weighted heavier than all core modules"? That seems like it would be the problem to me but I don't know what you're referring to.

So if Handshakes was working, where would the user settings appear? Could they still access their My Account page, and can admin still use the Track and Contacts tabs and other similar tabs that show up on My Account by default? Regardless of whether another user has shaken hands with another user, can those users see the other's My Account page by going to the URL "user/$uid"?

By the way, I tried the URL arguments you suggested before I sent my last post. /*checks* ...actually, I switched the UIDs of the initiator and recipient. It works when I put them in the right place, which would seem to confirm the module-weighting theory.

User search works fine for me, it just shows the My Account page instead of the content type used with Handshakes.

Hmm. I thought some of these questions were answered in the README, but perhaps not. When the module works, the user's account page looks the same for that user. All tabs show up for both the user and admins. For admins allowed to make handshakes, the handshake stuff is put at the top of the user info, but the user info is still visible. For other users, they cannot see anything other than the handshake interface since the idea is that only exchanges info should be seen. However, this doesn't affect tabs.

So what is on the handshake interface? There are three options. First, initiate a handshake, second contact the person (privatemsg and contact modules supported with preference given to privatemsg if both are enabled), and third go back to where you were before.

As for weighted - that refers to the 'weight' in the 'system' table of your DB. I looked at mine and noticed that I set the weight to 1, which is heavier than all core modules which are set to 0. I don't recall the circumstances of my setting this and it may have had to do with something else entirely. However, if this turns out to be a requirement, I'll have to add this to the .install file and just take care of it for new users. So set that to 1 or higher, then let me know if that fixes things or not.

My System is like this: Plesk 8.3, Linux: Centos 4.5, PHP5.1.6, MySQL - 5.0.48, Apache2, Drupal 5.7, All Modules are latest stable Versions.

I just manually edited the weight of the handshake module in the system table of the database as I could not find a place to set this in Drupal.
Hey presto, the handshake module now offers me the choice to initiate a handshake as per the expected behaviour. Woo Hoo!

My user search still falls over thus;
Fatal error: Call to undefined function search_help() in /var/www/vhosts/MYHOST.net/httpdocs/modules/nf_handshake/nf_handshake.module on line 4037

...But from your (rconstantine) assertion that the search is an implementation of the built-in search feature, I realised that the search module must be enabled - i.e. "search" is an as yet undocumented module dependancy (as far as I can tell).
-- Now I have enabled the search module, my user search works correctly too.

I love it when a plan comes together...

So, should I be able to set the module weight (DB system table) via Drupal?

I will do some further testing to maybe break user handshakes in other interesting ways and explore which modules (As I have closely followed the known working module recipe - registration_mod et al) are in fact dependencies and which ones can be lived without while Handshakes remain operational.

All the best,
D

That information was in the ReadMe, you're correct rconstantine. I was just confirming it because I was a little confused by something you said. If you want a pointer on that though, you should put the ReadMe documentation somewhere else (online) and just give the URL in the ReadMe file. It's a lot of plain text to read through in the same size, same font, same page. I've learned the hard way that to be effective in advertising, things have to be big, bold, and broken up. Of course you get a little more leeway with developers because they're already looking for the small print, but you get the idea.

Anyway, I edited my System DB table to add weight to Handshakes and it works now--more or less. I found two more bugs.

1) The initial prompt still tells you that you can send another user a private message, even if that user has disabled private messaging.
2) When using the Avatar Selection module, the Avatar field is displayed as empty on the Initiate Handshake form unless a user has overridden the default Avatars with a custom uploaded one.

Would you like me to open new issues for these problems?

Thanks so much for the weighting hint--the module works exactly as I need it to now. Yay! :D
...and it looks like that change should be added to the install file.

@deltaboy - I totally forgot that the search module could be turned off. I will update the docs to reflect the dependency - or I'll change the code to hide the tab if the module isn't activated. No, there's not a spot inside Drupal to set the weight of modules, but there is a weight module. So you did it the right way for now. I'll change the .install file to do it automatically in the future. I'm marking this as a patch so I don't forget. There should be no other dependencies other than nodeprofile and search.

@IceCreamYou - Ideally, I'll someday get around to adding documentation to the Drupal Handbooks, but that hasn't happened yet. And as I can't really include .doc, .pdf, or other file types in the distribution that may need special readers, I'm left with plain text. Although it is quite a bit of text, I'm sure most people would agree that the docs are way better than the vast majority of projects here on Drupal - not that I think you were criticizing that aspect. Actually, anyone could take my README file and add the contents to the Drupal Handbook. I've already broken it into an outline format, so where to break up the contents into book pages would be obvious. Feel free to pitch in and do it.

About 1), that's good to know. Please file a new issue regarding that so we can track it separately.

About 2), I'm not familiar with that module and I'd have to suspect that this would be a separate feature request. Am I to understand that the avatar uses the standard profile picture slot in a regular account? Screen shots would be useful here - again in a separate issue post please.

The weight trick is good to know about in general because I've found several module combinations which need to be tuned in this manner.

I might help you out with that documentation one of these days. I'm pretty busy lately but I'll put it on my list. It's certainly easier for me to do than submit patches since I haven't been learning PHP for very long.