New Option Group giving error

Please let me suggest that you do not want to create an option group for financial contributions. You should be just adding those values as possibilities to the existing activity type option group. Financial activities need to be saved and manipulated like other activities.

You can integrate WP Issues CRM with a payment processor. I recommend using Gravity Forms as a front end form generator and Stripe as a payment processor. You can then set up a WP Issues CRM interface from your form to record contributions that are made through the form.

That does not explain the error, which I would like to get to the bottom of for you anyway. The area of the software that you are you are activating has been stable for a long time, so I am not sure why you are seeing this response. It could be some kind of local condition unrelated to the software itself. To debug it I would need to see your debug log. You might also be able to get additional error data viewing your error console.

• This reply was modified 5 years, 11 months ago by Will Brownsberger.

Hello, thank you for the quick reply! I believe that I did what you said and created option values in ‘Activity Types’. I have some learning to do to set this up. I am not clear on what everything does. Mainly we want to take donations and keep a database of all of the supporters so that we can reach out to them.

I am planning on using Gravity forms but planned to use Paypal for processing.

I am a bit on the fence about using this plugin or using the Zero BS CRM plugin. There is an extension that they offer that will sync with the paypal account so that donations that are taken remotely are synced with the CRM.

Is there any way to accomplish this with WP Issues?

Yes, you just need to set the Gravity form that you are using to connect to PayPal up as an Interface in WP issues CRM.

Any entry you can do through a Gravity form to your payment system can be simultaneously synched to WP Issues CRM.

Try the “Interface” menu. For a working example, see https://votebrownsberger.com/wordpress/donate/

In absence of further inquiry, I’m marking this as resolved, but feel free to reach out if you want to pursue it further.

Hi Will,
I have been making progress, but just ran into the same issue again,this time with the Interface section. I made my Gravity form and went to the interface section. I filled it out and hit save and got this message:

Network or server error in response to ajax POST.
jqXHR.status: 500

jqXHR.statusText: Internal Server Error

errorThrown: Internal Server Error

Inspect server error logs and/or browser console for possible additional information.

The Console gives this error:

/wp-admin/admin-ajax.php:1 Failed to load resource: the server responded with a status of 500 (Internal Server Error)
ajax.js?ver=4.3.2:423 ajax POST (in module ajax.js, function mainFormButtonPost) returned an error. jqXHR: Object textStatus: error — errorThrown: Internal Server Error

Follow up,

I tried disabling all other plugins and still got the same error. I then tried it again a couple times and the second time I tried I used the bottom save button rather than the top and it worked. I am not sure why.

Final resolution of this problem turned out to be that an inadvertent change by the user’s web hosting company had increased the sensitivity of security rules so that they were generating false positives and bouncing legitimate transactions.

I offered the guidance pasted below, but the issue was resolved by the webhosting company reversing their inadvertent change.

For future reference:

The error logs showed that what was happening is that a particular apache mod_security rule was triggering a false alarm and blocking the request.

ModSecurity: Access denied with code 44 (phase 2). Match of “eq 0” against “MULTIPART_UNMATCHED_BOUNDARY” required. [file “/etc/httpd/conf.d/mod_security.conf”] [line “34”] [id “xxxx”] [msg “Multipart parser detected a possible unmatched boundary.”] [hostname “XXXXXXX.com”] [uri “/wp-admin/admin-ajax.php”] [unique_id “XXXXXXXXXXXXXX”], referer: https://XXXXXXXX.com/wp-admin/admin.php?page=wp-issues-crm-main&entity=advanced_search&action=new_blank_form&id_requested=0

If you google parts of this phrase, you will see that it is not an uncommon problem with multiple applications. This security rule does trigger false positives.

The solution is to downgrade the response to this particular rule (“MULTIPART_UNMATCHED_BOUNDARY”) firing from ‘block’ to ‘log’.

In fact, the relevant mod_security documentation recognizes the possibility of false positives and suggest the solution here:

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#MULTIPART_UNMATCHED_BOUNDARY

Basically, the fix is to modify one line in the mod_security configuration file to set the variable MULTIPART_UNMATCHED_BOUNDARY as follows:

SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"phase:2,id:31,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"

It would appear that you just want to REMOVE the word “deny” from this rule line, but check mod_security documentation.

https://support.kemptechnologies.com/hc/en-us/articles/209635223-How-to-write-a-WAF-rule-Modsecurity-Rule-Writing

• This reply was modified 5 years, 10 months ago by Will Brownsberger.
• This reply was modified 5 years, 10 months ago by Will Brownsberger.
• This reply was modified 5 years, 10 months ago by Will Brownsberger.