"Log in" on contrb pages not governed by settings.php or resource ulr settings?

[jobewan]

Hi,

Long story short: I had to migrate my site, and set up the SSL cert for "domain.com" rather than "www.domain.com".  I am in process of changing this in order to avoid domain mismatch errors, but for now, I have need to use "https://domain.com", which works, until I can get the existing ssl cert canceled, and a new one mapped to use "https://www.domain.com".

I have:

- removed the "www" prefix from Drupal's settings.php for the "base_url" parameter.  This has temporarily stopped the ssl mismatch error when going from the initial contribution page, to the field confirmation page.  Great.

- removed the "www" prefix from any CiviCRM Resource URLs

- removed the "www"prefix from the CiviCRM "Update Directory Path and URL" setting

- confirmed that all the url_homepage values in the civicrm_contribution_widget table are "http _isctm.local_.htm"

HOWEVER, if someone is an existing member, and they heed the advice on the contribution page, "Please enter a user name to create an account . If you already have an account, please login before completing this form." the link is pointed to "www.domain.com", and it causes an ssl mismatch error on the visitor's browser.

This is an urgent matter for me, as my hosting provider is moving as fast on the ssl cert changeover as someone swimming in molasses.

Please help if possible,

-J

[Donald Lobo]

check:

http://wiki.civicrm.org/confluence/display/CRMDOC/Moving+an+Existing+Installation+to+a+New+Server+or+Location

ensure u follow all the steps

lobo

[jobewan]

