CiviCRM Community Forums (archive)

Found an oddity when using civivolunteer on a Panopoly distro on MAMP.  This isn't an issue with the standard Drupal distribution.

When trying to define/assign volunteers, after clicking the button the screen just stalls with the progress indicator spinning.  Inspecting the console shows that a call to the api fails:

[Error] Failed to load resource: the server responded with a status of 500 (Internal Server Error) http://localhost:8888/afp/civicrm/ajax/rest?entity=volunteer_need&action=get&json=%7B%22api.volunteer_assignment.getcount%22%3A%7B%7D%2C%22project_id%22%3A1%7D)
There are also so unsuccessful calls to backbone js libraries, failing because they are looking for the .map files instead of the .js files.  That seems to happen regardless of the drupal distribution.

I'm not sure which program isn't playing nice here.  I don't have the skills to figure this out - but any suggestions are appreciated!

I haven't tested ALL the functionality in CiviCRM as this site is still in development - but other CiviCRM functions seem to behave normally. 

The 500 error is only seen in the console, not on the site.  Thus no backtrace, and the only description in the console is "Internal Server Error".

This led me to trying another Panopoly site on the same MAMP server ... and it (of course) worked just fine, so this is indeed probably a configuration error.  I've checked (and re-checked, and copied and pasted) both the Resource URL and Directories... the problem isn't there.  I'll need to explore further to see what the differences are between these two sites.

Yes, you might be able to get more info from firebug or otherwise replicating the call manually.
A 500 is not a javascript error though, so it should be able to be logged on the server.

It sounds like maybe your php error_reporting level is not high enough.
http://www.phpknowhow.com/configuration/php-ini-error-settings/

Hope this helps

Hershel:

Good idea!  Did that ... still no displayed errors or backtrace and nothing in the console either.  Found a fatal error in the php error log: PHP Fatal error:  Class name must be a valid object or a string in /Applications/MAMP/htdocs/afp/sites/all/modules/civicrm/api/v3/utils.php on line 1019

Inserted "error_log ($bao_name);" at line 1019 in both the failing site and the working site.  The working site produces multiple $bao_name entries, starting with "CRM_Volunteer_BAO_Need".  The broken site displays a null entry (or is it an empty value? hard to tell from the log) and then the same fatal error message.

So we've got a class for bao_name that is either null or empty.

Michael:

I've verified both the directories and resource URL entries... even copy and pasted from the working site (with edits to one directory in the path).  Same problem.  The working site does have a custom php directory defined, but that's the only difference.    Both sites have CRM_Volunteer_BAO_Need.php in the correct place.

Starting to think about just refreshing the civicdm module files and see what happens.

Xavier,

Interesting idea. Yes, Need and Project are custom entities accessed with the API.
I'm trying to think what could be installation specific that could cause this to fail though. Except for the extension directory.

https://github.com/civicrm/civivolunteer/tree/master/api/v3

CiviVolunteer doen't support less than 4.4.

Xavier:  the "broken" site is using 4.4.5 on Drupal 7.28 - and the "working" site was running 7.27.  Curious thing... when I used drush to update to 7.28 it broke in the same manner.  Yet another site spun up with 7.27 and 4.4.5 still works after upgrading to 7.28.   This is weird - and probably some edge case.  I'll keep exploring it.

Michael: Thanks for the backtrace link ... this is what it generates:
#0 _civicrm_api3_basic_get(, Array ([api.volunteer_assignment.getcount] => Array (),[project_id] => 1,[check_permissions] => 1,[version] => 3)) called at [/Applications/MAMP/htdocs/afp/sites/default/files/civicrm/extensions/org.civicrm.volunteer/api/v3/VolunteerNeed.php:77]
#1 civicrm_api3_volunteer_need_get(Array ([api.volunteer_assignment.getcount] => Array (),[project_id] => 1,[check_permissions] => 1,[version] => 3)) called at [/Applications/MAMP/htdocs/afp/sites/all/modules/civicrm/api/api.php:87]
#2 civicrm_api(volunteer_need, get, Array ([api.volunteer_assignment.getcount] => Array (),[project_id] => 1,[check_permissions] => 1,[version] => 3)) called at [/Applications/MAMP/htdocs/afp/sites/all/modules/civicrm/CRM/Utils/REST.php:360]
#3 CRM_Utils_REST::process(Array ([0] => civicrm,[1] => volunteer_need,[2] => get), Array ([api.volunteer_assignment.getcount] => Array (),[project_id] => 1)) called at [/Applications/MAMP/htdocs/afp/sites/all/modules/civicrm/CRM/Utils/REST.php:593]
#4 CRM_Utils_REST::ajax(Array ([0] => civicrm,[1] => ajax,[2] => rest))
#5 call_user_func(Array ([0] => CRM_Utils_REST,[1] => ajax), Array ([0] => civicrm,[1] => ajax,[2] => rest)) called at [/Applications/MAMP/htdocs/afp/sites/all/modules/civicrm/CRM/Core/Invoke.php:289]
#6 CRM_Core_Invoke::runItem(Array ([id] => 210,[domain_id] => 1,[path] => civicrm/ajax/rest,[access_callback] => Array ([0] => CRM_Core_Permission,[1] => checkMenu),[access_arguments] => Array ([0] => Array ([0] => access CiviCRM,[1] => access AJAX API),[1] => or),[page_callback] => Array ([0] => CRM_Utils_REST,[1] => ajax),[breadcrumb] => Array ([0] => Array ([title] => CiviCRM,[url] => /afp/civicrm?reset=1)),[is_ssl] => 0,[weight] => 1,[type] => 1,[page_type] => 0,[page_arguments] => )) called at [/Applications/MAMP/htdocs/afp/sites/all/modules/civicrm/CRM/Core/Invoke.php:72]
#7 CRM_Core_Invoke::_invoke(Array ([0] => civicrm,[1] => ajax,[2] => rest)) called at [/Applications/MAMP/htdocs/afp/sites/all/modules/civicrm/CRM/Core/Invoke.php:52]
#8 CRM_Core_Invoke::invoke(Array ([0] => civicrm,[1] => ajax,[2] => rest)) called at [/Applications/MAMP/htdocs/afp/sites/all/modules/civicrm/drupal/civicrm.module:456]
#9 civicrm_invoke(ajax, rest)
#10 call_user_func_array(civicrm_invoke, Array ([0] => ajax,[1] => rest)) called at [/Applications/MAMP/htdocs/afp/includes/menu.inc:517]
#11 menu_execute_active_handler() called at [/Applications/MAMP/htdocs/afp/index.php:21]

Glad you sorted it out.

Consider offering a beer to michael next time you see him

Xavier, Michael:

Yes - beer is owed! Thanks for not immediately hitting me with the "user error" stick - its better when I get to it on my own and learn something on the way.

And that post had some unfortunate automatic spelling de-correction... its "distros" not "distress" and "CiviCRM and CiviVolunteer".

SO the moral of the story is ... if you're using a Drupal distribution other than core and you get weird behavior in CiviCRM -> you probably broke it with a bad update process!