Jump to content
Kuuzu Forum


  • Content Count

  • Joined

  • Last visited

  • Days Won


MrPhil last won the day on April 2 2019

MrPhil had the most liked content!

Community Reputation

64 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. MrPhil

    DAL (Database Abstraction Layer)

    Basic SQL is the same across all database engines, but the devil is in the details (e.g., MySQL LIMIT is something else in other databases). A DAL can either be given an "extra" array of things like limits, and tack on the appropriate form of "LIMIT" to the query, or it can accept, say, MySQL as its base language and go in and edit the query (on the fly) to change "LIMIT" for non-MySQL databases. The idea is to get queries and actions (e.g., altering a table) specified in a consistent manner that can be made to work across any database on the market. This would include the Big Boys like Oracle and IBM, should your shop get that big. A DAL could also handle things like importing/exporting .sql files with different forms of comments and different syntax for various operations. I haven't looked at ORM, but I would assume that it's doing something along those lines.
  2. MrPhil

    What the software should be

    Another thought on how Kuuza should be organized... regardless of how an "add-on" is structured and how it plugs into the main product, when you update the main product (e.g., Kuuza 1.0 to 1.1), all your add-ons come with it. Automatically. Like Firefox and Thunderbird do, and maybe other apps (Wordpress?). That means keeping a list (in the DB), in desired order of application, of what add-ons have been applied, and keeping the .zip files or whatever around. Upgrade (replace) the base .php files, then Kuuza automatically reinstalls all the add-ons (whether they're true plug-ins, or core code edits, or whatever). If a conflict or install problem arises, inform the user and bypass that add-on for now. Uninstalling an add-on is simply getting a fresh copy of the PHP files, dropping the add-on from the list, and reinstalling everything else. It should be a lot cleaner than what osC has now. Maybe something could be done to allow site owners who have manually customized a file to preserve their work across reinstalls? At the least, don't wipe out their work when they upgrade the base product. Perhaps manual changes to files could be "tracked" by comparing to unmodified files, and auto-generating a custom "add-on"? CMS's such as Wordpress, Joomla, and Drupal assume that all modifications are stored in the database or in separate files (I'm not sure what the mechanism is here), so they can wipe and reinstall the base product without fear of compromising user changes. Kuuza should try to get something close to that model, even if more stuff is contained in PHP files rather than in the database. The whole notion of shipping Kuuza as a lightweight skeleton or framework with lots of preinstalled add-ons (to make a useful out-of-the-box product) could be accommodated with this architecture. It would be easy for an owner to swap out a preinstalled add-on for a higher function paid add-on.
  3. MrPhil

    Guest checkout

    Yes, I was trying to consolidate previous discussion into a summary, along with some new ideas. Didn't mean to sound like I was taking credit for your ideas!
  4. MrPhil

    Guest checkout

    OK, I can see customers as being reluctant to create an "account" because they're afraid it gives the store permission to keep data around for a long time (reality: most data needs to be kept for business/tax/regulatory reasons anyway) they're afraid that having a "long term" relationship with a store (an account) will mean they're innundated with spam (reality: most mailings should be controlled by explicit opt-in selections that can be revisited at any time) remembering yet another account name and password is a PITA (using their email address is better than an arbitrary account name they'll forget) Almost all of the information you would collect for an account is needed anyway for processing an order, so it's not that much more work for the customer the first time around. Giving keys or tokens to a "guest order" to access order status, write reviews, make returns, etc. is a possibility, but the big prize (for customers) is not having to enter everything again, once their email is recognized. You can't keep credit card numbers, etc. without going full PCI-DSS compliant, but does keeping the shipping address, phone number, etc. violate any regulations if access is not password-controlled? An email address is fairly public knowledge, so would it be a security problem to prefill fields based on an email address that the store has seen before? Or should it require a password to retrieve such information? How about allowing access to writing/editing reviews, and checking order status? The confirmation email could have links in it (with tokens) to perform these actions, which could be used as passwords. Or, the customer could create an account at any time (by giving a password), and streamline their interaction that way. So, the basic checkout interaction could work this way: enter your email first, and if it's known, ask for a password if there is an account. If the customer does not log in with a password, ask for all shipping information. If they do log in, prefill the shipping information, etc. Ask (if they do not have an account) near the end if they'd like to create an account by giving a password. In the confirmation email, give links with long tokens to check order status, enter a review, or create an account with a password (if they did not have an account). If the customer realizes later than they did in fact have an account (or had forgotten their password), and had checked out as a guest, they would need some way to pull that order into their account (another link, if the email is recognized?). It gets more complicated to merge two accounts if they used a second email, or otherwise created another account, but it should be possible. Would this work, as a normally guest checkout that allows account creation (with a password), and access to various functions via link with token regardless of whether they have (or used) an account? To encourage account creation, what sort of functions or goodies should be available only to those with accounts (cross selling, upselling, "you also viewed", a formal wishlist, prefilled shipping address, etc.)? For "guest" checkouts, what should be the protocol if the shipping address or contact information changes? The email address should receive a copy of the order anyway, plus the changes, just in case something fraudulent is going on. Checkout flow: ask customer to enter their email not seen before? ->(A) seen before: account for this email? Yes: ask for password declines to log in, or gives wrong password? ->(A) gives correct password within 3 tries prefill shipping address and contact info (if customer changes anything, note that in conf. email) No: no account associated with this email (and repeat customer) (A) merge point enter shipping address and contact information if no account for this email, ask if want to create an account Yes: enter password twice, store hash in new account entry ask customer to enter payment information
  5. MrPhil

    What the software should be

    Some things that keep coming up on osC, over and over, need to be thought about in the architecture of Kuuza. These are things like pricing, shipping costs, and taxes; which have so many ins and outs and special cases that simple solutions just can't handle. While no store owner wants to write their own custom modules for these, it may be necessary to do so, or at least we can provide some sample code that can be customized and plugged in. There's also how to handle incorrect or inconsistent addressing (affecting shipping, taxes, and interfaces to payment systems). From a customer point of view, they want to see all the correct shipping costs presented (that the store supports), with the cheapest listed first. Every shipper/post office has its own way of doing things, that needs to be accommodated, as well as "buy X amount, ship free" deals, multibox shipments and drop shippers, and restricted shipping lists (e.g., physical goods by US Mail only to US addresses, downloadables to any place worldwide not embargoed). Every US state has its own idiosyncrasies on what tax class to apply on what product, and how to map addresses to tax jurisdictions and their own set of rates for tax classes. Simple solutions such as "item -> national tax class, state -> list of rates per tax class" simply don't exist. Of course, the proper solution is to impose a national rationalized system (consistent tax classes, consistent state+ZIP mapping of rates, one-stop payment) but like that's ever going to happen... And pricing gets ever more complicated with "member" or "buying club" discounts, "buy N, get M free", volume discounts, repeat customer discounts, coupons, credits, etc. Buyers would like to see prices update "live" depending on what they've already got in their cart ("regular price: $X.XX, member price: $Y.YY" sort of thing), and their buying history and knowledge of coupons and credits the buyer is holding. It gets very complicated very fast, and an architecture that allows new modules to be plugged in to take care of these cases could be useful, rather than grafting more and more cruft on to the side of what once were simple modules. Oh yes, and make it simple enough to work with that a non comp-sci business person can easily do it. Granted, it's a lot on the plate, but at least we should be thinking about how it could be done. Do other carts out there do anything like this?
  6. MrPhil

    What is the planned release date?

    No. There is still a lot of discussion going on over some very basic design decisions. I don't expect to see a release 1.0 any time soon (and if the pace doesn't pick up, ever). If you want something now that is production-ready, use osCommerce Edge/CE/Frozen for now (not the official release). There should be an upgrade path to Kuuza 1.0, whenever that's ready.
  7. MrPhil

    Guest checkout

    My impression is that customers prefer "guest" checkout because they fear that if they set up an account (no more than adding a password), they'll be inundated with spam, and not having a formal "account" somehow protects them from that. How can a merchant deal with that fear? Also, it's another password to keep track of; so easy to forget that you even set up an account with this merchant. You really have to give them something extra (of value) to induce them to create an account, that will overcome any fears or annoyances -- repeat customer discounts/coupons, ability to write reviews, enhanced order tracking ability, past order history, useful cross-selling, etc. Let them feel that they're missing out on something if they don't have an account. Of course, only customers who intend to order again from you are likely to create an account in the first place -- a casual one-off buyer won't create an account if they think they'll probably never see you again. Be sure to make it easy for someone who does come back to pick up their past order history, etc. when they decide to create an account ("We'll keep the light on for you").
  8. MrPhil

    So where i landed?

    I put this guy on my "Ignored Users" list (click on your name at the upper right). I no longer have to read his nonsense.
  9. MrPhil

    So where i landed?

    Again, please don't call it "Legacy". Make it "1.0". Calling it Legacy makes it sound so... old fashioned, copycat, and therefore undesirable. Keep the version numbering clear and simple (1, 2, 3,...) and make it sound like it's something worth picking up and looking at, not something retro. If you shame it with a "Legacy" label, no one will use it -- they'll wait for the "real" one to come out. Then they'll drift away and use other products. Marketing 101.
  10. MrPhil

    What the software should be

    Well... say we have the basic data baked into the store -- is it feasible to have several different codes to handle taxonomy vs. categories vs. ?, all working on the same data, or is a store owner's choice of organization going to affect what data needs to be used? If the store owner makes the decision up front of which they want to use, their data could be tuned to one method or another. However, they might not be able to easily switch back and forth (e.g., let the customer select which view). It could be possible to switch from one to another, but that would likely require a DB revision (offline, with store temporarily down). Should all the data be present at all times for both/all methods (and will a store owner keep the unused data up-to-date)? What kind of data are we talking about, per product, per category/class, etc.? Is there enough overlap that much of the data could be in common? For non-overlapping parts, if the store owner chooses one search/classification method over the other(s), how easy is it for them to go back and update missing data if they decide they want to switch views, or give customers the choice of views? Don't wed yourself to taxonomy just because it's hip and kewl -- it may be the wrong choice for some merchants. It would be best to give a choice of which one(s) to use (or none at all!), but we have to first think about the impact on the data we need the store to keep.
  11. MrPhil

    What the software should be

    Regarding a "basic" cart, something to keep in mind is how it gets upgraded when the next version comes out. Some CMSs replace all PHP files, assuming that all customization should be in the database contents. It should be a one-button operation (at the least, check for updates to both core code and all official additions, with hooks for checking third-party additions/extensions, and inform the owner if updates are available in a big banner in the admin area and possibly an email). Same goes for language support files -- know what core languages are being supported, and what national variants (e.g., Spanish, updated by Argentine Spanish, on top of built-in English), and inform when updates are available. I think it was over in the osC forum somewhere that I recently discussed this at length. Templates/skins might be handled in the same manner. If a store owner has modified core files, selective upgrade (deltas/diffs) might be applied, or just tell the owner that the current file cannot be replaced because it's been modified, and throw it in their lap to manually upgrade (load in the new file with a .new extension, so it's available for comparison). Come to think of it, you might want to upgrade all or none, rather than do a partial upgrade. Above all, keep the store owner informed about upgrades and make it as painless as possible to upgrade, so we don't have people asking for support on 15 year old installations ("my store is heavily modified..."). Regarding categories vs. taxonomy, I've seen some long discussions on it (can't remember if it was here or over in osC land). It's not clear to me that one method has a clear advantage over the other, so making it modular and giving the owner the choice of using either might be a good approach. That is, don't bake categories into the basic structure of the product data, but make it something on the side. Is it even possible to enable both, leaving the search choice to the customer?
  12. MrPhil

    What the software should be

    A few more thoughts on language support. Since translations to non-English always seem to lag behind, how about the following: US English as base install, acting as fallback for anything not supplied in another language (no missing string errors, but could get English text in the middle of a page). Generic "other language" (e.g., Spanish/Espanol as written in Spain) installation that any "es_*" language would first point to. It would supersede the US English strings, hopefully with most if not all defined for Spanish. Anything not defined would fall back to US English. US English would be treated as the generic form for any en_* language (or UK English, if most developers would prefer that, for base install and generic English language). Country-specific terms that differ from the generic form of the language (e.g., Argentina versus Spain). It would not necessarily be a complete replacement for the Spanish package, and would probably lag even further behind than the Spanish package. If you have a common or generic Spanish language package (core + add-ons), and country-specific terms for various Spanish-speaking countries, would a merchant still need to add their own terms to fine-tune their store? I'm not sure how different something like Catalan is from "standard" Spanish (Castilian?), so Catalan might be "another language" or it might be a country-specific term pack on top of Spanish. Let's not get involved in autonomy disputes, etc. Regarding add-ons, any thoughts on the best way to handle them? An add-on might hit multiple modules or pages, so I don't know if it's possible to put everything into one file with a standard name, and automatically have the module or page try to load the add-on's base US English, then the language, then the country pack, if they exist (the base should, at a minimum). It would require standard naming conventions and possibly one file per module or page. Putting languages into a database might be a bit cleaner, with the same search order, and the database updated during add-on installation. Any idea how much slower or faster reading from the database is, versus a file? An add-on is likely to go out in US or UK English (base install) with sometimes one additional language. Some mechanism for checking and notifying the store owner when additional or updated language packs are available for an add-on (or core) would be good. The database could keep a list of what languages and countries are in use, and check for updates on a regular basis (check for new core and add-on versions at the same time). In the meantime, I suppose a merchant might supply their own translation as either a country-specific file, or even a merchant-specific override. The code might even solicit them to offer their translation as part of the language library, or advise them that their override may not be necessary any longer. On the subject of installation in other than English, it could be feasible to supply a handful of major languages. Wouldn't each not be a full Kuuza store, but just the text necessary to perform an installation and configuration? Perhaps a few dozen entries for each language? It really wouldn't bloat the installer all that much (even less if it can be requested and downloaded as the first step of installation), and can be erased after installation.
  13. MrPhil


    _____)) <(O^O)> *
  14. MrPhil


    I would give him until June 30 to offer "Edge" as the official 2.3.5, with a commitment to bring out "Frozen"+BS4 as 2.3.6 by the end of the year (provided that Gary's happy with it and it's been reasonably tested). I'm all for being "fair" to Harald, but he has left osC in the lurch for far too long (even predating his recent disappearance). If he has had confirmed health or family issues (we don't need to know the specifics, just that he has a legit excuse confirmed by reliable sources) and can't immediately resume his duties, he should turn over control of osC to trusted lieutenants to carry on. If osC is moving along vigorously, we can then discuss whether a Kuuza replacement is still needed (is that the official name now?), or if it would be better to work on osC 2.4 (provided Harald opens up support and development to others). Otherwise, it's the same old same old, and we should forget osC. My apologies in advance if this comes across as too harsh, but if we don't want osC to wither and die, something has to be done. If it's not clear that this fate is to be avoided, full speed ahead on Kuuza.
  15. MrPhil


    As Gary listed in the 9.5 year old discussion, there are lots of things that could be done with a good attribute system, from both the shopowner and customer point of view. Let's take everyone's favorite example, tee-shirts. I want to sell 5 designs in 4 sizes (S, M, L, XL) in 3 colors (red, white, green background) in two design variations (crew and vee neck). That's 5x4x3x2 = 120 variations, each needing their own inventory count. From a customer standpoint, I'd like them to see 5 products (designs), each with a selection of size, color, and neck attributes to choose from. A few complications: one of the designs does not go well with red, so it's only available with white or green. One of the designs is a bit saucy for kids, so we only offer it in adult (L, XL) sizes. For some reason, crew necks are not available with green. It should be easy for the shopowner to mark which combinations are allowed, and track inventory separately. The customer should see 5 products, and then select an allowed attribute combination that is in stock. If there are 5 SKUs (one per design), some means must be found to internally extend the SKUs to show the various combinations, for stockkeeping, etc. On the other hand, it could be 120 different SKUs, but then a means to gather and group them into 5 product displays (one per design) is needed. Oh, and be careful about how you handle extended SKUs or product IDs. osC had a lot of problems with using curly braces {} in external product IDs, which more recent PHP and server levels are often configured to ignore (security problems). You probably would be safe to use dashes/hyphens or similar characters.