Best Way to do this? FirstVisit Start Page :: Zikula Community

Try Zikula 1.3.1!New core, modules & more

Download Zikula!Version 1.2.8 (stable)

Best Way to do this? FirstVisit Start Page

Print topic

Go to page 1 - 2 - 3 [+1]:

HalbrookTech

Rank: Developer

Registered: Dec 31, 1969

Last visit: Jun 01, 2010

Posts: 6840
Posted: Oct 01, 2003 - 01:02 PM

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?
**unknown user**

Rank: Softmore

Registered: Mar 16, 2002

Last visit: Oct 21, 2009

Posts: 141
Posted: Oct 02, 2003 - 01:44 AM

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

Rank: Team Member

Registered: Mar 18, 2002

Last visit: Oct 21, 2009

Posts: 6606
Posted: Oct 02, 2003 - 01:48 AM

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 .
jn

Rank: Helper

Registered: Apr 08, 2002

Last visit: Oct 21, 2009

Posts: 614
Posted: Oct 02, 2003 - 05:31 AM

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
HalbrookTech

Rank: Developer

Registered: Dec 31, 1969

Last visit: Jun 01, 2010

Posts: 6840
Posted: Oct 02, 2003 - 06:34 AM

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
HalbrookTech

Rank: Developer

Registered: Dec 31, 1969

Last visit: Jun 01, 2010

Posts: 6840
Posted: Oct 02, 2003 - 06:37 AM

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
HalbrookTech

Rank: Developer

Registered: Dec 31, 1969

Last visit: Jun 01, 2010

Posts: 6840
Posted: Oct 02, 2003 - 07:04 AM

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
jn

Rank: Helper

Registered: Apr 08, 2002

Last visit: Oct 21, 2009

Posts: 614
Posted: Oct 02, 2003 - 09:20 PM

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
HalbrookTech

Rank: Developer

Registered: Dec 31, 1969

Last visit: Jun 01, 2010

Posts: 6840
Posted: Oct 02, 2003 - 10:15 PM

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
jn

Rank: Helper

Registered: Apr 08, 2002

Last visit: Oct 21, 2009

Posts: 614
Posted: Oct 02, 2003 - 11:08 PM

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.
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

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
HalbrookTech

Rank: Developer

Registered: Dec 31, 1969

Last visit: Jun 01, 2010

Posts: 6840
Posted: Oct 02, 2003 - 11:48 PM

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?
jn

Rank: Helper

Registered: Apr 08, 2002

Last visit: Oct 21, 2009

Posts: 614
Posted: Oct 03, 2003 - 08:17 AM

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
HalbrookTech

Rank: Developer

Registered: Dec 31, 1969

Last visit: Jun 01, 2010

Posts: 6840
Posted: Oct 03, 2003 - 08:29 AM

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
jn

Rank: Helper

Registered: Apr 08, 2002

Last visit: Oct 21, 2009

Posts: 614
Posted: Oct 03, 2003 - 08:55 AM

I thought about something like

Code
pnModRegisterHook('user',
'login',
'API',
'MyModule',
'user',
'Func')
To be thought about
HalbrookTech

Rank: Developer

Registered: Dec 31, 1969

Last visit: Jun 01, 2010

Posts: 6840
Posted: Oct 07, 2003 - 05:18 PM

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