Unfortunately, testing the process from the frontend will only tell me what I already know and not what the problem is. I would need to see a Security Log entry or a php error log entry or a server log entry to tell me what the problem is. There is another approach that is a reverse engineering approach that can accomplish the same goal when you are working blind without any clues to work with. Here are those steps below.
1. Use the BPS htaccess File Editor and comment out all BPS Query String lines of code with a # sign EXCEPT for this line of code: RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
Example:
# BEGIN BPSQSE BPS QUERY STRING EXPLOITS # The libwww-perl User Agent is forbidden - Many bad bots use libwww-perl modules, but some good bots use it too. # Good sites such as W3C use it for their W3C-LinkChecker. # Use BPS Custom Code to add or remove user agents temporarily or permanently from the # User Agent filters directly below or to modify/edit/change any of the other security code rules below. # RewriteCond %{HTTP_USER_AGENT} (havij|libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR] # RewriteCond %{HTTP_USER_AGENT} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR] ... ... you would continue to comment out all other BPS Query String lines of code except for this last one below ... ... RewriteCond %{QUERY_STRING} (sp_executesql) [NC] RewriteRule ^(.*)$ - [F] # END BPSQSE BPS QUERY STRING EXPLOITS
2. If the shopping cart is working successfully then you would uncomment BPS Query String lines of code one by one and test to isolate which line or lines of BPS Query String code is causing the problem.
3. Once you have isolated that line or lines of code then you would save your manually modified root htaccess code to BPS Custom Code to save it permanently.