Redirect works now followingly:

1. visitor enters page => redirect to unauthenticated page
2. visitor registers and enters in page => redirect to unauthenticated page
3. visitor enters again later and is authenticated by the cookie => redirect to authenticated page

The module I downloaded for 4.7.x seems to be dated back in April, is that the latest one?

Comments

dublin drupaller’s picture

dublin drupaller commented

thats not the latest version.

For the moment just put some text into the text area, like "redirecting" for the duration. I'm having problems tagging and branching files on the new CVS system. I'll email you a copy later rmac.

Dub

dublin drupaller’s picture

dublin drupaller commented
Status: Active » Fixed

Download a more recent version of the module (compatible with Drupal 4.7.x) from here:

http://ftp.osuosl.org/pub/drupal/files/projects/front-4.7.x-1.0.tar.gz

apologies for the inconvenience, I keep getting error message from the CVS and am unable to tag & branch updates to the module correctly.

Dub

rmac897’s picture

rmac897 commented

Sorry to say but I still have the same problem with the version attached. If user is not logged in, it redirects correctly. When the user logs in, it still redirects to unauthenticated page. However if the browser is closed and reopened, then the redirect works.

dublin drupaller’s picture

dublin drupaller commented
Version: 4.7.x-1.x-dev » 4.7.x-2.0
Assigned: Unassigned » dublin drupaller

Hi Rmac,

Apologies for the delay in following up with this, I had some problems tagging and brancing the releases properly, so ppl were probably downloading a very old version of the module.

please find the latest version for Drupal 4.7.x at this link below. I've tested it on a fresh install of 4.7.5 and it works as it should. I've also rolled back the new feature in the Drupal 5.x version of the module (front page by role type).

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/front/front_p...

Cheers

Dub

dublin drupaller’s picture

dublin drupaller commented

Rmacs..can you switch on your contact form..I was trying to get in touch and couldn't.

Dub

jsinbc’s picture

jsinbc commented
Version: 4.7.x-2.0 » 4.7.x-4.0
Status: Fixed » Active

I know how much work it is to write code and really do appreciate the efforts of folks who contribute to Drupal.

I downloaded the CVS version as directed earlier in this thread, installed it, created some text for anonymous users, specified logged in users get redirected to "node" and set "node" as the default for authenticated users.

Worked fine for anonymous users. Logged in users got a blank page.

Turned on the breadcrumb redirect and set it to "node". Worked fine for logged in users but anonymous users were also directed to "node".

Took a look at the code and noticed that the breadcrumb redirect is not enclosed in a if ($user->uid) block so it will be activated for any visitor.

Included the breadcrumb redirect within a test for logged in (and moved the global declaration up to precede it) and it's working as I expect it to be - i.e. displays a custom page if you're not logged in and recent posts if you are.

I'm not displaying different pages based on user roles, nor am I including php code or any such - I'm only using the very basic features of the module - i.e. "front page lite" if you will - and haven't tested to see if this hack works elsewhere.

Jim

Phillip Mc’s picture

Phillip Mc commented

As far as I know the breadcrumb redirect is supposed to be the same for anonymous and authenticated users. So it shouldn't be enclosed in a 'is this user logged in' check.

Check this box if you want to redirect users who click on any HOME links (including the HOME breadcrumb link). Useful if you have a splash page you don't want users brought back to when they click on HOME links from within your site.

I only use the breadcrumb redirect if I have a SPLASH page I don't want everyone brought back to when they are already on the site.

However, while it starts to get a little complicated, I suppose the module could be expanded to specify a custom HOME breadcrumb override for each Role type. So you have an Anonymous breadcrumb link, Authenticated home link and so on for other roles.

Phil

jsinbc’s picture

jsinbc commented

Right. I understand that. But ...

If you want to, for example, send logged in users to the standard recent postings page (e.g. "node") and you want to block this from users who are not logged in you're caught between a rock and a hard place.

Separate redirects for anonymous and logged in would be sweet. More work though.

Perhaps I'm trying to use this module for a purpose for which it was not intended - i.e. display a "welcome" page and hide content from everyone who is not logged in.

Of course I could block access to "node" for anonymous users but that would result in a "Page Not Found" message when anyone who is not logged in visits the site and wouldn't provide me with the opportunity to display the welcome page.

