Latest News: (loading..)

totalnumpty

Members
  • Content count

    239
  • Joined

  • Last visited

  • Days Won

    1

totalnumpty last won the day on November 1 2010

totalnumpty had the most liked content!

1 Follower

About totalnumpty

Profile Information

  1. But, quite honestly .... a commercial themes developer would naturally say that .... hmmm? "Vested interest" springs to mind.
  2. Harald !!!! You're teasing again - you've been eating mischief-cookies before bed, haven't you? Naughty, naughty :P
  3. LOL Mark - there are times when you display a sublime mastery of the art of understatement. ;)
  4. @ Harald - many thanks for the answers - for now, at least, I can disconnect the turbo-charger on my pacemaker ;) @ HomeWetBar - there's a current contrib for 2.2 RC1 & 2 that adds a couple of fields to the create product page and database, which allows you to add new sub-directories on the fly while creating new products or editing existing ones. It's a fairly quick and simple install and works perfectly (I use it on all my sites). Wish I could remember its name , but it's eluding me. Gaz
  5. Thanks Harald So, in essence, what you mean here is that the term "keyword" is in effect a user defined variable and could be a traditional product title, item ID (such as ISBN or UPI), or a site page ID etc? And that what you have done is extended the current (2.2 RCx) function of using either the osC product_ID or item title? Hoping I've got that right? Re the paths - with the new system, do you envisage it allowing WordPress style folder structuring such as - /httpdocs/bootstrap index.php /httpdocs/store/public directory content and such similar arrangements that allow the site root to remain relatively empty of files (even if it has a large folder list) - I find such arrangements do tend to reduce hacking by unauthorised persons (WordPress got really bad with it late-2008/early-2009 until I implemented that system on my sites). One other query along this line (a pseudo feature request) is an easy way to have an external point of display for products, using simply thumbnail, title, price, with an ordering choice of newest / specials / random / category - rather than having to implement plugins and hacks to extract such data into pages of other scripts (I like to have a small random display in blog sidebars etc). Potential here is that I'm thinking of something like a universal widget or mini-grid display. Not sure what terminology you'd give it (I have a habit of naming things to suit how I think - LOL - complete with appended expletives if they're being a pig to implement)). Have to admit, I'm looking forward to 3.0 going RC and Gold - forgotten if you mentioned if there'd be an auto upgrade path between those? Gaz
  6. This is confusing - does this mean the product title will not be used in the URL, but instead a keyword assigned to the product? If so, can that keyword be a "key phrase"? This could cause major problems with Google and "duplicate content" issues in URLs - think of the variations on a product e.g. T-shirt T-shirt Red T-shirt Red size L T-shirt Red size L Ladies T-shirt Red size L Ladies Adidas T-shirt Red size L Ladies Adidas Olympic Logo etc That's why we have product names/titles - to take care of all the variations for similar products and use them as unique identifiers. Simply using a key word as the URL uniquifier is not going to work other than in the antique collectibles world, and probably not even there either - how many different Chippendale chairs were ever made? If you're meaning to use something like the ISBN number of a book, or the merchant's UPI stock code, then be prepared for osC based sites to vanish from Google search results too, and the actual selling side of the community to be howling for your head on a plate. Unless the search engine companies have told you something they haven't said to the rest of us, then please go with the ecommerce standard URL format of domain/product-title or domain/category/product-name - otherwise all us merchants are sunk. Can the oscommerce/ be renamed as per current practice? I understand and applaud the obfuscation of the osCommerce/OM framework location, but seek reassurance on this point that years of inbound link building can be retained if an osC 2.x to osC 3.x upgrade is performed Thanks Gaz
  7. Unfortunately Harald, that may be leaving it too late - as you know, for a hosting company to upgrade is not the same as you or I doing it on our personal machines or office networks. They might have 1000's or 10,000's of servers to roll it to, and have to create procedures and validations to ensure all is well etc. One of the reasons the hosting companies are so far behind the developers is to do with resource availability for such a major project. The sooner this is brought to their attention, the easier it is for them to drip feed resources for the planning stage of such a project. Simply rolling up to them and saying "upgrade to 5.3 NOW or lose all your osC customers" is going to go down like a lead brick in a fish tank. Alternatively, launch an "osC 3.0 ready" list of hosting companies sub-page here on osc.com and let the community keep it updated with details of which of their hosts are up to date enough to run it - it would also serve as an extra whip to companies not ready, to get ready. Something similar needs done regarding which companies are/are not SSL ready too - there's a huge number of hosting services that make SSL impossible (or claim it is) due to their configurations - especially in the shared hosting arena. Gaz
  8. Hi Harald Just missed earlier that the new v3.0 is going to be PHP 5.3 dependent - i.e. will not run on anything less than 5.3 I think you need to put out a pretty urgent call to the entire osC user base to start hassling their hosting companies. I had a trawl earlier after realising this requirement - none of my current hosts are on 5.3, they're all on 5.2.x - so I then had a hunt around some of the big name hosting companies that I currently don't have accounts with - again, none of them were on 5.3 or higher. This will be a major support overload for the osC team and the forums - there is going to be so much of the script broken by laggard hosting companies that this needs to become a global pressure movement from site owners and developers. I know that self host dev environments such as WAMP and XAMP run 5.3 - which is why "obscure" support tickets are kicking up throughout the open source world - devs are building in features such as the new DateTime PHP class (awesome and long overdue) but the hosts cannot support it. Please perform some form of broadcast on this - let's start building the pressure on the hosting companies now, so they are ready for osC 3.0 when it goes RC or Gold. Gaz
  9. Thanks Harald - sounds good I realise not everything can be done immediately (no matter how much we wish it could), but certainly having the "drop in" extensibility will be a massive boost to shortening site development and delivery time. Look forward to it rolling Gaz
  10. Thanks Harald I did look at the structure on Github and it seems to be moving to a modular OOP structure. However that still does not guide me as to whether it will have drop-in plug-in capability for contribs in the same way as other scripts. I know there are arguments for why it cannot in the 2.2 stream (though again, that could have been sorted out programmatically). Just as an example, several devs say that it's impossible to account for GST / VAT across plug-in contribs. MY thinking on that is quite simply "rubbish". If GST / VAT calculation were itself a module with settings in admin, then it wouldn't matter in the slightest how many core or third party contribs were above it on the checkout final order total. It's this sort of leap that is needed to make the script as flexible and development/customisation friendly as other scripts out there. Don't get me wrong. I cut my PHP / SQL teeth on osC too, but at times it was more like wrestling a bathtub of octopuses than website building. There are now so many forks of osC / Cube / Zen and so many various hosted drag and drop customisable carts now, that osC needs to do something pretty radical for the non-programmer web admins or lose the mass market race. Gaz
  11. Harald It's great to see osC 3 moving on apace, but like other posters, I'm concerned at the lack of availability of a stable release for 2.2 Right now I'm running all sites on 2.2 RC1 simply because that's what had (only just) been released when I started my first site, and that's the code base I built variants around with mods pre-added before install. Whilst I love osC and enjoy the flexibility it delivers, it does become a pain to extend when a client (internal or external) asks for a LOT of additional functionality. There are hundreds of contribs that can do the jobs required, but they all have to be hard-coded unless they are a payment or shipping module, and that brings it's own challenges as, for example, I posted in the Shipping Insurance mod page regarding PayPal's messing with shipping insurance options, which completely broke several sites for reasons beyond the control of you, contrib authors, clients, or myself. The fix had to be hard-coded direct into core files, and had to be written from scratch first. With pluggable contribs, that would have been a one-click upgrade from the contrib author or community. Will osC 3 be bringing in plug and play modifications in the same style as WordPress or SMF forums etc? I've heard all the arguments and had a few debates about why osC is not WP and so on, but I still maintain that the team are missing the point entirely - osC COULD have the same plug and play modular contribs and mods as the other packages, IF the hooks and pluggable points were available in the wireframe. Absolutely, the first requirement for this is to make the templates, themes, and css as table-less as practicable, and to separate visual theme from operational coding by making far, far more extensive use of functions and classes, instead of every php file being choked with php, DB calls etc - those should all be in functions/classes, leading to the theme files containing only the layout and function-call coding. If this approach was taken, then contribs could also be function call driven, and able to drop in as plug and play with calls to action hooks and hook points embedded in the core code. The contribs should have no need to modify the core code, they should be just registering their own function call in the appropriate sequence register. Have any of the osC team looked at how WP and SMF do it? It makes everything so simple, including extreme customising. It is to my deepest regret that I don't have enough spare time to create a working model of this from a 2.2 RC1 build, to show that it is possible. It feels at times that the team devs flatly refuse to believe it can be done, without trying it, yet many open source applications in many application sectors, are doing exactly this, including shopping carts. Reading your latest OSCOM 3 descriptions on the blog, particularly about the subsite-ing of major core units (admin, store, checkout, accounts etc) leaves me hopeful you will be driving for what I have described ... but I'd like to see a road map for it, otherwise I'll just have to keep delivering 2.2 RC1 based sites. Gaz
  12. 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
  13. 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
  14. 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
  15. 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