Tiggering Sync results in blank page.
| Project: | CiviRoles Sync |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | posco |
| Status: | closed |
First of all, this one modules solves a lot of problems for me, so I'm really hoping that I can get it working. Unfortunately, it's not going smoothly and I'm not sure how to proceed.
I'm running Drupal 5.1, MySQL 5.0.45, PHP 5.2.5, CiviCRM 1.9.13019, and tried both v1.2 and Dev-1.x of civimember_roles with the same result.
The module installed and enabled fine, I set up permissions so I could access it and configured some sync rules as listed below.
Rule ID Rule Name ("CiviMember Membership Type" --> "Drupal Role") Current Codes Expired Codes Operation
1 Student --> Club Member New, Current, Grace Expired edit delete
2 Certified --> Club Member New, Current, Grace Expired edit delete
4 Swimming --> Club Member New, Current, Grace Expired edit delete
5 Lifetime --> Club Member New, Current, Grace Expired edit delete
6 Student --> Expired Club Member Expired New, Current, Grace edit delete
7 Certified --> Expired Club Member Expired New, Current, Grace edit delete
9 Swimming --> Expired Club Member Expired New, Current, Grace edit delete
10 Subscriber --> Expired Club Member Expired New, Current, Grace edit delete
I then configured the module to sync roles on user login/logout. When testing, I was faced with a blank white page each time I logged out or logged in. If I refreshed the page, then I would get the view I expected to see in each case, but found that roles had not been updated appropriately.
I then tested the Manual Sync functionality, and it gives me the same blank page response.
The hard part is that this is on a hosted server and I only have access to very limited log files including access_log for apache, and the drupal logs.
Any suggestions for troubleshooting this would be greatly appreciated.
Thanks!
#1
My first reaction is that your PHP installation does not have enough memory allocated to it. You have 10 different rules and if you have a relatively large user base I can easily see PHP needing more memory to process that.
Can you get access to a phpinfo script and tell me what the memory limit is? I've attached an example of my personal localhost's phpinfo output. Also, how many members are you processing?
Since you are in a hosted environment, it will probably be very difficult to get your company to give you more memory if this is the issue. It doesn't hurt to send their support staff an e-mail and ask them. They may also be able to help you confirm that this is a memory limitation issue.
Please keep me updated. I will be more than happy to help you try and resolve your problems. I will also consider optimizing the code so it is more efficient.
#2
Thanks for the quick response, I actually just upgraded my account last week so that I could get enough memory to run CiviCRM.
Now I see phpinfo is telling me I have 45MB allocated which is less than I'd hoped for, but I would have thought it'd be enough to process 121 contacts and ~60 users. Though once I have everything running there'll be something on the order of 1800 contacts and ~120 users.
#3
I will look into changing the code around a little bit. Maybe as soon as this weekend. Now that I'm looking at the code, I can see that I can increase the efficiently by getting rid of some loops.
It's also a little troubling that you get blank screens using the user login/logout feature as that should only be dealing with one contact. My test database uses 125 contacts, with each one having a Drupal account. I will scale back my PHP's installation to 45MB and see what happens. However, when developing this module I was originally using a 32MB memory limit and not having any problems.
You are also using Drupal 5.1. Would it be possible for you to upgrade to Drupal 5.7? I haven't tested the module on 5.1 before.
How many modules are you using on your site? If you disable a few non-critical modules and try to sync, does that change the behavior at all?
#4
I'll try to set up a sandbox and see if I can reproduce the environment and problem there. If I can, I'll be better able to assist with troubleshooting. Then I'll try to upgrade and see what difference that makes.
Thanks again!
#5
Ok, now I feel like a dolt... starting to play, set the sync to happen with every page load by accident..and now I'm locked out... where is that config stored so I can manually tweak it back?
Thanks
#6
Nevermind, I managed to work around it by commenting out the following code in civimember_roles.module
/*//Synchronize user if they are authenticated and the config option is set
if (variable_get('civimember_roles_sync_method', 0) == 1) {
global $user;
if (in_array('authenticated user', $user->roles)) {
_civimember_roles_sync($user->uid);
}
}
*/
Then I was able to get to the site with a few error messages. Went disabled the module, then enabled it again, re-configured it appropriately (disabled automatic sync), and then went back and uncommented the above code.
While doing all that, I was able to set up a sandbox to tinker with, and can reliably reproduce the problem. However the sandbox by default has 128M of memory allocated, so I'm thinking this isn't a memory issue.
checking error_log for Apache I get the following message for every blank screen, so there doesn't seem to be any mystery about it.
[Wed Mar 5 14:30:53 2008] [error] PHP Fatal error: Call to undefined function session_save_session() in /Library/WebServer/Documents/drupal/modules/civimember_roles/civimember_roles.module on line 469I'm now going to play with updating drupal.
#7
Yay! Ok, well I've managed to update the sandbox to Drupal 5.7, and so far it seems to have been a relatively painless process. I'll have to poke around and make sure I didn't break anything, but Civimember_Roles is happy, and did what it needed to after triggering a Manual Sync. If I'm understanding correctly, this should be the most intensive type of sync as it hits all the contact and user records.
So off to test and eventually roll out to the live environment.
Thanks again!
#8
I will install Drupal 5.1 onto my localhost this weekend and see if I can't make the module compatible. Thank you for finding the code that was causing the issue.
In the mean time I would recommend switching to Drupal 5.7. The code you commented out is the code that handles the user login/logout syncing.
Yes, you are correct in that manual syncing is the most intensive.
#9
Oh and another thing. It makes sense that the session_save_session() function is causing the issue. This function is used for security reasons. When the syncing is performed the user is temporarily switched to user 1 in order to please Drupal's permissions. However, I didn't want to introduce a privilege escalation risk so I turned off session saving with that function. I was told on the mailing lists that this function was introduced as a security feature in one the of Drupal 5.x releases.
So, upgrading to Drupal 5.7 is even more encouraged as this plugs be a very huge security hole.
#10
While I was hesitant to do an upgrade for a long time (the original install was done by our provider), I'm growing in confidence with this hosting solution, and see there's no great mystery to it.
I completed the live upgrade just a little while ago, and all is wonderful again. Our members will be very pleased and I personally thank you for your support, patience and especially for writing the module in the first place.
Just so you know who's thanking you, we can be found at www.euc.ca.
#11
Automatically closed -- issue fixed for two weeks with no activity.