Wrong datatype for second argument

For deleting strange things that seem to be leftovers from any module, you can use phpmyadmin and do a 'search' for the text you think may have to do with the problem. Although you will be able to delete the results from the table that the search function gives you, I suggest looking at the results first to make sure of what you are deleting.

As for the 1028 thing, I'm still pretty sure it has to do with incorrectly set up pageroutes. Without more info, I can't do anything else.

I haven't solved it yet, but will try to get more info first.

That's what 'active(needs more info)' is for.

I'll give it a couple of weeks more, but if I don't hear back from the poster, I'll close this issue.

I have removed the page routes, but after each login, the following warning is displayed:

warning: array_search() [function.array-search]: Wrong datatype for second argument in C:\wamp\www\communitylocal\sites\all\modules\nf_registration_mod\nf_registration_mod.module on line 1028.

Feel free to close the issue because I can't find more information to provide.

Well, if you want to get this module working, I'm willing to try and help. I just thought you weren't coming back and didn't have any other info for me to help you with. There are a couple of very good, and very long closed posts here detailing setup steps and questions that a couple of people have had. You might try looking there.

I'm troubled by your last post where you said that you removed page routes! This module requires that they be used! And on top of that, my post in #2 indicated that this error seems to me to indicate a pageroute that is setup incorrectly, not that it needed removing altogether. In the README of this module, I outline the steps required to set this module up. The first step is to download, and understand all aspects of the modules that this module depends on, namely: nodeprofile, and pageroute. These must be understood, but not necessarily setup, before this module.

In fact, I find it best if new users of Drupal, or this module play with both nodeprofile and pageroutes on a test environment until they understand them, and then, follow the README of this module. That way, all of the new stuff is here, not in the other modules.

All of the 'success' stories of those who used this module without problems were by those who learned these other modules well. Anyway, if you are really moving on, I will close this issue. Let me know what you want to do.

I have accurately and repeatedly read the README for this module and related ones, and was finally able (that was more than a month ago) to make it work.

The current setup works fairly well, except for the error pawshaker reported, which appears at login (and only once per login) for users other than admin. I have to say that since I can't figure out what's wrong (I've installed and reinstalled the module a few times, and I'm happy enough with the way it's working, so I don't want to mess it up), I simply "solve" the matter by adding an @ to avoid error echo on line 1030 (in 1.5):

if ($page_name = @array_search($type, $user_pages)) {

I know, it's the strategy of the ostrich, but it doesn't really seem to cause any other trouble. Normally avoiding the problem would bug me, but I need to be productive at the moment.

Still, rconstantine, the issue exists, and if I can be of help by providing more details on my setup, I'll gladly answer any questions you have.

I might follow your strategy of the ostrich :) I would be happy to read more about your solution in case you manage to solve it. Just like you, I've been extremely careful when following the README. Because of the complexity, i thought that I did something wrong, but it's interesting that you run into the same issue.

To rconstantine, thanks for your kind offer to help, however with my semitechnical skills, I really can't provide more info than what I already gave. I consider to retry installing the module, but will likely wait to see if there are any other developments here.

Okay. I will look into this more. Thanks for the extra info.

Okay. So I'm looking at the code, and tracing back to what the function expects, we can see that $all_pages which feeds $users pages comes from a call to cck_taxonomy_ssu_field(); this makes an array, or an empty array at least, so the wrong datatype problem should not be happening. Please verify for me the version of PHP that you are using. There's always the chance that something changed. In that function, there is a SQL call to the pageroute_pages table which is why I wonder if there is a setup issue with your pageroutes. Perhaps you guys can describe for me the structures of your pageroutes. That might help. Lastly, you may not have made any pages required for registration. So try this: got to admin/user/nf_registration_mod/ct_adjustments and then make sure you have at least one page which is required. You do this by checking a box and clicking on the 'Require for login' button.

Let me know how this goes.

Oops looks like I posted to the wrong issue. That's what I get for trying to multi-task. And it took me 11 days to notice. Argh!

No!!! What am I thinking??? I guess the post was correct except for the function I pasted. I must not have had the correct one in my clipboard. It should read this:

So I'm looking at the code, and tracing back to what the function expects, we can see that $all_pages which feeds $users pages comes from a call to _nf_registration_mod_get_pageroute_pages();

Anyway, it seems there is no more interest in this issue, even though users are essentially using a broken version (that they broke by using @). So I'm going to leave this open for a little longer, but will close it if nobody comments.

