brownowl

To add to the above, the "Clear Formatting" Menu option had no effect, which again, compounds the problems with the editor. Regards, Laurie.

Hi, John, This is a really good add-on, which I am trialling at the moment. It has enormous potential: well done, and thanks. However, I have found three glitches so far, two are irritating, and the other a real problem. The first is that occasionally, seemingly at random (ie. I haven't quite worked out why it happens of what causes it - except see below), [submit Changes] has no effect, and it is necessary to back out a couple of levels, or sometimes to go right back to the traditional Admin screen, in order to clear it. Of course, changes made are lost. The second is that <shift-delete> works, but <shift-insert> doesn't; it requires Ctrl-V in order to paste. I could live with this, except that <shift-insert> is one of the causes of the failure of [submit Changes] above, and the one I habitually use. The serious problem is with the editor. There are several problems here. Clicking on a drop-down menu has the expected result, but it is not possible to dismiss the drop-down without choosing an option. Show Blocks does not work consistently, which compounds the problem below. This one is a killer for me. It seems that is not possible to insert raw HTML into a product description. For instance, and specifically in my case, <br />, which comes out in the description as literal text. This makes it very hard to lay out text properly. It also seems that once some text has been put into a paragraph, it is not possible to add a new paragraph, or another block. I accept that I may be mis-using the editor, in which case some guidance would be appreciated, but there is definitely a case for allowing people to have access to raw HTML. Regards, Laurie.

Hi Jim, Just want to say that I installed this add-on onto V2.3.3 and it worked a treat. The code and the documentation are a fine example of how these things should be done. I had just one discrepancy, which I put down to a difference between the version of 2.3.x when you wrote it, and 2.3.3, and that was when modifying catalog/admin/modules.php I found, in addition the the "Line 38" difference, a second one as below at line 245, where the top one is the one included in your kit: 274c273 < $contents[] = array('align' => 'center', 'text' => tep_draw_button(IMAGE_EDIT, 'document', tep_href_link(FILENAME_MODULES, 'set=' . $set . (isset($HTTP_GET_VARS['module']) ? '&module=' . $HTTP_GET_VARS['module'] : '') . '&action=edit')) . tep_draw_button(IMAGE_MODULE_REMOVE, 'minus', tep_href_link(FILENAME_MODULES, 'set=' . $set . '&module=' . $mInfo->code . '&action=remove'))); --- > $contents[] = array('align' => 'center', 'text' => tep_draw_button(IMAGE_EDIT, 'document', tep_href_link(FILENAME_MODULES, 'set=' . $set . '&module=' . $mInfo->code . '&action=edit')) . tep_draw_button(IMAGE_MODULE_REMOVE, 'minus', tep_href_link(FILENAME_MODULES, 'set=' . $set . '&module=' . $mInfo->code . '&action=remove'))); On the grounds that this difference was probably spurious, I ignored it and only made the "Line 38" change. The add-on has worked perfectly. Many thanks, Laurie.

Just to put this one to bed... I rebuilt the whole shop from the base up, re-installing the latest version of every one of the many plug-ins we had. Last of all, I put Protx V4.4 on. Guess what! Not a problem! I don't think we'll ever know what the problem was, clearly it was not your fault, Tom. I can only conclude there was an incompatibility somewhere with a plug-in. Thanks one and all for your help, and thanks, Tom, for a top piece of work. Cheers, Laurie.

No! Thanks for your help, Laurie.

Ok, I've reverted to the original code, and the error is just the same. Same message with a pink bar underneath. I'm sure there's supposed to be a message in there somewhere... Cheers, Laurie.

Just double-checked, and these have not been changed: checkout_payment.php checkout_process.php checkout_success.php This has been changed: checkout_confirmation.php It looks as if it's the change to force shoppers to accept the Ts & Cs prior to purchase, so I'll revert to the original code and re-test. Cheers, Laurie.

No problem, we all have our "challenges", but I must admit I was getting worried! Yes, you have. That is exactly what's happening. Thanks for the clues as to where this might be happening. I've checked the site, and I can confirm that the following files are unchanged: protx_process.php includes/languages/english/checkout_process.php These have been changed: checkout_confirmation.php checkout_payment.php checkout_process.php checkout_success.php They were changed for some plug-in or other, and I'll find out which and see if I can spot the problem. Cheers, Laurie.

Post 210 onwards in this very topic (page 11) will answer your question. You need curl installed to use this plug-in, and you don't appear to have it. Cheers, Laurie.

I've just done a test transaction and a live transaction, both failed as described above, but this time, here's the debug info: Test transaction with "test" card: Request URL=https://ukvpstest.protx.com/vspgateway/service/vspdirect-register.vsp Data string sent=VPSProtocol=2.22&TxType=PAYMENT&Vendor=******&VendorTxCode=25**-74669753405113456032259062******&Amount=3.00&Currency=GBP&Description=Order+Number%3A+2532&CardHolder=*****+***&CardNumber=5404000000000001&StartDate=0103&ExpiryDate=0108&IssueNumber=&CV2=123&CardType=MC&BillingAddress=********%2C+************+**%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&BillingPostCode=IP**+***&DeliveryAddress=********%2C+Grundisburgh+Rd%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&DeliveryPostCode=IP**+***&CustomerName=*********&ContactNumber=07736******&CustomerEMail=*********%40*******************&ClientIPAddress=10.0.1.152&Basket=2%3AColoured+Bookmarks%3A1%3A1.00%3A0.00%3A1.00%3A1.00%3AShipping%3A1%3A2%3A----%3A2%3A2&AccountType=E&Apply3DSecure=0 Protx response=VPSProtocol=2.22 Status=OK StatusDetail=0000 : The Authorisation was Successful. VPSTxId={954A6DC6-CCE4-2694-1ED1-EE82BF7*****} SecurityKey=W8AKPS**** TxAuthNo=3583*** AVSCV2=SECURITY CODE MATCH ONLY AddressResult=NOTMATCHED PostCodeResult=NOTMATCHED CV2Result=MATCHED 3DSecureStatus=NOTCHECKED Response array=Array ( [VPSProtocol] => 2.22 [status] => OK [statusDetail] => 0000 : The Authorisation was Successful. [VPSTxId] => {954A6DC6-CCE4-2694-1ED1-EE82BF7*****} [securityKey] => W8AKPS**** [TxAuthNo] => 3583*** [AVSCV2] => SECURITY CODE MATCH ONLY [AddressResult] => NOTMATCHED [PostCodeResult] => NOTMATCHED [CV2Result] => MATCHED [3DSecureStatus] => NOTCHECKED ) curl_error= Live card, live transaction: Request URL=https://ukvps.protx.com/vspgateway/service/vspdirect-register.vsp Data string sent=VPSProtocol=2.22&TxType=PAYMENT&Vendor=******&VendorTxCode=25**-52881278035046185963675275******&Amount=5.70&Currency=GBP&Description=Order+Number%3A+2532&CardHolder=*****+***&CardNumber=****************&StartDate=&ExpiryDate=0909&IssueNumber=7&CV2=802&CardType=MAESTRO&BillingAddress=********%2C+************+Rd%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&BillingPostCode=IP**+***&DeliveryAddress=********%2C+************+**%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&DeliveryPostCode=IP**+***&CustomerName=*****+***&ContactNumber=07736******&CustomerEMail=*********%40*******************&ClientIPAddress=10.0.1.182&Basket=2%3ABells%3A1%3A2.99%3A0.00%3A2.99%3A2.99%3AShipping%3A1%3A2.71%3A----%3A2.71%3A2.71&AccountType=E&Apply3DSecure=0 Protx response=VPSProtocol=2.22 Status=OK StatusDetail=0000 : The Authorisation was Successful. VPSTxId={5BA2D632-6DC6-AF80-D47C-1D38C47*****} SecurityKey=QY7EGN**** TxAuthNo=5868**** AVSCV2=SECURITY CODE MATCH ONLY AddressResult=NOTMATCHED PostCodeResult=NOTMATCHED CV2Result=MATCHED 3DSecureStatus=NOAUTH Response array=Array ( [VPSProtocol] => 2.22 [status] => OK [statusDetail] => 0000 : The Authorisation was Successful. [VPSTxId] => {5BA2D632-6DC6-AF80-D47C-1D38C47*****} [securityKey] => QY7EGN**** [TxAuthNo] => 5868**** [AVSCV2] => SECURITY CODE MATCH ONLY [AddressResult] => NOTMATCHED [PostCodeResult] => NOTMATCHED [CV2Result] => MATCHED [3DSecureStatus] => NOAUTH ) curl_error= Once upon a time I was a professional programmer, not in php unfortunately, and although I can mostly make sense of it, debugging it is difficult as it seems hard to get values and stuff at different stages of the processes. Cheers, Laurie.

We've just put a card through the protx management screens successfully, and then tried the same card through the site. We get the usual error as described above. This is not good, and I'm at my wit's end to see where this might be going wrong. Cheers, Laurie.

In view of Thieving_Gypsy's comment above, I feel I should mention that the errors I have described were on a Mastercard, with and without 3DSecure. Cheers, Laurie.

Hi Tom, I have a strange problem here with V4.4. I have a shop that's working inasmuch as the dosh is being taken from the customer's card, the db table for protx_direct is being updated, but the order doesn't process at all. I've really tried to solve this, but would appreciate some help, please (it's a live site). What's happening is that I'm getting 'Credit Card Error!' on paying with a card, so have modified that string in includes/languages/english.php to change the Protx error message from 'Credit Card Error!' to 'Credit Card Error in Protx!', which message now appears after posting to Protx. I did that because there are several files with that string in, and I wanted to narrow down whence it comes. Protx takes the money from the card, but nothing seems to come back to the shop, no order, no emails, nothing. A valid record is written in the protx_direct table, however. In test mode, using a test card, it returns to the credit card page with this URL: https://shop.playwoodtoys.com/checkout_paym...c_expires_year= Another trip through the payment process, with a real card, AND via 3DSecure (which worked, the money was taken, db updated properly) led to this URL: https://shop.playwoodtoys.com/checkout_paym...c_expires_year= which is exactly the same as the one above! I'm sure that there's a clue in the fact that it keeps thinking the expiry date is incorrect (it isn't). At all stages the user interaction seems ok, and all forms, fields and confirmations are also correct. I've ripped out and reinstalled protex direct, checked and re-checked, and I can't find the cause. HELP!!! Cheers, Laurie.

I did as you advise, and the site is now working fine. There is one caveat though. The 2.1c version isn't properly compatible with MySQL5. There's a later replacement for seo.class.php which changes the database tables slightly (see: Fixed seo.class.php jpweber 25 Nov 2006) . Ideally, the new version should be installed before first running the app, so the database is properly configured. However, if, as I did, one runs the app as per the instructions, SE-friendly URLs don't work for categories, and clearing the SEO cache dies with the following error: "1146 - Table '<your-database>.cache' doesn't exist DELETE FROM cache WHERE cache_name LIKE '%seo_urls%'" It is also not possible to create new categories. The solution is to take the SQL code from seo.class.php which creates the cache table and execute it your favourite way. Everything works fine thereafter. Many thanks to all who helped here, and especially Tom for a great plug-in. Cheers, Laurie.

Ok, I've removed the SEO stuff I was using, flushed all caches, turned off the "search engine friendly URLs" thingy in admin, and the site now works, albeit without SEO enabled. I'll now tar the site up and add in Chemo's stuff. Will report back. On another peripheral note, is anyone else in the East Anglian contingent a member of ALUG (Anglian Linux User Group)? PM me if you are or want to be, please. Cheers, Laurie.

I'll uninstall the one we currently use (didn't know there was a better one), and try Chemo's one out. I must say, the old one has been working for a very long time with no problems... Cheers, Laurie.

