[solved] New members appear as guests

[MikaK]

I seem to have closely same problem than "BrandonC" describes at http://www.vbulletin.com/forum/showthread.php?t=126559 and https://vborg.vbsupport.ru/showthread.php?t=74368

I am using a membership suite (php/mysql based) to register members. Everything seems to go fine except the following:

-the editor doesn?t get changed to the full wysiwyg as I?ve set in vb registration to be the default,

-the new member can not view any threads - this gets corrected when the default for threaded view is disabled

-the registered member appears as guest in postings, untill I run the

"Help Fix broken user profiles" in the acp maintenance. After this everything works as should. When looking at the meber data via acp all seems correct also the member fields appear ok in the database.

As my board is fairly heavily hacked I understand the support per ticket is not available. However, I?d really appreciate any hints on what parts the "Fix broken user profiles" affects.

Thank you for any ideas,

-Mika

### THE EDIT ###
It was a db issue. Anyone who tries to use exeternal membership management suites should check the registreation process - especially what db fields are included as in some cases the standard user, userfield and usertextfield tables arent the only ones required to be updated if a lot of hacking has been going on.

[MikaK]

*bump*

Not any ideas? Is there any way to find out about how Fix Member Profiles works as that corrects the problem when used?

-Mika

[Marco van Herwaarden]

What values do you set in the user table for:
- usergroupid
- styleid
- options
- languageid
- threadedmode
-

[MikaK]

What values do you set in the user table for:
- usergroupid
- styleid
- options
- languageid
- threadedmode
-

This is what happens
1) After registration
threads don?t show
2) After disable thread views
language id changes to 0 (the wrong language 1 is initially inserted when compared to others with 0) threads are viewable in linear mode
when writing member appears as guest
3) After running the fix
no changes in the db, but proper user status appears and the threaded view starts working

...........................1) ................2) .....................3)
usergroupid .........35 ................35 ...................35
styleid ................0 ..................0 ......................0
options ...............7255 ............7255 ..................7255
threadedm ..........0................... 0 ......................0
lastvisit ..............1109694655 ....1109694697 ......1109694697
lastactivity ..........1109694697..... 1109695862 .....1109696711
lastpost ..............0 ....................0 ......................1109696677
languageid ..........1.................... 0....................... 0


-Mika

[Paul M]

The profile fix function inserts missing users into the userfield & usertextfield tables - I take it your script to add users is not putting entries into these tables ?

[Marco van Herwaarden]

Well formatted like this i can hardly read it.

Maybe you can post again, but then better formatted (maybe just run a select * from user). Post the values from immediate after you created the user.

A few things i already notice:
Usergroup: 353535 ?? that sounds extreme high to me
displaygroupid: should probably be 0
passworddate 09.11.2000samesameemail <-- what is that text "samesame" there? text also appearing on more places.

Styleid: 000 Should be just 0

parentemail <-- should be just empty, unless COPA user

showvbcode 111 <-- 111 is not a valid value, try putting 2
customtitle: 00 <-- try a plain 0
daysprune -1-1-1 <-- is not a valid value

Hmm i think i am reading this totally wrong, and this should be in 3 columns.

Sorry i give up until you reposted.

[MikaK]

Sorry i give up until you reposted.

I noticed it as well. Sorry. Hop it?s more readable now.

The profile fix function inserts missing users into the userfield & usertextfield tables - I take it your script to add users is not putting entries into these tables ?

It adds the user but doesn?t add any into the field14 (should be Enable), field13 (should be Compact) field15 (should be 30) userfield table which are related to the threaded view. After correcting the settings in profile options as in stage 2) the values get added and the linear thread as well as threaded forum view starts showing if changed to. So those are at least missing as entries at stage 1).

However, at this point the only thing that needs running the Fix is to get the Guest status changed to the normal one in postings. The oddest thing is that the only place where the guest status is showing is the postbit legacy. All other places show correct user status as a registered member.

-M

[Paul M]

It adds the user but doesn?t add any into the field14 (should be Enable), field13 (should be Compact) field15 (should be 30) userfield table which are related to the threaded view. After correcting the settings in profile options as in stage 2) the values get added and the linear thread as well as threaded forum view starts showing if changed to. So those are at least missing as entries at stage 1).

However, at this point the only thing that needs running the Fix is to get the Guest status changed to the normal one in postings. The oddest thing is that the only place where the guest status is showing is the postbit legacy. All other places show correct user status as a registered member.

-M
TBH, I have no idea what you are talking about here. What is stage1 and stage 2 ? - what is field13, 14, 15 - these are not in the standard userfield table unless you have added a load of extra user defined fields.

When you add a new user to the user table, you also need to add a corresponding row to the userfield and usertextfield tables - this is all the fix broken profiles function does.

[MikaK]

TBH, I have no idea what you are talking about here. What is stage1 and stage 2 ? - what is field13, 14, 15 - these are not in the standard userfield table unless you have added a load of extra user defined fields.

When you add a new user to the user table, you also need to add a corresponding row to the userfield and usertextfield tables - this is all the fix broken profiles function does.

The stages I?m referring to are the ones i?m describing in the post #4 of this thread.

You are right about Fields 13,14 and 15 they seem to be related to the threaded forum view hack.

Well... I don?t want to be obnoxious, but apparently there is something else going on under the hood with the fix as any of the data in discussed tables doesn?t seem to be changing when the fix is run and yet it makes things work. Having said this I will most certainly cross check all aspects brought up in above posts.

If I only knew where to have a look at the code about the fix...

Thanks for the resposes in any case; they?ve already at this point shown some definite flaws needing correcting.

-Mika

[Paul M]

Well... I don?t want to be obnoxious, but apparently there is something else going on under the hood with the fix as any of the data in discussed tables doesn?t seem to be changing when the fix is run and yet it makes things work. Having said this I will most certainly cross check all aspects brought up in above posts. Well you are free to disagree if you wish, but I've looked at the code to see what it does .......

[MikaK]

Well you are free to disagree if you wish, but I've looked at the code to see what it does .......

I know... One more: As the postbit is the only place where this "phenomenon" of the unwanted guest status persists until the fix I am wondering where the <if condition="$show['profile']"> is set. I guess that would be a good place to check since the username and title in the posbit_legacy is the only visible place changing it?s appearance when the fix is executed. My posbit_legacy regarding this looks like:

<if condition="$show['profile']">
<a class="bigusername" href="member.php?$session[sessionurl]u=$post[userid]">$post[musername]</a>
<script type="text/javascript"> vbmenu_register("postmenu_$post[postid]", true); </script>
<else />
$post[musername]
</if>


Regs,
-Mika