rconstantine,
sorry for not keeping the issue alive. It's still an issue, I guess, and if I used @ it was just to find a way for it not to interfere with my work.
I'll take some time later to provide some more info as you requested.
Thanks, again.

Okay. Be sure to give me all info requested in #10 above.

I can anticipate that at the end of this post there's a solution to my problem, but I'll still go through the steps I took, since I wrote them before finding a solution...

PHP version is 5.2.5. I have 3 membership types("agent" and "company"), two of which have their own pageroutes (required for login) containing one page (a Lonely node management page). The third membership type ("generic user") has its own pageroute but it's not required for login and (honestly, at this point I can't remember why) it does not contain any pages.

I can't remember exactly why I did this, since the third membership type doesn't need a pageroute, but it still needs to show up at registration.

So I just tried to delete the empty pageroute and created a "generic user" account. After confirming the account, I got the dreaded warning:

Twice, yes.

Next, I decided to delete the "generic user" membership type. This time I got no warnings at login.

In the end, I imagine it was the membership type without a "valid" pageroute that created the problem. Yet, I still need that type to show up.

Last attempt: I recreated the "generic user" type and tied it to a pageroute (not requred for login) that displays the user edit form. All went smoothly this time.

After all, the warning was created by lack of attention on my part, but at the same time I guess it was due to the fact that I didn't see why I had to set up a custom pageroute to do something that Drupal naturally does (that is, make the generic user go through the user edit form). I've learned my lesson.

One final question, though (off topic, I must say): can the membership-type labels be wrapped in t(), so they show up in the right language at registration?

Thanks, once more.

Hmm. You could probably create a content type with just a 'registration successful' message and no user inputs (using autotitle module and leaving off the body; add a cck field to include the message) for your 'NULL' pageroute instead of actually leaving off nodeprofile types. That might work. It might be unintuitive though, since users will still have to submit it - although you could change the submit button to read "enter site" or something.

Also, I can see two feature requests here that you might want to open as separate issues.

First, to allow NULL page routes; i.e. membership types without nodeprofile pages (like maybe admins might have, or generic users in your case).

Second, to wrap your membership names in t(). I've never done that for admin-entered text before, nor have I seen the practice that I can recall. I'm wondering if it is a straight-forward thing to do, or if there might be some tricks to that. Are you using this in a multi-language environment?

Such features aren't on the top of my list, so might take quite a while to get in unless you submit patches yourself.

Anyway, they sound good. So please open new issues if you are interested.

This is related to the fact that when registering a new user, an option that should not exist anymore appears in the dropdown box. This is the only place where this membershiptype is visible. I was now able to locat this field in the table drupalvariable. Can I just delete this record directly in the database or is there another way?

Given the feedback at the end of this thread, I believe that this kind of "orphan" memberships (and therefore memberships without pageroutes) are causing the mysterious error message. I will keep you informed.

Well, shoot. If there is a variable not being removed, that is something I need to know. Now that you mention it, I suppose I have never had to delete one in my live sites.

To answer your question, you can safely remove that variable from the table by hand. Would you also be so kind as to open a new issue and call it 'membership name variable doesn't get removed' or something? Then we can focus on that by itself. Thanks.

Automatically closed -- issue fixed for two weeks with no activity.

I was also getting this error message.

I debugged it and the cause is simple -- this error message appears when a user's membership type (as stored in $user->mem_choice) is not valid for some reason.

I found two ways to reproduce this bug:

(1) Install the module after creating users. The previously created users do not have a membership type. This causes the error.
(2) Create a membership type and delete it after users sign up using the membership type. The membership type is no longer valid. This causes the error.

There is a very simple fix:

Add the following line of code

before the foreach loop near line 1029.

I reopened this issue so you can evaluate the fix, or at least mention this in the documentation.

Cool. Thanks. I should do an new release because I just made a bunch of fixes while working on a paying job that used this. The problems you mention may be related to not updating/deleting correctly. As it turns out, only two out of three tables were being updated when a name changed. I should rethink the schema, but for now it's fixed. I'll look at the code provided in #20. Look for a release soon.

@JStuckman: thanks for your message, the fix works for me

@rconstantine: I can confirm that the two methods to reproduce mentioned by Jstuckman were applicable to my case as well

You know, to address issue 1 from comment #20, all you have to do is assign all existing users to a membership type when you first install the module. You can do that from admin/user/user and is part of the "Update options" drop down. That was the intention anyway. Can someone tell me - was that tid bit not in the README?

I should get to a new release soon.

Perhaps I should finally get around to that new release.