Jump to content
Kuuzu Forum


Popular Content

Showing content with the highest reputation since 07/21/2018 in all areas

  1. 5 points
    I'm pleased to announce that all further work done on @burt's version of CE will be done under the Kuuzu banner. This will be known as Kuuzu 'Legacy', and will be an interim version until work on Kuuzu 1.0 starts in earnest. Resources are spread thin and attention is currently scattered so it's best get a bit of focus. The planned timeline is: Kuuzu 'Legacy' - based on osC CE but with major improvements (but not too many!) Release Aug - Sep 2018 Kuuzu 1.0 - based on 2.4 Release mid to late 2019 Kuuzu 2.0 - based on what @clustersolutions is investigating (or even something else - but it will be radical) Release Late 2020 All releases will come with an upgrade mechanism so stores can be easily moved to the new version. First job is to work together and get Kuuzu 'Legacy' out. If you can help express your interest below.
  2. 3 points
    I'm willing to take ownership of this if the team will accept my version of a product class. I really dislike Harald's V3 product class -- it mixes the database calls, business logic, and some output formatting into a single class. This works if nothing changes, but as @burt has found, it's a pain to revise if you need extra database fields etc. My approach is to have nothing but the data retrieval in the class. The business logic all goes in the modules, and the presentation in the module template. This is about as close to MVC as I get. It greatly simplifies changes in any of those areas. No changes are needed to retrieve additional database fields as long as they are in the existing Product tables. Changes in business logic can be managed with a new module or modifications to the existing module(s), and changes in presentation are just changes to the template. Like Gary, I am insanely busy right now, so my time is limited. I can handle something this size in a reasonable timeframe, but probably nothing else. Regards Jim
  3. 2 points
    A few things: I thought the name was going to be Kuuza rather than Kuuzu, as Kuuzu didn't mean what you thought it did? Schedules slip, and this one is already on a one-per-year rate. Keep in mind that if a product isn't refreshed/updated at least once a year (12 months), the market regards it as dead. This is what has killed osC, and is what will kill Kuuz* if you're not careful. Please plan for some intermediate releases so that even if schedules slip a bit, we're still going no more than 12 months without a major update. You can't afford to lose momentum in product releases. For example, a current stable CE/Frozen could be 1.0, with BS4 as 1.1 4 to 6 months later. Be careful about naming and numbering conventions. "Legacy" should be "1.0", the osC 2.4-based release should be 2.0, etc. You want to have a clean, consistent system, and not a hodgepodge of names and out-of-sequence numbers that sows confusion. And you never want to do like osC did and have a "Milestone" or "Release Candidate" out there for years as the official release.
  4. 2 points
    I agree with this but I also think that the base should include some pre-made modules just to help people and make the shop more user friendly. Some of these modules would be optional to install but would be available. - Coupons: I would say ALMOST all shops use some sort of coupon module and/or gift vouchers - Better image handling: we could use this opportunity to get better image handling integrated into the core product (auto-thumbnailing / repsonsive images in some form) - Better attributes: Ability to have text options, files, images, whatever AND the ability to keep track of stock on these - Human readable URLs: I know this is a touchy subject and not a requirement. Most shop owners want this. I know the idea is to not clutter up the core project with addons but there needs to be some addons available that are maintained by the team that actually work properly. There needs to be features that attract people to use to software. Bare bones software does not attract users. More advanced features can be made available as commercial addons.
  5. 2 points
    IMO, making the admin bootstrap would be a time sink, time we don't have when there is so much else to do. Everyone needs to be on board, no stupid shit as is seen at the other forum and elsewhere. If you want to code something, you own it. When it is presented and changes are asked for, you make the changes without arguing. If shopowners want to code something, I'm all for that. But you will be treated as a developer, and developers get treated harshly.
  6. 1 point
    I had problems a few years ago with backups, and I now use the database optimiser addon.
  7. 1 point
    Getting back on topic, my part of this is ongoing - getting the v4 bootstrap into the shopside. I've planned to have this completed asap, and that is looking like late Aug, perhaps into the first week of September - I'm giving bits of time as I can. In the meantime, could someone have a look at "Frozen" /includes/application_top.php and see what else can be changed in there to make updates to software easier in the future? Typical example of that is the effort a few months back to make "actions". Another example could be moving the breadcrumb bits out of app_top and into the breadcrumb module - I don't know if that would work as we may not have the data at the right time for display purposes (but maybe someone can try?)... Not particularly talking about anyone actually doing codework, more about having a think to see if anything can be simplified or removed elsewhere... Does anyone recognise any other "bottle necks" in the core code, that would be better/easier if those bottlenecks were changed to something else ?
  8. 1 point
    As to the name, I say just leave it. Most of the shopowners won't know or care what it means, and we have a funny story to tell the few that do ask. Regards Jim
  9. 1 point
    Get rid of the 1999 DVDs etc and replace with a few up-to-date products (maybe 3?) and a category... Is what I was thinking.
  10. 1 point
    @ArtcoInc I didn't mean to say you were wrong. We all need to stretch our minds past the confines of osCommerce. This is not easy, or at least it's not for me. I'm working at it still. Regards Jim
  11. 1 point
    @ArtcoInc Think big. An Addon/App can create the database tables it needs. It can contain a class to access that data, modules to format the data as needed and present it in the desired format. Another App can build on that data or use a completely different scheme to replace the first one. All of this is possible. How fast this can be done is the big question. You probably don't want to make major changes in the Legacy code with the limited time we have to produce it. Bigger and better schemes should wait for 1.0 or preferably 2.0. Regards Jim
  12. 1 point
    I'm certainly not insisting or stating that old v3 class should/must be the one that is used.
  13. 1 point
    - that's me putting a hand up to do something. If products are already covered then my preference would be the import stuff but gut feel is that product class should come first if it's coming now.
  14. 1 point
    Just as a little interlude, a fun moment if you will, and to show that eyes are sometimes on a bigger picture; https://en.oxforddictionaries.com/definition/syzygy
  15. 1 point
    Nope, never thought what was said was right. I say again please walk away from the keyboard when there's only negativity. It just doesn't help the community nor any personal cause. Oh, I do get it, and I am not on any side. Just try to help when I can...
  16. 1 point
    Starting point for Legacy, merge together: - @burtGarys syzygy: https://github.com/gburton/Responsive-osCommerce/tree/Syzygy - @BrockleyJohn John's defrosted: https://github.com/osComma/Responsive-osCommerce/tree/defrosted - update to BS4 if Gary is willing to give his work over - add the bug fixes listed here: https://forums.oscommerce.com/topic/412984-edgefinalfrozen-bug-list/ and which are not yet included in the 2 repositories - add some more modularity, for example modular shopping cart and modular checkout pages - modularize review pages, create account etc. - standarise old modules like product_listing.php, checkout_new_address.php etc and integrate them into content modules