Phillip Mc’s picture

Phillip Mc commented
Status: Active » Closed (works as designed)

Perhaps I'm trying to use this module for a purpose for which it was not intended - i.e. display a "welcome" page and hide content from everyone who is not logged in.

That's precisely what I use the front_page module for. Use the text area for anonymous users under admin-> settings-> front_page to display a welcome message and redirect logged in users to /node/.

Phil

Phillip Mc’s picture

Phillip Mc commented
Priority: Critical » Minor

Perhaps I'm trying to use this module for a purpose for which it was not intended - i.e. display a "welcome" page and hide content from everyone who is not logged in.

That's precisely what I use the front_page module for. Use the text area for anonymous users under admin-> settings-> front_page to display a welcome message and redirect logged in users to /node/.

setting this issue to 'by design'.

Phil

jsinbc’s picture

jsinbc commented

Ok so we're both doing the same thing.

The only reason I started using the breadcrumb redirect was since without it logged in users were presented with a blank page.

I downloaded the CVS version as directed earlier in this thread, installed it, created some text for anonymous users, specified logged in users get redirected to "node" and set "node" as the default for authenticated users.

Worked fine for anonymous users. Logged in users got a blank page.

So unless I've configued it incorrectly the bug described earlier in the thread is still present.

rmac897’s picture

rmac897 commented
Priority: Minor » Critical

I'm sorry but I just cannot figure out what is wrong here. I'm using front_page version 4 in the simpliest way, just using the redirect fields. I also try to keep things simple and only use anonymous/authenticated, not roles. User who is not authenticated will see a splash and user who is authenticated will see view/front.

Now what is happening is:
1. visitor enters page => show splash (ok)
2. visitor registers and enters in page => show splash again (not ok)
3. user enters again later and is authenticated by the cookie => show empty page, no errors logger (not ok)
4. user clicks home -breadcrumb => show view/front (ok)
5. user logs out => attempting to show view/front but since has no permission anymore, will show register/log in window (not ok)

Phillip Mc’s picture

Phillip Mc commented

http://drupal.org/node/111828#comment-192461

rmac897’s picture

rmac897 commented

Ok half of the problem is now solved when using login_destination module together with front_page. It would be good to mention in readme that the two should be used together to avoid problems. Now the only remaining problem is the empty page in case of authenticated user:

1. visitor enters page => show splash (ok)
2. visitor registers and enters in page => show view/front (ok)
3. user enters again later and is authenticated by the cookie => show empty page, no errors logged (not ok)
4. user clicks home -breadcrumb => show view/front (ok)
5. user logs out => show register window (not ok but not a major problem)

Phillip Mc’s picture

Phillip Mc commented

-1 from me to recommend using the login_destination.module like that.

The main reason why is because the default setup with Drupal is ideal and it's the standard online. i.e.

- Person visits a page on the site that requires login
- if they are not registered, they go to registration
- if they are registered and logged in they see the page.
- if they are registered but not logged in, they login and they automatically see the page they wanted.

Simple. By changing the login_destination, you lose that simple ergonomics, i.e.:

- Person visits a page that requires login
- if they are not registered, they go to registration
- if they are registered but not logged in, they login
- visitor is forced away from the page they wanted to view and brought to the front page instead.
- they have to try and find the page they wanted to view.

Not good.

have a look at this thread here: http://drupal.org/node/111828#comment-192461

Phil

rmac897’s picture

rmac897 commented

There are two different cases. In one case the page visitors enters can be any page, referred by Google or whatever. There is interesting content and that will make the visitor to register. In this case the first example is good, to allow registration but keep in the same page.
The second case is a splash front page, where the splash contains some sort of teaser, e.g. 'register now'. It might even contain a link to user/register. In this case there is a major problem if the same splash is viewed again because you don't want to show user/register to a user who already is authenticated.

It would be great to have the redirects working in front_page because it would make managing it with all the different roles so much easier.

Anyway, regarding this bug report, the only remaining problem is the empty page in use case 3. Case 5 is a nice to have.

Phillip Mc’s picture

Phillip Mc commented

that's a simple mistake to make.
Have you seen the following comment about using redirects?

http://drupal.org/node/111828#comment-192461

Phil