CiviCRM Community Forums (archive)

I have a profile form that uses a large number of custom fields (30). It also has two drop-downs with a choice of about 500 options each (languages and ancestry from international standard) and includes 5 file upload fields. About 30% of 500 users are getting the above error when saving the form. I personally cannot simulate the error as the form works fine for me.

Could you please provide guidance on isolating the error. It does not appear to be related to internet bandwidth as cable users experience the problem and the host service provider assures me the server is not busy.

The problem occurs for both authenticated and anonymous users.  I am running Drupal 5.1 and Civic 1.7

The form is invoked for authenticated users by the following link in a drupal content node  (anchor tags removed):

href="http://testfiles.com.au/drupal51/user/login?destination=civicrm/profile/edit?reset=1%26gid=1">sign in as a listed <em>individual</em>

I have checked that all the form fields are from the available (individual) options when building the form.

Some of the custom data is assigned to contact. It appears in the individual field options so I assume this is OK and it works (well 70% of the time).

I have checked the users have access to profiles and custom data. There are no defined ACLs.

Is it possible the error does not relate to the form at all but to a timeout error?

The problem happens whether file uploads are being processed or not.

Is it possible the error only occurs when a user fills in a particular field? (I have tried all the fields and they appear OK)

Are there any configuration parameters to adjust to allow this large form to be processed better if it is a processing issue?

Any guidance appreciated,

David

(By the way a 2Mb file takes over a minute to upload using the form over cable - is this normal?)

A bit more information...
Item 1:

I have what appears an unrelated problem but maybe they are linked. My profile form has a field individual-phone-home-phone. If I do an advanced search and I look at the data using the built-in contact form the home phone numbers appear in the list (and in the home fieldset when viewing the record). If I use the profile form as the search view the home phone number column is visible but the phone numbers are not listed. The form has the home number field set as searchable and in selector. The phone numbers are not visible when viewing an individual record.

Item 2:

The client has an existing site. The drupal/civic site is visible within a 100% sized frame on the existing site. The client has done this as the drupal/civic site is not yet accepted and they do not want their customers going to a new url until they are sure it is working (which it isn't). Could "hiding" the url in the frame be part of the problem? if so why for only 30% of the users?

Dave - I did not have user registration ticked. I was directing them to the login and then ?destination= processing them with the form and didn't consider it part of the registration. Hopefully it's the solution. Thanks for the feedback - so very much appreciated.

Some limited testing points to the frame being the cause of the error. When users who previously experienced the above issue are sent directly to the site the problem disappears (100% OK on 10 users all on IE). I went through the drupal log looking for errors relating to the get (submit) with none to be found. Am I looking in the right place for the errors or is there a civi-log somewhere? Thanks for helping isolate this. The  civicrm code stands up fine despite the beating it gets with this form design and custom data requirements.

I assume if I build my own custom tables I won't be able to use the profile form builder natively. Is this correct? Should I be using CCK instead of profiles with this many fields and keeping the CRM element seperate?

Any guidance would be appreciated.

 

Good advice!!

I will stick to the initial strategy of all data in civicrm for the moment. Civicrm does meet the requirements very well even though I am abusing the SQL joins for all the custom data.  The forms do work but I will take your advice and split them up a little.  Once the profile is split up I can see how to manage the EDITS using the contact id in the URL but if I  ADD a NEW contact entry across say 3 forms as an anonymous drupal user how do I ensure that the second and third forms are adding (or really now editing) data to the same entry?
Is there a way to get the newly created contact id after the first form is saved and before the next form is loaded as a post-process?

David

Thanks lobo. I might wait till version 2.0.

To summarize this long topic for other newbies like me.

1. The error that this topic discusses is NOT related to the civicrm code. It appears to be an issue with IE browsers losing the session when the URL is "hidden" in a frame. The civicrm code is fine.

2. If you are building a form with lots of custom data be aware of the following for civicrm 1.7:

Each custom data item is a table whether it is in a group or not. MySQL has a join limit of about 60 tables which limits custom data fields to about 30 MAX (20 is safe) depending on what you are doing. If you use more fields in the form you will get a SQL error when presenting/saving the data.

3. If you need to use more fields than can be put on one form you can split the form. Splitting the form will work if you register each user first with a mini form that captures first name, last name and email address (assuming you are using these fields to avoid duplicates). Mark this mini form for User Registration and View/Edit User Account so that it is completed as part of the cms registration process. You can then proceed to complete other the other component forms.

4. The simple way for the user to complete the remaining component forms is to register these forms for User Registration and View/Edit User Account so that they are available as tabs on the cms user profile. THIS METHOD WILL NOT WORK if your forms have a file upload field as there is a problem with processing the form when it is part of the cms user profile. You have to use the method in 5 below. When using the tabbed approach on non-technical users I found they did NOT save each subform on the tab and became frustrated with lost data and they also did not realise that each tab meant more data to be completed, no matter how much you spelled it out to them.

5.  The more complex way is either by using a menu (step1, step2 etc) directing the user to each form off the menu OR by initially directing the user after registration/login to the next form using the user/login?destination=civicrm/profile/edit?reset=1%26gid=N option. (Note & must be written as %26 if in a menu or node anchor). You can then tail one form to the next by using the Redirect URLs for save and cancel (in Advanced Settings on the form).

6.  You MUST register the users first in the crm and civic before moving them through the split forms. If an anonymous user moves from form to form civicrm cannot determine that each form relates to the one record.

7. Last tip: The file upload is fraught with challenges as users will try to load files larger than PHP will process or will become impatient with the upload and abort the session. So put file uploads last on a seperate form. At least all the other data is saved if the session is aborted.
 
Thanks again to Dave and lobo for getting me on track..