Dizkus

I'm about to write what I think should be a fairly simple module for someone to allow the Admin to define two start pages for their users. One for the first login after sign up (could be a welcome letter, ect) and the other start page would be a normal start page.

My thought is that the best way to achieve this without having to actually hack the existing routines is to:

1. Add a new field to the *_users table called first_vist or something that will default to 1. In the init set existing users to '0' (maybe admin selectable?) I've done similar wiht the new Groups module I'm almost done with for the same client and the regular NS-Groups works fine since it just ignores the extra fields, so It doesn't seem like it should cause a problem (unless the upgrade routine would get rid of the field in any upgrades).

2. Add two module vars for FirstVisit & Visit containing the URLs/Mods to use.

3. Admin has to set the pnFirstVisit as the start module.

What I'm thinking is that, in the init, I can get the value of the current startpage from the DB, assign that to the regular visitor value, and then change the start page to pnFirstVisit, since if the Admin is installing it, that means they plan to use it, and if it's not the start page, then it's worthless.

So, is there a better way to handle this? And do I need to define the new nuke_users structure in the pntables.php for the module since a field is added, or can I just add it using the init?

Don't have a clue how to do it, but I like the idea!

--
/N!cklas
Bingo | BlueCow | Blogg

Michael,

Better to use a dynamic user data field to store the value for each user. Store the value using pnUserSetVar and retreive it with pnUserGetVar. User vars could store the visit times as well.

-Mark

IMHO to do it properly, a module with its own table is needed. In this table, only the usernames/uids are required. If the current user is contained in this table, redirect him to module "NotFirstVisit". If he is not, add him and redirect him to "FirstVisit". So this functionality is self-contained without being dependent on dynamic user data or hacking the user table.

I wouldn't set such a module as the start module, but to alter the login fields to redirect to this module after logging in.

Jörg

Mark, thanks. Makes sense that way. I'm assuming that would have the same effect as if I were to add a new field in that it could be set to 1 by default and updated to 0 on init for existing users?

Jörg, if I'm not mistaken, that would then require a hack to the core code to accomplish, which is what I'm trying to avoid. Is there some way what you suggest can be accomplished plug & play?

Oh and N!cklas, the cool thing is the client is planing to let me release this GPL and/or for submission to core. (Which if that's the case then I can see doing it Jörg's way since it'd be in the form of a patch I guess).

Jörg's method of using a dedicated table looks like the easier of the two to implement for the purpose of making it easy to install, since Mark's method would require adding a define to global.php, which is more work than I'd like to make the admin do. (Which is the only reason I want to do it as a stand alone module rather than a hack to the core. Maybe I'll submit as a patch for .8 once I get a good look at it).

You mean the second part of my suggestion, to alter the login fields?

This is why I not wrote where to change this, only what to change -- There are may ways wher you could log in. In can be in your theme, it can be done with the login block (whcih has indeed to be modified; but this can be done by copying the block and renaming it), or with user.php (in this case you would have to hack indeed).

I guess that for user friendlyness you are using one of the first two methods....

Technically, all you have to pass to the login procedure is a hidden field in the login form with the name URL and the value "where to go after logging in".

Jörg

Jörg, I did mean the 2nd part. Don't all methods of logging in ultimatly go through user.php? So the change would need to be made there I would think.

I'll have to see what my client thinks. I do know his desire/intent was something that could be submitted to be added to the core, which makes that a more attractive way to go. It's not really something that would need to be a seperate module in that case, just an extra couple lines of code in the user.php and the settings page.

No need to hack anything....

Have a look in modules/NS-User/user.php, function user_user_login(). You can see that the variable $URL ist taken from the input and passed to access_user_login, which is defined in modules/NS-User/user/access.php. There, this variable is passed to redirect_index defined in modules/NS-User/tools.php (uh, a long way to get there )

This variable is used to create the output


The only trick is to get the URL set in the login form. That is why I mentioned the different ways to get such a login form.

The form must look like


Note the hidden URL field.

This can be hardcoded in the theme, in a block or elsewhere....
Jörg

Wouldn't it be better, in the initialization of the module (or if it's in the core of PostNuke) to do something like


Then add in to access.php


That way it wouldn't matter how the user logged in, the $URL value is over ridden if it's the user's first visit, otherwise it's what was set by the system.
I'm not clear on how to utilize the UserSetVar and UserGetVar, but I'm assuming it's best to check if it's set and if it isn't assume first visit?

Hey, you're hacking core :P

Of course that is the best way to do it, if it is not the first time the "normal" behaviour of the login procedure -- taking the now-logged-in user to where he was before -- is only altered for the first time. I'm too lazy at the moment to check if you can use pnUserGetVar this way, but I guess you can.

(looks to me we need something like userlogin and userlogout Hooks...)

Jörg

Oh :P. As I said, the client is interested in having this patch/module added to core, and it seems like it would be of no impact to people not wanting to use it (have it off by default) and very useful to those who find it a good idea.

I thought about something like
To be thought about

Well, the part about checking if the admin has it on or off is working, just gotta figure out how to make use of userGetVar/SetVar if it can be done. I guess I need to add the Dynamic User Data when I install the module. If there's no display needed I guess the lang define doesn't need to be done?