Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by totalnumpty

  1. totalnumpty

    Free templates?

    But, quite honestly .... a commercial themes developer would naturally say that .... hmmm? "Vested interest" springs to mind.
  2. Hi all I've searched but didn't find an existing contrib for this, I'm hoping someone knows of one, or that someone who is a far better coder than me can pick the idea up and run with it. Here's the situation - on one of my osCommerce stores I have a very wide range of payment options, from multiple options for bank deposit/transfer/TT etc through various online processors (AlertPay, MoneyBookers, NoChex, PayPal, ppPay, Google etc) to postal payments and wire transfers. Generally there is no issue and they all work as well as can be expected, but now and them I get a PITA customer - you know the type, they select an offline payment method and when you follow up a few days later, asking where the payment is, they decide they want to use an online payment service instead - so you send them an (e.g.) PayPal money Request, they don't pay it, you remind them, they ignore it, and eventually you just delete the order and move on. Then a few months later, they come back and repeat the entire self-same process. Maybe doing it several times over a year. You don't want to delete or block their account, because just maybe one day they'll actually complete the order, or they may have purchased and completed the transaction somewhere else with you (like eBay or Amazon) and on your osCommerce site, they class as a returning customer. So here's what I want to do - On this site, I've got the Admin Notes contrib installed, so I can at least record that they've done the runaround described above, but I'd like to take it a bit further. Rather than block them completely, and obviously blocking the payment method for their tax zone is not a solution, I'd like to be able to prevent display of non-immediate payment methods for selective customers - ideally by way of some sort of "allowed / not allowed" checkbox list in the customers profile in admin. This would allow the maximum flexibility of making the restrictions apply only to specifically selected customers. I've no idea how to begin coding this, and very little about where such mods should be placed within osC, so I'm hoping someone can work with me and do the grunt coding, then use my site (and me) as a test bed and test installer. Anyone interested? Gaz
  3. totalnumpty

    Official PayPal IPN Support Thread

    Have you by any chance got more than one PayPal module active and installed? Just a wild thought that popped into my head. Also, don't know if this is possible or not, but have you got hard-coded embedded calls to an inactive PayPal module as well as to your active IPN? On-screen duplication I would expect to be due to duplicate code, but not normally to cause duplicate entries in the database - the "unique key" per table should prevent that. If you could check your database tables using phpMyAdmin and grab the row numbers and unique key column entries, it might help reveal if the problem is with the database, the write-to-database code, or with duplicate transaction (PayPal) code inside your site. If you see what I mean? If the problem is there and you can't fix it yourself, you'll probably need to put out a call for paid support from a competent PHP/SQL developer. Busy deep in the throes of site building - don't count on me being around here much before the end of next week. Gaz
  4. totalnumpty

    Official PayPal IPN Support Thread

    Julian Hi The more I think about this, the more it feels it has to be due to the one page checkout - I've not implemented that on any of my sites yet, but can you check through the install instructions carefully looking for any code that tells you to delete / comment out hooks to the original checkout flow. Make sure you followed those accurately. Are you getting the same duplication from other payment processor modules? Or is it solely the PayPal one? Have a look at the module's contribution page in the repository, I seem to remember that the version you're using had some issue with being for German language sites only (or something like that). Unfortunately I don't have time to root around in this too deeply right now as I've got five complete site build, config, and style jobs to finish before month end and the job only arrived yesterday so nothing's been started on it yet. Good luck Gaz
  5. totalnumpty

    Official PayPal IPN Support Thread

    Hi Julian I can't give you a definitive answer, but I can give you a few areas to look at for the cause of this. First though - did you spot that your VAT is not included in the total price? Here's my guess on that - PayPal has two IPN files in the IPN install. One is in the catalog/ext/..../paypal/ folder - that one is the IPN responder which receives the3 data from PayPal about a transaction and updates the order status in admin. For the order total problem, you can ignore that one, and for the duplication issue, it's very unlikely to be causing it, but you never know, as you say the order number is also duplicated. The other paypal_ipn file is in catalog/includes/modules/payments/paypal/ this is the one most likely to be the source of the order total problem and there's been loads of discussion posting detailed problems and the fixes, regarding that file. Normally, using the aggregate tax method clears it - don't worry too much about VAT accounting issues on the payment processor - you account for VAT from the invoice and in your accounting system, not at PayPal. This problem has been a long-running "open sore" with the open source PayPal modules. That second paypal_ipn is possibly, though unlikely, the cause of the order detail duplication - generally though, I'd say that if it was the source, then your invoices would be double the total price too, and you'd be spotting that pretty fast. My guess would be that the one-page checkout is echoing with the original checkout flow somewhere - probably in the order confirmation area. In the normal checkout flow, the last page of the process is where the order is written to the database and assigned the order/invoice number, then the whole is passed to the customer chosen payment module. Logic says that it's most likely at this point that the database is being written to twice, You've said the order is duplicated - but did you check if the order.invoice number is identical? (On the admin home page, hover your mouse over each order and look at the status bar at the bottom of the screen - it'll show the order/invoice number in the URL for the order). If the order number is identical for both, then you have a two step problem - osC is "printing" the order twice to screen as well as to the emails - that should be the easier to kill problem. Look for code duplication, or if the default checkout process is still active and working in parallel to the one-page checkout, instead of being replaced by one-page. If it's identical and in the database as two separate orders with the same number (which should be impossible given the auto-numbering osC uses with SQL) then you've got bigger issues - do you know how to use phpMyAdmin to inspect the database content and structure directly? You'll likely need to do that anyway - to verify if the problem is in the order recording, or in the osC use of the data after it's recorded. Sorry I can't drill straight to the problem, but hope the above helps you find it. Gaz
  6. totalnumpty

    Oscommerce Auction Lister Pro

    All eBay sites now require that all sellers seen as business sellers offer a return policy. Private sellers must make a return policy statement, even if that statement is "no returns". Since last Autumn (22 Sept 2009) eBay banned the shipping insurance options on all sites - it broke the osCommerce3 PayPal IPN modules using the Shipping Insurance contribs too. I have been searching for proof, and found it today on the PayPal Developer site, plus have finally (also today) been able to construct a fix to re-embed the shipping insurance charges back into the IPN data passed to PayPal, and get payment for them - it has taken me nearly six months to do this.
  7. totalnumpty

    Official PayPal IPN Support Thread

    Strange - I thought the confirm order button was on catalogue/checkout_confirmation.php - not at PayPal I say that because it sounds like the checkout_confirmation order button is being activated twice or the checkout_confirmation.php page is being loaded twice (osC commits the order to the database when that page is loaded - including at a page refresh or if the back button is used to escape paypal). That's the most common cause of multiple records and order numbers for the same order. Example - if your site "home currency" is not the same as the transaction currency, nor the "home currency" for your PayPal account, then rounding errors occur during the currency conversions, and even if only a few pennies, some customers will use the back button to check that the PayPal total is truly not the same as the one shown by checkout_confirmation - that will cause two orders to be logged on their account, in the database, and on the admin/Customers/orders page. Other than that, I'd recommend you increase the level of server error logging to try and capture more information to point you to the culprit. Sorry I can't be more helpful. Gaz
  8. totalnumpty

    Seperate Pricing Per Customer v3.5

    If you're having to insert a multi-query in multiple places, why not just create a function for it, and then call that function where it's needed? You could then set all the parameters under the one function rule, and call the required parameters where they are needed.
  9. totalnumpty

    Official PayPal IPN Support Thread

    OK, fair call - my bad, I was using generally understood shorthand pathing ... try this - /includes/modules/payment/paypal_ipn.php Just for the record in RC2a ... catalog/ext/modules/payment/paypal/standard_ipn.php hooks up with catalog/includes/modules/payment/paypal_standard.php and catalog/includes/languages/english/modules/payment/paypal_standard.php Therefore as I originally answered - No your premise of the single file in /ext/.... is still incorrect, and my original answer SHOULD have given you enough information to track down the other two files of the trio. The overall process I described remains the same for the standard_ipn in RC2a, it's just handled slightly differently by the code. Lastly, there perfectly well could be an /includes/modules/paypal_ipn.php in RC2a on a NON STANDARD install, which is actually the norm for osC sites - i.e. NON-standard (nobody uses it straight from the box and runs with it that way as a production site - that's just begging for hackers to visit your install). You could do - if you only have one website, will only ever have one website, and that one website will only ever be the sole source of payments into your PayPal account (i.e. no instant payment buttons, no auction sites, no WordPress eShops etc etc etc) - otherwise, read the help files and the instructions - within osC, and at PayPal - enter your /ext/... path in there and EVERY IPN or PayPal Express callback confirmation from your PayPal account will be sent to your website, many will be irresolvable (because they did not originate from the IPN on your site) and could cause server resource abuse due to SQL query loops and timeouts, and your hosting account could get suspended (I've heard several stories of it happening). If you ask for advice, listen to experience, and read between the lines if it's not an exact fit with your situation. Adapt what you're told to what you're experiencing ... and I do hope that's not "teaching granny to suck eggs"? Alternatively - follow the osC forum credo - and post your full site and server spec with version numbers, plus screen shots of errors etc, then people who help you are not firing blindly and generically when they offer that help.
  10. totalnumpty

    Official PayPal IPN Support Thread

    Ken - your confusion is understandable, but your assumption is wrong. How it works is like this - - Once the customer has entered checkout and chosen shipping, and shipping options (gift wrap, insurance etc), the next step is the payment method - checkout_payments.php checks the customer address against the tax zones (geographic areas) for each payment method you have installed - if the customer is in the allowed geo-zone for PayPal, it offers payPal as a payment method - if the customer chooses PayPal, and goes to order confirmation, then checkout_confirmation.php assembles all the customer and order details and basically asks the customer if it is all correct, or if they want to edit anything. If they confirm it, then all that data is passed to /includes/modules/paypal_ipn.php - /includes/modules/paypal_ipn.php then passes that data to PayPal and redirects the customer to the PayPal website to sign in and choose funding source etc. This part of the IPN also passes to PayPal the data return path for confirming payment has been transferred to the merchant's PayPal account. - once the customer has done what's needed, and PayPal have moved the money to the Merchant's PayPal account, then the PayPal IPN server squirts a data stream back to your site - but the returned data goes to /ext/.../paypal_ipn.php NOT to /includes/modules/paypal_ipn.php - /ext/.../paypal_ipn.php then records the payment details into the database and updates the order status and transaction record, I think it also confirms back to PayPal that the payment data was received from them, and failing to do so is one common cause of payment failures. So the IPN has two parts - - the first paypal_ipn.php which is the payment methods module, and sends the customer and order details to PayPal, this is in /includes/modules/ - the second paypal_ipn.php which is the response receiver and order updater, this one is in the /ext.../ folder There is a third file in /includes/languages/{language-name}/modules/payments/paypal_ipn.php which controls the displayed language strings for the checkout pages and the admin payment modules page. So .... nope, the /ext/.../paypal_ipn.php is not all that osC needs - it needs all three files for any individual payment processor's IPN in order for that payment processor's IPN to function - regardless of which payment processor you're using (e.g. MoneyBookers, NoChex, AlertPay, ppPay etc.n Google Checkout is a little different, as is Amazon Payments, but the idea is similar). Each set of files will be named after the payment processor they handle - e.g. MoneyBookers.php and so on. Hope that helps? Gaz If any of the above is wrong, can someone post the correct process or logic - I think there's a few people get stuck with how the IPN's work.
  11. At the bottom of catalog/application top is a list of error messages that display in a pink bar at the top of the public catalog These error messages display the full hosting account details and folder/file path for the file causing the error I've also noticed PHP errors (syntax etc) do the same when adding contribs and mucking up the code inserts. This is a serious security breach because it is displaying the hosting account user name to the browsing world. Whilst co-incidence probabilities are against a hacker manual browsing your site just as a code error message displays itself, the pink messages from application_top can be present for several hours - in my case whilst waiting for DNS to propagate following a server migration, and the world might be seeing those messages before the site owner even knows they're being displayed. Somehow, the file paths displayed need truncated to show only the file path below /catalog/ - the server and hosting account name should NEVER be displayed to the public. (This might also help reduce instances of store owners copying and pasting their hosting details into osC forum posts and not editing them out). Gaz
  12. totalnumpty

    ot_loyalty_discount and paypal

    Ditto How did you fix it? I have a feeling your fix may also apply to other modules having similar issues - e.g. the gift wrap module and the shipping insurance module. Therefore, please, even if your fix was to remove the discount module, please illuminate the rest of us.
  13. totalnumpty

    AlexStudio - are you around?

    Alex Hi It worked fine for two years but when eBay banned shipping insurance this September, all PayPal transactions from my osCommerce website using PayPal IPN also stopped collecting the insurance - even though the insurance is shown in order total and on the invoice after the payment has been made - at PayPal the payment is without the insurance. This is starting to lose me real money as the customer expects me to ship with insurance and not try to recollect it with a PayPal money request. Any help or pointers would be gratefully received Gaz (osC 2.2 RC1 + PayPal IPN 2.x (Oct 2007))
  14. totalnumpty

    Need help to install Paypal IPN

    In your payment modules in admin, is it showing something names "PayPal incl Credit & Debit Cards" or similar, or something like PayPal IPN? Remember you have to activate the module, not just upload it.
  15. totalnumpty

    PayPal Standard not updating in Admin

    That's the right module but roll back a bit on the versions to the last English version (I think it's 2.7.something) - use the expand all link at the top of the contrib comments and look for the last entry in English, then scroll down for the last entry stating it's "full package"
  16. Hi everyone I'm starting to pull my hair out on this - it started in late September just after all the eBay sites went to no shipping insurance. When a customer completes their order after choosing the shipping insurance (contrib = http://addons.oscommerce.com/info/1069) PayPal are either ignoring or stripping the insurance parameters passed through the API. The result is a payment received that is net of the insurance charge, but the customer's invoice shows both that insurance was chosen, and the correct rate for it. I've tried the patch in the contrib's read me, but that hasn't helped. I also tried the patch in another forum thread based off a different service's patch, and that didn't fix it either. I ran this contrib with the API module from nmid-2007 until September this year and it worked perfectly, like I say - it stopped working on my osC site right after eBay banned shipping insurance on theirs (eBay owns PayPal - for those that didn't know already ;) ). No code or contrib changes had been made on the site since around Easter. I'm convinced the issue has come from within PayPal, but so far, can't find anyone else reporting (or noticing) it happening on their sites. Has anyone else seen this happening? If so, has anyone cured it? Gaz
  17. totalnumpty

    PayPal IPN Invalid Process - emails

    C'mon everyone - I can't believe I'm the only person having this - the shipping insurance was working fine right up until eBay removed insurance from their sites in late Sept 2009, after that, every transaction where the customer in my osC store selects insurance - the transaction is stuffed and no insurance collected by PayPal. Mind you, at least they've stopped sending invalid process emails on it, and it's sort of working correctly in the osC backend again (just no insurance collected in the PayPal payment). Gaz
  18. totalnumpty

    problem with shipping insurance with linkpoint

  19. totalnumpty

    Invalid IPN Process error

    Those emails are triggered when someone tries to access the PayPal IPN file directly in the ext.... folder - looks like a test of some sort coming from someone who knows you have PayPal on your site (or could be a novice hacker trying to get at your IP login details). You can trigger one of them emails yourself by following the test instructions in the module's readme file. Gaz
  20. totalnumpty

    Heartland and oscommerce payment module

    Heartland ... weren't they the crowd who had 5.5 million credit card records hacked out of their data centre at the start of the year in the US, and billions of dollars lost in fraudulent transactions against all the banks' credit cards that they manage? Or have I mixed the name up with a different crowd?
  21. totalnumpty

    Paypal issues the month. Anyone else?

    The PayPal developers blog for API and website payments is stuffed full of last minute announcements of system outages and maintenance times for most of October - the service is seriously knackered and from my personal experience it looks like they've removed any API calls for shipping or postal insurance. Transactions ARE completing at PayPal, but I'm getting PayPal IPN Invalid email notices and examining them reveals all insurance fields are stripped away as if they'd never existed - - - - I blame the new eBay policy that banned any and all mention of shipping insurance on their sites from around 22/23 September - looks like San Jose ordered PayPal to strip it from their systems too. If your site(s) are set up with shipping insurance modules - check the payment received very carefully against the invoice total in osC, because osC is still showing the insurance as customer-requested and paid, but the money for it is not included in the amount PayPal takes off the customer. This all started happening in mid-September, my latest incident of it was yesterday. Gaz
  22. totalnumpty

    PayPal IPN Invalid Process - emails

    I've checked the dates and times of several emails I've had which begin with - eMail Title = PayPal IPN Invalid Process $_POST: mc_gross=68.48 invoice=80 protection_eligibility=Eligible address_status=confirmed item_number1=(obfuscated) payer_id=(encoded) tax=0.00 address_street=(obfuscated) payment_date=03:54:25 Oct 28, 2009 PDT payment_status=Completed The bits above in brackets are changed by me to post here Basically the email is the entire transaction data, claiming an invalid process. On PayPal the payment proceeded normally. In the osC Admin transaction record it shows as payment failed. When I dig a little deeper - the optional Shipping Insurance module's value is not being passed to PayPal (or not accepted by them) and the monetary value of the insurance is missing from the amount received into PayPal, but still showing in the osC transaction record as chosen and paid by the customer. It also displays and prints on the invoice as such. The cynic in me says that since eBay banned option or compulsory insurance outside of the consolidated shipping charge (or total product price with "free" shipping) PayPal have now removed the option for non-eBay sites to process insurance through them. This issue is ONLY arising on transactions where the customer has elected for shipping insurance - if the customer decides not to request shipping insurance, the transaction processes normally. This is completely screwing our wholesale export business where everything is either C.I.F. (Carriage, Insurance and Forwarding) or F.O.B. (Frieght on Board) shipping terms. It's also royally beggaring our "bulk retail" business to small resellers where again all shipments are CIF or FOB at customer's choice. We're at the point of removing PayPal from those services because of this, and moving our customers to bank transfer only - most of them have indicated they would understand and accept such a move. Has anyone else had issues with PayPal and the postal/shipping insurance field? It's completely non-present in the full values list emails we're getting on these invalid IPN emails Gaz
  23. totalnumpty

    Checkout by Amazon for osCommerce Support Thread

    So when is the rest of the world going to get it? (just as importantly, when will the rest of the world be allowed to sell on Amazon Marketplace etc?
  24. totalnumpty

    Modular means "Modular", right?

    I think we both agree that osCommerce needs to have some dedicated time applied to modularisation. My original intent in replying was not to try elevating one software over another, but to illustrate examples from how other packages are doing modular expansion. As I said, I like osCommerce - I like its flexibility and expandability, and that generally speaking, the core files system and conventions are very logical once you've had a little time to explore them. It is the routine upgrades that are a real bind - whether it is actually the effort required, or the way the scope of the changes is presented, I'm not sure, but I've not upgraded any of my sites from RC1 to RC2 because the amount of work implied is simply too much. Then there is also the effect of core upgrades in relation to "monster mods" - CCGV / CCGV(Trad) especially springs to mind. CCGV v5.20 was apparently the last stable version and that worked with osC 2.2 MS2. Since that version, the forums are full of howls of agony from users unable to complete installation into an RC1/2 install. The developers for CCGV(Trad) have emphatically refused to attempt a port of their version for any RC osC version and have repeatedly stated they will wait for the final osC release - that leaves everyone who downloaded osC from osC.com between mid 2007 to present and into the future, unable to use either CCGV version. CCGV is not the only "monster mod" with this issue, SPPC appears to have revolving issues according to the forums. When I read the latest queries from the threads related to SPPC and other price tiering modules, I get the impression that osC's architecture is designed to stop such modules from operating successfully - however, I also blame the contrib authors in part - each time a fix or improvement is uploaded, they RARELY state which osC version it applies to and I suspect too many support seekers are simply downloading a package that looks as if it's for their osC version, but isn't, because the contrib uploaders did not include enough versioning information. osC core teams and the osC website are to some extent also guilty in this - there is a general dearth of info about the core code differences between the older MS2 and current RC series - what I'm referring to is for the "little changes" such as the one that killed off so many mods in the MS2.2 to RC1 switch in the overall checkout/payment/shipping core code files. I lost count of how many wasted hours were spent trying to add a mod, discovering the install location had code changes, and then having to rip out progress so far and look for a different contrib to do the same job because the one I wanted was no longer compatible with an RC osC. This then of course comes back to the old argument of should RC versions of osC be the prime distribution file set? Like many others, I believe that in July 2007, Harald & Co made a major blunder by removing MS2.2 as the primary download and replacing it with RC1. They should have offered the two alongside each other, offering MS2.2 as the stable version, and RC1 then RC2 as the latest public availability of the development version. Had they done that, my sites would have been on MS2.2 and CCGV and SPPC would be installed and running, instead of missing, and I would not be having to run separate sites for wholesale & distribution customers instead of having them integrated under one site with the retail interface. Unfortunately, my sites were originally installed (basic install and setup) by someone else, who simply grabbed the offered download version from osC.com and ran the install without checking version number. The version number also did not become significant until a couple of months of site development and product populating work had been done, then it was too late to revert. I suspect many webmasters new to osC have found themselves in that position. The summary point is that there needs to be a better system for completing core code upgrades, or at the very least a better way of presenting the upgrade instructions, such that they don't inhibit users from upgrading. I also believe that (as with RC1 and RC2 for example) when core devs decide a major function like checkout needs a major operating code rework, that the core devs put out a consultation call to the contrib devs whose offerings rely heavily on the then current operation system for the section to be upgraded - dare I say IPN & API call back functions from payment processors + CCGV + the completely reworked checkout_process.php between MS2.2 and RC1 and RC2? Gaz
  25. totalnumpty

    Modular means "Modular", right?

    Errr - not quite A blog has posts, and comments, and threaded replies, and threaded discussions, and pingbacks, and trackbacks, and many of the functions of a wordprocessor and DTP package, including all of the html available to osCommerce product descriptions, and a whole lot more besides. Products have prices ... yup, as demonstrated by several full featured shopping carts that are simply copy-and-activate plug-ins to WordPress. osC itself is also just a plug-in for Joomla! within the CMS structure of that package. In addition to categories, blogs also have tags and authors and editors and contributors and a host of other post/product taxonomic data that does not exist in carts - this balances out the cart's tax and products-into-cart functions. Additionally, whilst osC reviews can have star ratings, so can blog posts (and comments, and even the images - all rated independently of each other within a single post or page entry) it just needs the plug-in to be uploaded and activated - there's around 20 or so different ones, each with a slightly different focus or style, to choose from. The cart's checkout system is undoubtedly the biggest coding difference between a blog and a cart, however, consider the massively multi-user "product creation" functions native within most blogging softwares - from basic commenter, to contributor, to author, to editor to admin (using WordPress heirarchy) as opposed to the single admin native to osCommerce. Blogs win therefore on organisation scalability. On this topic, WP comes in two flavours - single blog version, and WP-MU which is massively multi-blog management within a single install. osC has the Multiple Stores from single install contribution (it's a monster to install and highly unstable when adding further contribs in my experience) therefore why not target osC 3.x to release in two variants the same as WP - single store and multi-store - until they do, WP is way ahead of osC or Zen or any other cart system on that one. External shippers and payment processors - see the comments above about the cart plugins for WP and other blogs = identical functionality but in a drag and play plug-in. Equal ranking therefore, though the plug-in system of WP actually keeps it ahead of osC on this one, due to the ease of 1-click upgrading when (for instance Google Checkout) a payment processor makes radical changes to their API or terms of service and the plug-in author upgrades the plug-in's code, but not every blog script is as advanced as WP. Blog plug-in carts are multi-currency too, and via a plug-in, all monetary value mentions in any WP post or comment or page can also be made fully and automatically multi-currency - polling the reader's IP address to get their country and auto-converting to the local currency of that IP address with exchange rates pulled from the likes of XE.com and other servers via a cached currency chart (timing of which is usually schedulable via WP-cron or server-cron, including multiple times per day). Currently this is a drag and drop plug-in for WP, but not for osC, and even the contribs that are available, have to be merge-installed to get the same full functionality, even then they only work on catalog product's prices, not the prices quoted in text from the language files (e.g. a shipping insurance compensation narrative in /shipping.php). Blogs win emphatically on that one. For WordPress it's a drop and play plug-in called "eShop" - and it can be used for both digital and tangible goods, supports PayPal style processors as well as the online direct card processing services and merchant services. See? That's part of the problem - you're approaching it as a programmer, not as a retailer or wholesaler. Options are exactly that - options! They are either free, or cost extra. That's all a customer wants to know on the pricing front. Therefore code it as "this extra stuff costs this much to add it into the bundle" - anyone doing more than that is just making life to difficult for the buying customer and they'll click off to where it's easier to buy. Hmmm ... OK - to me "getPriceFormatted" should be stored in the customer table, and based on their country (comma or period between currency unit and cents? etc.) which will yield the correct currency symbol ($ etc) and whether it should be to the left or right of the actual value. All this should be pulled either from the countries database, or from a flat file that can be edited within the admin interface (sayyyy ... would that make it a .... module ... by any chance?). Horses for courses - I've never been able to get to grips with diffs - gimme a set of text install steps and the code to copy over. Of course, that easily deprecates in favour of a real drop-and-go modular plug-in system like WordPress's ;) Gaz