Oh dear. I spoke, much, much too soon... That hasn't worked... ARRGGGHH!!! Cheers, Laurie.

Top man! That worked a treat! Thanks! Next time I'm in Stow, I'll buy you a beer, or if you come to Ipswich, I'll buy you one! Cheers, Laurie.

I was happy too soon... Indeed this fixed the problem with traffic going out to Protx, but it's broken something else. If one clicks on a category, it goes straight back to the home page. Hovering over the category shows the home page URL in the lower left hand corner of the browser (firefox). SEO URLs V1.1 has been installed (http://www.oscommerce.com/community/contributions,2796). I see that there are some updates to apply to the SEO plug-in, and will apply them, but reading the comments and the associated forum topic, I don't think it will make any difference to this particular problem. This is turning into a nightmare! Any suggestions, Tom? Cheers, Laurie.

Hi Tom, You're absolutely right! That's sorted it. Many, many thanks. Cheers, Laurie.

I've overwritten all the distributed files, checked all the manual edits are done (they are), and re-done the install in admin. Traffic for http/https/icmp is leaving the server for Protx by all reasonable means except by this module. Everything appears normal right up until confirmation of payment, then it just hangs. I'm running tcpdump on the server, and also on the firewall. Note that the IP address I'm looking [grepping] for is 213.52.247.135 as that's where https://ukvps.protx.com goes to. I am stumped. Note that iptables is NOT running on the server in question. My php isn't that strong, so I can't see how else I can debug this. This may help: catalog # grep -r ukvps * admin/orders_protx.php: $url = 'https://ukvpstest.protx.com/vspgateway/service/'.$service.'.vsp'; admin/orders_protx.php: $url = 'https://ukvpstest.protx.com/showpost/showpost.asp'; admin/orders_protx.php: $url = 'https://ukvpstest.protx.com/VSPSimulator/VSPServerGateway.asp?Service='.$sim_service; admin/orders_protx.php: $url = 'https://ukvps.protx.com/vspgateway/service/'.$service.'.vsp'; includes/languages/english/modules/payment/protx_direct.php: define('MODULE_PAYMENT_PROTX_DIRECT_TEXT_DESCRIPTION', '<strong>Test Credit Card Numbers:</strong><br /><br />Visa#: 4929000000006<br />MC#: 5404000000000001<br />Delta#: 4462000000000003<br />Solo#: 6334900000000005 - Issue #: 1<br />Maestro#: 5641820000000005 - Issue #:01<br />AMEX#: 374200000000004 <br /><br />Any future date can be used for the expiration date and any 3 or 4 (AMEX) digit number can be used for the CVV Code.<br /><br /><a target="_blank" href="https://ukvps.protx.com/vspadmin">VSP Admin</a>'); protx_process.php: $url = 'https://ukvpstest.protx.com/vspgateway/service/direct3dcallback.vsp'; protx_process.php: $url = 'https://ukvpstest.protx.com/showpost/showpost.asp'; protx_process.php: $url = 'https://ukvpstest.protx.com/VSPSimulator/VSPDirectCallback.asp'; protx_process.php: $url = 'https://ukvps.protx.com/vspgateway/service/direct3dcallback.vsp'; protx_process.php: $url = 'https://ukvpstest.protx.com/vspgateway/service/vspdirect-register.vsp'; protx_process.php: $url = 'https://ukvpstest.protx.com/showpost/showpost.asp'; protx_process.php: $url = 'https://ukvpstest.protx.com/VSPSimulator/VSPDirectGateway.asp'; protx_process.php: $url = 'https://ukvps.protx.com/vspgateway/service/vspdirect-register.vsp'; Cheers, Laurie.

