CiviCRM Community Forums (archive)

Hello, we've recently upgraded to joomla 2.5 on our site, which required an upgrade to civicrm 4.0 from 3.2.4. All tests showed this migration to work fine for data, but what we've now found is an error when using our payment processor, which throws this error when a payment is attempted:

The website encountered an error while retrieving https://[website]/administrator/?option=com_civicrm&task=civicrm/contact/view/participant. It may be down for maintenance or configured incorrectly.
Here are some suggestions:
·         Reload this webpage later.
HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request.

What concerns me is the fact that there doesn't seem to be an id being passed, only an option and a task. Is this something I should look into? The logs are empty, of course.


rchapman

yes, there is absolutely nothing in my apache log. It is quiet during the 500 error, even though it receives other civicrm errors. Can you upgrade 4.0.0 straight to 4.2 stable? I'll try that if that's the case.

I'm also getting an error on some pages about 'your database is configured to use MyISAM...' instead of INNODB. Which I find odd, as it is a direct mysqldump of the previously working database, only upgraded to 4.0 using the upgrade script within civi. Can I change this, or do I need to convert outside of civi and re-install?

r

This did not seem to be the issue. The SSL links were not always defiined as https, so I have selected 'force ssl URLS' in the admin console, and that has solved half of this problem.

The processing of payments is now confirmed as using https links, but when you select 'continue' upon the confirmation page, I now get a blank white page, no errors in the apache log. We can also confirm that the payment itself is not being processed.

I've had issues previously where a small error in civi does not flag as an error. I may just need to follow the process and hope there is a small step we missed.

it also does not seem to be 100% passed by POST, as there is a value for 'task' which is the participant option. While it is obvious there should not be the credit card/payment information in the URL values, there should at least be something for a participant id, should there not? This seems to be the main reason why the script fails, despite not showing any error in a log file.

Any suggestions where to start on debugging this?

rchapman