Thanks Monsieur Lobo.  (O.

It was the CIVICRM_UF_BASEURL variable.

[jobewan]

Hi Lobo,

One last (I think) glitch:

Hi,

When a non-authenticated visitor [who is already a member] accesses a contribution page, there is a message they need to pay attention to:

" If you already have an account, please login before completing this form."

When they log in and become authenticated, they are taken to the home page instead of back to the contribution page they were using.

Can  you help me fix this?

Thanks!

-J

[jobewan]

Lobo,

What I have gathered at this point is that the template governing the login function from a contribution page is not using a dynamic parameter to "catch" the filename from which the login is being launched, and as a result is unable to return to that page.

This is a major problem for me (of course), but really I would think for anyone, especially if they are sending our renewal notices (as I am) to folks who understand their field of endeavor, but not website mechanics.

Am I using an old template, or is this a current issue?

Any help as always . . .

-J

[jobewan]

The CiviCRM demo site appears (to me anyway) to have the admin section locked out for demo users, and the contribution pages locked out to non-authenticated users.

As a result, I cannot test whether or not a login launched from a contribution page by a non-authenticated user who then logs in is going to the home page on the demo site, or not.

[Donald Lobo]

The login block is controlled by drupal.

I suspect you can achieve what you want to do, by using one of drupal's hook (maybe a redirect on _login?)

u'll need to explore and figure out a solution. if you do so, please publish your findings and code so others can benefit

In the past, we've asked folks to login first and then the home page prominently displays the membership renewal link etc

lobo

[jobewan]

L,

While I am fully knowledgeable about the circumstances, I am not up to speed sufficiently on the programming end to attempt this on a production site.  I am soliciting help, and am perfectly happy to share the results with my community members.

Best,

-J

[Dave Greenberg]

I'm looking at a solution for including the destination parameter in the "Login" link that we include when "Create user account" block is part of an online contribution, membership signup or event registration form. This would be a Drupal only solution (for the moment) since I haven't found a way to pass a "redirect after login" URL parameter for Joomla. I'll post back here with results.

[Dave Greenberg]

Thx for pushing on this and getting us to think a bit more about it. A fix to include "destination=" in the "please login" link is committed and will be part of 3.1 release:

http://issues.civicrm.org/jira/browse/CRM-5360

If you need this sooner, you can probably backport this to your 3.0 install by getting the diff from the issue tracker (it only affects one php file).

[jobewan]

Hey ev'rbody,

If'n I helped in some small way to improve the product, I am very pleased to have done it.  (-.

Wish I could actually do the programming piece, but I 'm just now getting to where I can actually read the code for the most part.  Thanks to every/any one doing the heavy lifting.

I'll look into retrofitting my 3.01 install once the requisite file from 3.1 is available.

-J

[jobewan]

Hello all,

As promised, this is what was done to make the Drupal login block contained on the Contribution pages to come back to the Contribution page in question on my 3.01 system:

- Line 233 in the file, CMSUser.php, located in webroot/sites/all/modules/civicrm/CRM/Core/BAO/ was originally:

          - $loginUrl .= 'user';

changed to:

          - $loginUrl .= 'user?destination='.str_replace('&','%26',$_SERVER['REQUEST_URI']);

This resulted in the use of the Drupal login block contained within each Contribution page to come back to the Contribution page in question.  Good.

It also resulted in a problem.  Bad.

The problem being that when someone logs in Drupal from any page other than the contribution pages, they are taken to: http://domain/login-redirection, which throws a "content not found" error page.

At this point, the Login Destination add-on Drupal module has to be moved to the circular file (dumped), as it was seemingly/probably causing with this newest issue, and wasn't doing anything else that was good.

The secondary issue from that one is that the Drupal default is to take the user to their account page, which could not be a stupider option for my members, especially since the Drupal side of the house is built to either give access to controlled content, or block access to same.  CiviCRM is doing all the other lifting.  I would rather they end up on the home page, if not the page they were on when they logged in.

This latter issue was dealt with in the short term by modifying line 168 in the template.php file of Drupal 6.13, located in domain/sites/all/themes/themeinquestion/.  This file contains a Drupal login block that appears that the top of all site pages:

          - line was: $loginUrl .= 'user';

          - line is now blank

This is not an altogether wonderous solution, and we/I haven't had a chance to test thoroughly, as it was just done today, and so it is not altogether completed, and will not likely look a great deal like the hack immediately above.  At the moment, the user is brought to the home page if they use the top page login block, and back to the Contribution Page in question if they use that login block.

Hope that helps out.

-Joe

[Dave Greenberg]

For others following this thread - the actual fix committed for the 3.1 release can be seen at this URL (it's a "diff" from Fisheye):

http://fisheye2.atlassian.com/viewrep/CiviCRM/trunk/CRM/Core/BAO/CMSUser.php?r1=24668&r2=24920

This resulted in the use of the Drupal login block contained within each Contribution page to come back to the Contribution page in question.  Good.

It also resulted in a problem.  Bad.

The problem being that when someone logs in Drupal from any page other than the contribution pages, they are taken to: http://domain/login-redirection, which throws a "content not found" error page.

I'm a bit confused by the above statements. I don't understand how a change to civicrm/CRM/Core/BAO/CMSUser.php could affect what happens to users when they login from other locations. The code change we made simply passes a "destination=" parameter to the login form WHEN a user clicks that specific link in a CiviCRM form which has a "Create Drupal User" option enabled (like your contribution page).

Perhaps that part of your post is solely related to the way you implemented the Login Destination module ??

[jobewan]

Hi Dave,

I believe your statement is exactly correct.  As I tried to make clear, while I understand a good deal of the flow, I am not a coder.  The first step in attempting a workaround to the Contribution Page issue, I downloaded and installed the Login Redirection module.  It became clear very quickly that this module would not likely help out, and so it was immediately abandoned, without being configured.  I actually forgot to uninstall it while working on the overall issue with my coder associate.

The patch my associate made is on my 3.01 system only, and has nothing whatever to do with your implementation in 3.1.  Just checking to make sure that is clear.

Why and how hacking the CMSUser.php file would result in modifying another Drupal login block is not something I can explain so much as simply report.  I collected as much information as possible in order to produce some sort of meaningful report.  It is possible that some adjustment outside of the CMSUser.php and template.php files took place, but based on what I saw, it seems unlikely.

Additionally, if you and/or your crew ultimately make it simple to retrofit 3.01 with your "official" destination solution, this thread will be rendered relatively useless.  I had this done to my system in the hopes of bridging the period between right now, and when the official option comes to bear.