Same result, Tom. I think I'll roll back and re-install. It was an upgrade from 3.2, and something is definitely not right! Cheers, Laurie.

The customer was having trouble with Maestro (and Barclays as his bank) but I've just tested this with a test mastercard number (5404000000000001) and the module set up for both "Test" and "Production", with the same result he is experiencing: one is sent to this blank page: https://www.paperartzzi.co.uk/protx_process...0issuing%20bank Nothing happens thereafter. Just tried with a "real" MC with the same result. Done some more traffic sniffing, and it now appears that no traffic is leaving the server for Protx via the OSCommerce site. Connecting via lynx and links works just fine. I'm really confused... Cheers, Laurie.

Hi folks, I have a major problem here with 4.4, and I'm getting no help at all from Protx. The scenario is that I host and maintain an OSCommerce site for a customer, and when Protx made all these changes, I implemented 4.4 on his site. I have checked, and re-checked, and as far as I can see, it is all correct. I've run tcpdump at our firewall, and traffic is leaving our site to the new Protx URLs, and an ACK is being received. And, er, that's it! Even with debug on, nothing seems to happen. Protx claim nothing is arriving at their end. I've received no documentation from anyone at Protx, and my client says he hasn't either. Is there something I'm missing here? Do we have to set-up the various accounts/IP addresses at the new Protx URLS? Any clues on debugging this, please? Any gotchas I may have missed somewhere? All help gratefully received. Cheers, Laurie.