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?
Forum Activity
- Teb answered »PNphpBB2 and menu tree« 04. Jul
- marc@marcpare.com posted »Adding an "About Us" page« 04. Jul
- animateclay answered »SafeHTML output filter and youtube« 04. Jul
- videokid answered »caching« 04. Jul
- Wendell answered »pagesetter pdf output« 04. Jul
- Fredricn posted »Mediashare mysql instalation issue« 04. Jul
- slam answered »Theme by iThinkMedia.com footer - Beacon for Hackers?« 04. Jul
Login
Best Way to do this? FirstVisit Start Page
-
- Rank: Legend
- Registered: 31.12.69
- last visit: 30.06.09
- Posts: 6766
Posted: 02.10.2003, 01:02
-
- Rank: Moderator
- Registered: 19.03.02
- last visit: 27.06.09
- Posts: 7661
Posted: 02.10.2003, 13:48
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
--
Visit My homepage and Zikula themes. -
- Rank: Professional
- Registered: 09.04.02
- last visit: 27.06.09
- Posts: 714
Posted: 02.10.2003, 17:31
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 -
- Rank: Legend
- Registered: 31.12.69
- last visit: 30.06.09
- Posts: 6766
Posted: 02.10.2003, 18:34
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? -
- Rank: Legend
- Registered: 31.12.69
- last visit: 30.06.09
- Posts: 6766
Posted: 02.10.2003, 18:37
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). -
- Rank: Legend
- Registered: 31.12.69
- last visit: 30.06.09
- Posts: 6766
Posted: 02.10.2003, 19:04
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). -
- Rank: Professional
- Registered: 09.04.02
- last visit: 27.06.09
- Posts: 714
Posted: 03.10.2003, 09:20
mhalbrook
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?
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 -
- Rank: Legend
- Registered: 31.12.69
- last visit: 30.06.09
- Posts: 6766
Posted: 03.10.2003, 10:15
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. -
- Rank: Professional
- Registered: 09.04.02
- last visit: 27.06.09
- Posts: 714
Posted: 03.10.2003, 11:08
No need to hack anything....mhalbrook
Don't all methods of logging in ultimatly go through user.php? So the change would need to be made there I would think.
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
Code
echo "<html><head><META HTTP-EQUIV=Refresh CONTENT=\"2; URL=$url\">\n";
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
Code
<form action="user.php" method="post">
Username: <input type="text" name="uname">
Password: <input type="password" name="pass">
<input type="checkbox" value="1" name="rememberme"> Remember me
<input type="hidden" name="module" value="NS-User">
<input type="hidden" name="op" value="login">
<input type="hidden" name="url" value="http://www.example.com/index.php?module=MyFirstVisit">
<input type="submit" value="Login">
</form>
Note the hidden URL field.
This can be hardcoded in the theme, in a block or elsewhere....
Jörg -
- Rank: Legend
- Registered: 31.12.69
- last visit: 30.06.09
- Posts: 6766
Posted: 03.10.2003, 11:48
Wouldn't it be better, in the initialization of the module (or if it's in the core of PostNuke) to do something like
Code
pnConfigSetVar('UseFirst','1');
pnConfigSetVar('FirstURL','....');
pnUserSetVar('FirstVisit','1');
Then add in to access.php
Code
if pnConfigGetVar('UseFirst')==1 and pnUserSetVar ('FirstVisit')!= '1' {
$url=pnConfigGetVar('FirstURL);
pnUserSetVar('FirstVisit','1');
}
rest of code
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? -
- Rank: Professional
- Registered: 09.04.02
- last visit: 27.06.09
- Posts: 714
Posted: 03.10.2003, 20:17
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 -
- Rank: Legend
- Registered: 31.12.69
- last visit: 30.06.09
- Posts: 6766
Posted: 03.10.2003, 20:29
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. -
- Rank: Professional
- Registered: 09.04.02
- last visit: 27.06.09
- Posts: 714
Posted: 03.10.2003, 20:55
I thought about something like
To be thought aboutCode
pnModRegisterHook('user',
'login',
'API',
'MyModule',
'user',
'Func')
-
- Rank: Legend
- Registered: 31.12.69
- last visit: 30.06.09
- Posts: 6766
Posted: 08.10.2003, 05:18
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?
- Moderated by :
- Support
Users online
This list is based on the users active over the last 60 minutes.
