Jump to content
Kuuzu Forum

All Activity

This stream auto-updates     

  1. Earlier
  2. 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.
  3. OSCOMMARKET

    What the software should be

    There is NOTHING, ABSOLUTELY noting what a country/city can produce them self, whats on the market today. absolutely 0. If we want it, we can do it all our-self. That's a winner for me already. But how we connect them?
  4. OSCOMMARKET

    What the software should be

    if i start to make $, i know who i hire and educate them in what to do. For me it is simple. I dear to say i have enough experience. Amazon and lookalikes wil be going to feel very , very sick. You cannot beat an individual living in a community.
  5. OSCOMMARKET

    What the software should be

    i expect a development period from A to Z in a max of 3 years. As that might seem long, within these 3 years a non-stop revenue system will take place. There will be made $ within these 3 years.
  6. OSCOMMARKET

    What the software should be

    The plan: hijack oscommerce towards kuuzu. in same stage develop a system inside laravel ( seems like the most in favorite ) . It is much harder to gain clients out of nothing, it is much easier to get them from something existing. We need to ignore the problems converting but still cover them in a howto to let them move.
  7. OSCOMMARKET

    What the software should be

    For that you all need to understand how adopting a framework is. Many development agencies or bureaus developed their own CMS within a framework. There is NONE package for FREE available for any of these frameworks. That can be changed, but can let them pay for "custom" scripts within. You only need to look at how the others try or do it.
  8. OSCOMMARKET

    What the software should be

    @clustersolutions Lets say we go use laravel. And it will go require lot's of discussion and work to do. Not even in laravel there is a real e-commerce package available what inhibits oscommerce functionality. I not even speak of the "most popular" ones. It just not exists! So there is a market. In fact there is a HUGE market open for it. Consider just 1 simple package, but that package can give so much options.
  9. OSCOMMARKET

    What the software should be

    This is not rocket science, but it is a fun concept to code. I sort of covered the matter using the 2.4 updater code and build it into 2.3.4 BS. When i found it it could do the job (when i build the market-place), i stopped coding to see how much audience there was on oscommerce. It not came to fruition on oscommerce, yet now we are here on Kuuzu talking about the matter? So... does that not have any effect on someones dignity? When i was seriously nice and discreet on osc, there where no discussions like these. It amazes me "some" guy was able to pull you all from the main source, yet no production made. Considering, all the matter discussed here, was an "in-progress" @ oscommerce. In the beginning......... it was NOT ME. I BECAME LIKE THAT. And the current situation and 0-results of any progress confirms "for me" , my excesses is the result of....
  10. OSCOMMARKET

    What the software should be

    NO. This is already covered whenever an addon is "submitted". Kuuzu 1 or 2 (whatever is the release). Kuuzu 2.1 (development version) or simply: Kuuzu 1 or 2 "nightly build". An addon maker should be aware of the progress and direction the "new" release is going towards to. The "small" versioning like Kuuzu 2.0.2 should not affect any addons, and "some" addons should not even have a problem with a Kuuzu 2.1.0. Kuuzu should have a automatic reporting to the author of the addon when it "fail" to install OR a manual reporting to the author. The way how the Author of the Add-on qualify his add-on is crucial. The Author is responsible, NEVER should be Kuuzu. (When Kuuzu lacks, Dev's should contact Kuuzu staff on Dev's add-on forum (not available for regular users). NEVER TRY TO INSTALL. First CHECK KUUZU'S CRITERIA. So the add-on maker MUST provide: > Kuuzu 2.0.X > Kuuzu 2.1.X > Kuuzu 2.X.X < Kuuzu 1.11.9 < Kuuzu 1.99.99 ( i know this looks ridiculous) Etc etc........ So first CHECK, Not even try to install. If not anymore compatible with latest Kuuzu version installed on the server. Just let the Kuuzu system "Disable" the addon. But yeah.... i got you on this.
  11. 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.
  12. OSCOMMARKET

    What the software should be

    My wish is that at the end when kuuzu makes a release right HERE. You go over everything you said above and try to track each of the work done or offered (via addons). You comment is LIGIT and friendly towards. I never as a dev myself can be friendly to the provider. So i have to do it myself! But most of all, i would like to do it together!
  13. piernas

    Design by Committee

    Hi Frankl, I suppose you're still busy but I'm wodering (I'm not the only one) why the project does not start - There's been some dicussion and a vague roadmap set up but does not seem to be final. By reading the forums it looks like there's no team and nobody is working on the project - you've been absent for months and does not help to clarify the current status of the project. Are you willing to continue with it?
  14. Dan Cole

    Guest checkout

    I think that's the ticket. Dan
  15. ArtcoInc

    Guest checkout

    @MrPhil No problem. As I initially suggested, if a "guest Checkout" is not built into Kuuzu (perhaps as an option?), the 'logic', or work-flow, of the checkout process needs to be modular, so that an alternative route could be added. Malcolm
  16. 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!
  17. ArtcoInc

    Guest checkout

    @MrPhil That's pretty close to what I suggested in the first post in this thread (abeit, with a little more detail) Malcolm
  18. 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
  19. 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?
  20. timray

    What is the planned release date?

    Thats great news.
  21. frankl

    The Plan

    Hi all. I've been away on vacation but now back. Been busy so far hiding posts which aren't constructive Let's see if we can get the initial iteration of Kuuzu out very soon.
  22. frankl

    What is the planned release date?

    Stay tuned. An announcement will be made soon.
  23. timray

    What is the planned release date?

    Hi, No, i was hoping there would be a beta so something because what I've been reading seems very interesting. Will just keep an eye out for any releases. Thanks
  24. OSCOMMARKET

    The Plan

    it can only work if do it together!
  25. OSCOMMARKET

    So where i landed?

    And i do not have to.
  26. OSCOMMARKET

    So where i landed?

    So, i try to get it back. But now it is up to you. Like everyone seems to get a chance in building up a new kind of e-commerce system, regardless if based on oscommerce or not. It's work is what should be measured, right? So, regardless my not so subtiel approach. (yet, even if it is not "completed", The admin BS4 became a favorite). So.......... let's first work on an admin, before even considerate work on the front-end. It is a known mistake to work first on the "oooeeesss and ahhhhhs, with a cool dimension given to it" , before make the front-end actually to work. The front-end will be worked out. And what i am saying now, it is not ment sarcastic, @burt have the expertise + much more, he know i know. I worked with him on it, and he know that. And if he remember.... THAT was fun to do. So why cannot work anymore like that? Is there no middle way to find? I feel i am made look like stupid. Just let's work together and see what comes out of it , it is all i ever asked. Before all my anger started, all that was already on the table. I was "Good before" , i became "angry" after. For none reason, i became ignored. It hurt'ed when kuuzu/kuuza was anounced, the ones you counted on most, choosed for it. But i was invited to, and that had a reason. My personality might not suit you. Yet............... my work speaks for itself. It does not matter if finished or not. For that we now we (I), have a so called team. That means we need to put our heads together. And it not matter to me if you are an as-hole, a good guy............. we will get along. We all have our "behaves" , and we all need to deal with them. Now it is me. In time, it will be some other guy. It is always gonna be like that. You cannot serve them all.
  1. Load more activity
×