PHP Web Host - Quality Web Hosting For All PHP Applications Free RavenNuke(tm) Add Ons
  Login or Register
 • Home • Downloads • Your Account • Forums • 

View next topic
View previous topic


Google
 
Web RavenPHPScripts (This Site)
Post new topic   Reply to topic
Author Message
myrtletrees
Involved
Involved


Joined: Sep 13, 2005
Posts: 259
Location: Cornfields of Indiana

PostPosted: Tue Aug 23, 2011 10:36 am Reply with quote Back to top

Raven wrote:
The `users` table is set to default to 1. I don't know why but I would not agree with that. Here is a portion of the schema:

Field Name: user_allow_viewonline
Default Value: 1

Try changing the Default Value to zero using phpMyAdmin or a similar tool. That should `fix` the new user issue. If that works we can then address the profile update issue.


Still having this issue.

I have set the user_allow_viewonline default value to 1.

If I leave that default field in Admin Users Configuration Active, when a new user registers/activates, their online status is set to NOT hidden. However, if I deactivate that default field, then all new user registration/activations are saved with status HIDDEN. This makes no sense....
View user's profile Send private message
Raven
Site Admin/Owner


Joined: Aug 27, 2002
Posts: 16987
Location: Kansas

PostPosted: Tue Aug 23, 2011 2:21 pm Reply with quote Back to top

I suggested setting it zero, not deactivating it. What happens when you set it to zero (in the table itself)?
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger
myrtletrees
Involved
Involved


Joined: Sep 13, 2005
Posts: 259
Location: Cornfields of Indiana

PostPosted: Tue Aug 23, 2011 3:48 pm Reply with quote Back to top

Raven wrote:
I suggested setting it zero, not deactivating it. What happens when you set it to zero (in the table itself)?


Same result as above...
View user's profile Send private message
kguske
Site Admin


Joined: Jun 04, 2004
Posts: 6044

PostPosted: Sun Aug 28, 2011 1:39 pm Reply with quote Back to top

We are testing changes that enable most (but not all) of the user profile fields to be:
- used in the registration process
- optional or required (for registration, user maintenance or both)

We expect to have this in the 2.5 release.

Some assumptions that are important to note:
- admin views and can edit every attribute, regardless of whether or not the user can (this is necessary in case a field is deactivated, but users can still have data there)
- every attribute is optional for the admin
- if it's required for registration only, it will be display-only on the user maintenance screen
- if it's required for registration, it's required for user maintenance, too

While testing the activation, we found a significant issue related to this forum topic. We are asking the user - who has already entered most of the information (excluding the forum yes/no flags) to confirm / maintain this information. But there is currently no provision for this to be maintained here (it is only copying the data from the temp table to the users table). Now that we will have the ability to specify almost all fields in registration (the Yes / No forum settings are excluded), there are several options for how to address this.

Options:
1. Display the fields for registration, and allow them to change ONLY the additional yes / no flags not available to registration.
2. Allow even the forum yes / no flags in registration and only display them on the activation screen
3. Skip the activation screen and create the account with defaults and / or whatever is entered on registration, then take them to the user account screen for maintenance of all fields
4. Modify the activation screen to enable maintenance.
5. Default the forum yes / no fields and skip the activation screen. If Forums and Private Messages are active, and if they want to change the defaults, they can do this on the regular user maintenance screen.

Option 2 is annoying - it would discourage people from registering if they had to answer all those unnecessary questions - especially if the forums aren't even active. Option 4 seems unnecessary since it duplicates the maintenance function. I favor options 1 and 5 (with 5 being the best).

What do you think?
View user's profile Send private message
montego
Site Admin


Joined: Aug 29, 2004
Posts: 9136
Location: Arizona

PostPosted: Sun Aug 28, 2011 2:42 pm Reply with quote Back to top

Not sure how helpful I will be as I haven't signed up and activated a new user in a very long time. I like the direction this is going though. Some possibly random/disconnected thoughts:

1) First off, I'd like every user profile data element to also have the ability to have a default assigned (by the admin). Admins should never have to change code or alter a table to get new defaults assigned. Wink

2) Keep the registration / activation as simple as possible. Only required data for registration needed.

3) Maybe separate registration from use? Could be a crazy idea, but make it painless to register, but then to use that registration there is a small price to pay: make sure all required profile data is up-to-date plus give them a chance to update all the other (because they were defaulted). Once they've update the required, they are now allowed to continue using the site.

What if an admin decides she wants to now collect another required piece of information, maybe clear out the "profile complete date (a new date field) and highlight for the user upon next accessing the site the field on the user maintenance page which now needs to be entered.

Not sure I've helped... Sad
View user's profile Send private message Visit poster's website
kguske
Site Admin


Joined: Jun 04, 2004
Posts: 6044

