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?
Watch
GitHub Core
Show your support for Zikula! Sign up at Github account and watch the Core project!
GitHub Modules
- Guite responded to »Can the Updated Version Check be Turned Off (Z 1.3)« 05:53 PM
- frw responded to »Bug in the SMTP mail transfer protocol - Port 25 - Zikula 1.2.9« 22. May
- mdee responded to »Short URL questions« 22. May
- mesteele101 responded to »Problem in Database Connection« 21. May
- Herr.Vorragend responded to »Clip Documentation and Doubt« 19. May
- mazdev responded to »zikula 1.3.3. and IE9« 19. May
- mesteele101 responded to »How to install Zikula for MSSQL ??? - Part II« 19. May
Zikula Blog
- Anatomy of Open Source Projects on Mar 07
- Continuous Review on Mar 01
- Not Invented Here on Feb 24
- How to Contribute Your Code at Github on Jan 13
- 10 Steps to Coding-Nirvana: Tips for Successful Module Writing on Nov 12
- Submitting Bug Report Tickets That Get Results on Aug 17
- Cozi Tricks #1: Syntax Highlighting on Aug 07
Login
Best Way to do this? FirstVisit Start Page
-
- Rank: Developer
- Registered: Dec 31, 1969
- Last visit: Jun 01, 2010
- Posts: 6859
-
- Rank: Team Member
- Registered: Mar 18, 2002
- Last visit: Oct 21, 2009
- Posts: 6606
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: Helper
- Registered: Apr 08, 2002
- Last visit: Oct 21, 2009
- Posts: 614
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: Developer
- Registered: Dec 31, 1969
- Last visit: Jun 01, 2010
- Posts: 6859
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?
--
Home Page | Find on Facebook | Follow on Twitter
-
- Rank: Developer
- Registered: Dec 31, 1969
- Last visit: Jun 01, 2010
- Posts: 6859
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).
--
Home Page | Find on Facebook | Follow on Twitter
-
- Rank: Developer
- Registered: Dec 31, 1969
- Last visit: Jun 01, 2010
- Posts: 6859
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).
--
Home Page | Find on Facebook | Follow on Twitter
-
- Rank: Helper
- Registered: Apr 08, 2002
- Last visit: Oct 21, 2009
- Posts: 614
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: Developer
- Registered: Dec 31, 1969
- Last visit: Jun 01, 2010
- Posts: 6859
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.
--
Home Page | Find on Facebook | Follow on Twitter
-
- Rank: Helper
- Registered: Apr 08, 2002
- Last visit: Oct 21, 2009
- Posts: 614
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: Developer
- Registered: Dec 31, 1969
- Last visit: Jun 01, 2010
- Posts: 6859
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: Helper
- Registered: Apr 08, 2002
- Last visit: Oct 21, 2009
- Posts: 614
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: Developer
- Registered: Dec 31, 1969
- Last visit: Jun 01, 2010
- Posts: 6859
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.
--
Home Page | Find on Facebook | Follow on Twitter
-
- Rank: Helper
- Registered: Apr 08, 2002
- Last visit: Oct 21, 2009
- Posts: 614
I thought about something like
To be thought aboutCode
pnModRegisterHook('user',
'login',
'API',
'MyModule',
'user',
'Func')
-
- Rank: Developer
- Registered: Dec 31, 1969
- Last visit: Jun 01, 2010
- Posts: 6859
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?
--
Home Page | Find on Facebook | Follow on Twitter
- Moderated by:
- Support
