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.