Latest News: (loading..)

porpoise1954

Members
  • Content count

    176
  • Joined

  • Last visited

1 Follower

About porpoise1954

  • Birthday 09/10/1954

Profile Information

  • Real Name
    Steve
  • Gender
    Male
  • Location
    Jersey
  1. Well, I've gone through every file and updated all the deprecated $HTTP_******_VARS variables to the newer $_POST, $_GET, $_SERVER, $_SESSION etc. variables and everything is pretty much working (not perfectly, as there are still a few tweaks and a bit of prettifying [getting rid of all the schoolboyish icons! :x for example] to do) and Anglicizing all the English to "PROPER" English! ;). :) Found a great little stand-alone executable to do the "find-and-replace-text" part - TurboSR Search & Replace It required quite a lot of tweaking to get it to work on a highly modified osC 2.2-MS2 site running on PHP 4.4.9 and Apache on Linux 2.6.28.8 and MySQL 5.0.91 Had to make a "New News Item" button, as there wasn't one in the distrib! So, back to the MUST_DO list (the stuff that NEEDS to be done before I can actually put it live!): 1. Currently working on generating differing affiliate rates based on MANUFACTURER as the margins vary widely between manufacturers and the commissions need to reflect this but also need to take into account different affiliate rates and compound the two. Have modified the Manufacturers table to add a commission percentage rate for each manufacturer via the admin page and am currently still testing the code within "affiliate_checkout_process.php" to do all the necessary calculations checking the manufacturer of each product and applying the correct rate to the item before adding it to the affiliate total. Still testing! 2. Still need to incorporate adjustments where Discount Codes/GIFT Vouchers come into play. So, back to the grind-stone - check back later...
  2. I haven't completely got it working yet either. There are a number of issues I have come across: The "$HTTP_POST_VARS", "$HTTP_GET_VARS" etc. all need changing to "$_POST", $GET" etc. to bring them up-to-date. Have come across some files which have "<?" instead of "<?php" which needs to be changed to avoid ambiguity as "<?" won't correctly parse as PHP on some server configurations. I also haven't managed to get the images to display on banner links, although the text versions work just fine and both types of link at least take you to the correct page on the site, so it looks like the code to select and display the image needs re-working somehow. Unfortunately, it looks like the original developers of this mod are no longer working on it, :( so we're going to have to work this stuff out ourselves. Still, it should be a lot less work than trying to write the whole thing from scratch huh?!?:) In the meantime, it is now 5:00am and I need to get some shut-eye...
  3. Ermmmm..... you have to add it in yourself, according to what responses you are receiving back from your provider. You could do it using conditionals like: if ($_POST['authcode'] == TRUE && $_POST['authcode'] == 123456) { relevant code to do whatever it is you want to do based on the result of the foregoing test goes here; } I use three items for the test: ?authorised ?identifier (generated code sent to provider returned matched) ?digest (MD5 hash) if those 3 tests pass, then, and only then, is the content of checkout.process.php run and an order generated with the data from the transaction. That way, we don't end up with a load of dead unprocessed orders in the database (where payment has failed) and skipped (genuine) order numbers - only those which have had payment processed get generated into a valid order.
  4. You need to do a "dump" of the $_POSTs &/or $_GETs that are returned from the gateway and decide which ones you want to include in your osC code for checking purposes and the actions you want carried out in response to those responses. For example (in our cart), when a customer creates a basket(cart), the related data are placed in a temporary table into which I include a couple of extra fields like a count of long_items (over 610mm - for Royal Mail), a unique identifier for the basket (which is included in the data passed to the payment gateway and comes back with the response (and is used in checkout_process.php as an additional security check), country code & weight (for calculating shipping) and total order value. So, when the post-back data is received from the payment gateway on completion of the transaction, the authorisation code and the identifier code are checked before the order# is issued and the basket(cart) processed - which processing then includes the transaction# from the gateway, the auth code, the unique identifier (from the original cart) and the rest of the order details. It's basically up to you what data you which to test/include/exclude as part of the transaction process. The data that gets returned from our gateway provider is: authcode authorised? amount errorcode errorid errormessage identifier (provided to the gateway from the cart and returned from the gateway) transaction# cscresult avsresult digest (MD5 hash) We don't necessarily retain all the data that gets returned.
  5. You would need to contact the 3rd party gateway company for a list of their response codes.
  6. You could add the "define" code to the top of ech of the relevant files that you want it different to whatever is set in config. e.g. define ('IMAGE_WIDTH', 'xxx'); define ('IMAGE_HEIGHT', 'xxx'); Or you could add it to your stylesheet.css as a style for each different sized image you require. eg. img.small { width: 400px; height: 400px; } img.smaller { width: 300px; height: 300px; } etc.... Then, in the code on the relevant page displaying the image: change the code to (removing the existing HEIGHT/WIDTH attributes): <img src="yourimageurl" class="small" ................... /> <img src="yourimageurl" class="smaller" .................. /> etc... You can call them whatever you want. The big advantage of doing it in the stylesheet, obviously, is that if you want to change the sizes, it can all be done in the one place - the stylesheet.
  7. Bad, bad, bad - REALLY bad idea! There are any number of sites out there that advise against going any where near that idea, and the reasons why. (Not least because you could lose your merchant account if you do not jump through all the necessary hoops required to comply with the necessary data protection requirements). http://www.ecommerce-guide.com/article.php/10183_484911 http://www.webmasterworld.com/forum22/5286.htm http://www.computerweekly.com/Articles/200...a-clampdown.htm http://www.ssiweb.co.uk/news/internet-news-4/68.htm That's a bit of reading to get you going but you can find tons more by gargling it.
  8. Rather than Zone Rates, I use Table Rates (each postal rate/zone is a seperate table). To post from Jersey to all the countries we ship to requires 14 different Rate Tables as the calculations are based on weight/destination/long item? (over 610mm - which means it MUST go parcel post) The actual table rates have been done using a Table Rate Contribution (which one I can't presently recall) then I have added files for calculating weight/destination/method/long_item? so that the customer is only presented with the options that are applicable (otherwise, they would be presented with all 14 options - and you can guarantee they would be selecting wrong ones!). The correct price is then selected from the relevant table. So, it's basically done in 2 stages, the first determines which postal methods (letter, parcel, etc.) are applicable to the destination, the second stage selects the appropriate postal rate from the relevant table(s). Although Jersey have their own Postal Service and different (more expensive!) rates, Royal Mail take over the onward distribution from Gatwick. I therefore think that the different destination groups from here will be the same as from UK but with different rates. That being the case, you should be able to easily modify this system to suit your needs. It really depends on what you are shipping and what the likely weights/lengths are. The postal rates jump significantly once you start to ship to other countries - with different weight limits etc., too. The rates are not the same for every EU country either.
  9. You can get the up-to-date countries list from the ISO site: http://www.iso.org/iso/country_codes/iso_3...de_elements.htm I've mentioned to Harald several times by email that the current country list in osC is out of date but no-one seems to be bothered to update it. Luckily, it's easy to update the countries table yourself by just adding the missing countries from the current ISO list.
  10. Hmmm.... Except that isn't in the osC package - it's a third party contribution.......
  11. Actually, if you use the current ISO countries list (as opposed to the one that comes with osC), you'll find that the Channel Islands aren't a country. Jersey, Guernsey and Isle of Man, however, are: JE, GG, IM respectively. (Alderney and the smaller islands come under Guernsey).
  12. Or CSS Z-index
  13. Unfortunately, I do not know anything about the PayPal IPN but it does seem that the original contributor has abandoned both this thread and the Easy Coupons thread - which is a shame because they are both great contribs. - which I finally got working delightfully, to my satisfaction after a lot of head scratching and sleepless nights!
  14. Easy Discount is extrememly flexible but you need to have at least a rudimentary coding ability, as there is no friendly UI for it in the admin section, you have to get down and dirty. The amount of complexity of code required is dependent on the complexity of the criteria upon which you wish to base the discount. For example, I have added code to take into account the product attributes mod I have installed, so that I can do individual discounts on specific product attributes (eg. discount size 14, colour blue only). Used in conjunction with Easy Coupon, the possibilities are endless. Just don't expect too much support on the Easy Coupon support thread, as it seems to have died (and I don't have the time at the moment to help much there - although I have really got down and dirty into these two contribs.) I have modded the Easy Coupon contrib so that we can do Gift Vouchers as a product as well as being able to issue coupon codes ad hoc. It's not perfect (you have to use the Qty field for the value required) but it works like a dream - have also included the option of receiving .pdf Gift Voucher with the code, expiry date and customer's name on it too (They can ask for the recipient's name to be printed on the digital Gift Voucher if required - although, at the moment, this is done manually). All info is also printed on the invoice and in the email confirmations. You can see it in action here: http://www.apnea.co.uk/product_info.php?cP...products_id=946 The contribs are here: Easy Discount Easy Coupon
  15. Is it just my imagination, or has this thread just ground to a halt?