PostPosted: Sun Aug 28, 2011 2:50 pm Reply with quote Back to top

2 sort of answers the questions, but 1 and 3 are more work...not for this release.
View user's profile Send private message
myrtletrees
Involved
Involved


Joined: Sep 13, 2005
Posts: 259
Location: Cornfields of Indiana

PostPosted: Mon Aug 29, 2011 11:10 am Reply with quote Back to top

kguske wrote:
We are testing changes that enable most (but not all) of the user profile fields to be:
- used in the registration process
- optional or required (for registration, user maintenance or both)

We expect to have this in the 2.5 release.

Some assumptions that are important to note:
- admin views and can edit every attribute, regardless of whether or not the user can (this is necessary in case a field is deactivated, but users can still have data there)
- every attribute is optional for the admin
- if it's required for registration only, it will be display-only on the user maintenance screen
- if it's required for registration, it's required for user maintenance, too

While testing the activation, we found a significant issue related to this forum topic. We are asking the user - who has already entered most of the information (excluding the forum yes/no flags) to confirm / maintain this information. But there is currently no provision for this to be maintained here (it is only copying the data from the temp table to the users table). Now that we will have the ability to specify almost all fields in registration (the Yes / No forum settings are excluded), there are several options for how to address this.

Options:
1. Display the fields for registration, and allow them to change ONLY the additional yes / no flags not available to registration.
2. Allow even the forum yes / no flags in registration and only display them on the activation screen
3. Skip the activation screen and create the account with defaults and / or whatever is entered on registration, then take them to the user account screen for maintenance of all fields
4. Modify the activation screen to enable maintenance.
5. Default the forum yes / no fields and skip the activation screen. If Forums and Private Messages are active, and if they want to change the defaults, they can do this on the regular user maintenance screen.

Option 2 is annoying - it would discourage people from registering if they had to answer all those unnecessary questions - especially if the forums aren't even active. Option 4 seems unnecessary since it duplicates the maintenance function. I favor options 1 and 5 (with 5 being the best).

What do you think?


5 seems most simple to me, although I do like the activation. It helps deter spammers a little.
View user's profile Send private message
kguske
Site Admin


Joined: Jun 04, 2004
Posts: 6044

PostPosted: Mon Aug 29, 2011 11:27 am Reply with quote Back to top

You can still activate, but they won't have an extra step.

I am working on another solution that has proven very effective against spammers...basically, on registration, the email address, user name and IP address are checked against multiple databases of known spammers. If there is a match, no registration. I call this nukeSPAM, and it's in development for a future release of RavenNuke (it won't be in 2.50, though it might be released earlier than the release after 2.50).
View user's profile Send private message
montego
Site Admin


Joined: Aug 29, 2004
Posts: 9136
Location: Arizona

PostPosted: Tue Aug 30, 2011 6:24 am Reply with quote Back to top

kguske wrote:
though it might be released earlier than the release after 2.50).


Cannot wait...

worship
View user's profile Send private message Visit poster's website
kguske
Site Admin


Joined: Jun 04, 2004
Posts: 6044

PostPosted: Wed Aug 31, 2011 10:37 pm Reply with quote Back to top

Here's an update on skipping the activation screen:

These 2 fields are updated from the activation screen, and we can default them as noted:
user_dateformat - D M d, Y g:i a
user_timezone - 10

The rest of the activation screen fields are not written to the user account, so it doesn't matter what you enter on the activation screen, they will default as:
user_allowsmile (1)
user_allowhtml (1)
user_attachsig (0)
user_allowbbcode (1)
user_popup_pm (0)
user_notify_pm (0)
user_notify (0)

At this point, activation verifies the request, but before displaying the somewhat bogus activation screen, redirects to activation function. We could consider using a switch to configure whether or not to skip activation, but if we did that, we'd need to do a lot more coding to address the issue raised earlier in this post. Smile

IMO, let's leave it like this and move forward with the release.
View user's profile Send private message
Display posts from previous:       
Post new topic   Reply to topic

View next topic
View previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Forums ©
 

All logos and trademarks in this site are property of their respective owner.
The comments are property of their posters, all the rest © 2002-2011 by Raven

You can syndicate our news using the file xml

CSE HTML Validator Helped Clean up This Page! [Valid RSS] valid RSS 2.0 Valid robots.txt Stop Spam Harvesters, Join Project Honey Pot

Website engines core code is © copyright by PHP-Nuke but has been heavily patched and modified by myself and others.
PHP-Nuke is a free software released under the GNU/GPL.


:: fisubice phpbb2 style by Daz :: PHP-Nuke theme by www.nukemods.com ::
:: fisubice Theme Modified by the RavenNuke™ Team ::

:: W3C CSS Compliance Validation :: W3C HTML 4.01 Transitional Compliance Validation ::

zerosum