Jump to content
Kuuzu Forum
frankl

What the software should be

Recommended Posts

As I wrote in the other post, this is what I believe we should aim for:

The core software will be basic, although the default install will be ready to sell products right out of the box, with essential apps included.

There were lots of great ideas thrown up in this thread https://forums.oscommerce.com/topic/412801-shopowners-club-core-suggestions/ 

The new Shopowners Council and Project Leader will be the final deciders so let them know what you would like to see here.

I think an app store for installing/upgrading apps right in the software would be ideal.

More classes, image upload handling, better execution of languages, and a whole new product attributes system are must haves.

Those are my opinions of course.

Share this post


Link to post
Share on other sites

I would like to propose a couple of additional "must haves":

  1. Modularity. 2.4 has a good start at this, but @Burt has added a lot more in his Edge version. I'm including Hooks and Actions in this category.
  2. The product attributes system needs to contain an inventory control system for each combination of attributes.

We need to set up some kind of list for product features. This should be divided into:

  1. Core code features. This should be kept to the minimum necessary for all (or most) stores.
  2. Widely used Addons. These should be available (in at least a rudimentary form) from the product launch.
  3. Other Addons that would be useful to add, but may be written later.

Thoughts?

Regards

Jim

Share this post


Link to post
Share on other sites

Sorry if I bump with duplicate content...

I put in another post this:

- NewCom must allow to oldCom users to use/update it in a easy / sexi way:

1. Database update in a script for dumies. People can try and see that NewCom uses their old data without problems (as easy that a windows user can test an ubuntu CD-rom without install it)
2. Languages definitions (at least English, Spanish, French, German). Good for italians, japaneses, chinois... Including ADMIN configuration
3. Allow old contributions - at least from 2.3 edge - to be compatible without problems at least in a legacy code in the first versions. I know, VLC, hexagonal or functional programing is the future. The problem is not the way you program, the problem comes when you only think in you and forget the purpose of the software you are dessining: a car software that allow to sell things with a code esasy to use.

4. (May be must be in "Point 0")

On 4/27/2018 at 3:25 PM, rudolfl said:

Documentation first. Core must be designed VERY carefully to make sure it flexible enough and can easily be extended in the future. implementation to start only after team agrees on particular implementation and requirements are locked. Any functional changes to core are to be documented, approved and only then implemented. Design and APIs are to be clearly documented from Day 1.

5. Template system for easy customize the web and secude designers to do templates.

More thoughts / dreams :

- App areas for free / payd apps where people can score them and see their popularity / valoration and core version supported

- A web where people can use the free or payd version (may be shopify or opencart model)

.. of course the web will be not in a wordpress installation but with NewCom!! :classic_laugh:

Share this post


Link to post
Share on other sites

I would suggest to keep functionality to an absolute minimum in core.

As much as possible should be implemented as a stand-alone module. This will allow for easy bug fixes/upgrades and changes to functionality. Will also allow multiple developer working on different features without interfering.

 

Rudolf

Share this post


Link to post
Share on other sites
7 hours ago, rudolfl said:

I would suggest to keep functionality to an absolute minimum in core.

As much as possible should be implemented as a stand-alone module. This will allow for easy bug fixes/upgrades and changes to functionality. Will also allow multiple developer working on different features without interfering.

 

Rudolf

I think that should be the plan too.

Rudolfi, you going to put your hand up for a seat at the table?

  • Like 1

Share this post


Link to post
Share on other sites

There have been many discussions about what is wrong with osC 2.3.x. I'm not going to rehash them here. It *sounds* like the plan here is to take the 2.4 foundation to build a new and improved version, hopefully addressing the problems with 2.3.x.

My question is: is the 2.4 foundation really capable of addressing the biggest problems, such as attributes (including inventory control of things like t-shirts in different sizes and colors), or will this require a complete rethink (and rewrite) of the core?

Share this post


Link to post
Share on other sites
11 hours ago, frankl said:

I think that should be the plan too.

Rudolfi, you going to put your hand up for a seat at the table? 

Absolutely,

With 20+ years of software development under the belt, I hope I can be useful.

Rudolf

Share this post


Link to post
Share on other sites
3 hours ago, rudolfl said:

Absolutely,

With 20+ years of software development under the belt, I hope I can be useful.

Rudolf

Can I put you down for the Management Team?

Share this post


Link to post
Share on other sites
12 hours ago, ArtcoInc said:

My question is: is the 2.4 foundation really capable of addressing the biggest problems, such as attributes (including inventory control of things like t-shirts in different sizes and colors), or will this require a complete rethink (and rewrite) of the core?

The short answer is "no".  
2.4 is an "on the fence" release designed to pacify those people who want a forward movement from the official osc, whilst also pacifying those who want to stay "close" to how 2.3 works.

The longer answer:
3.0 (which was in its time, absolutely the most brilliant piece of code I had ever seen) was unreleased. 
I won't say why it was unreleased but it was a personal choice of HPDL to nuke it.  Prestashop (which is now well regarded, has, at its core, that 3.0 code).

So, 2.4, with some backports from that older 3.0 - would be a hammer.  Backports such as products class, attribute variants, and so on.  

I'm not sure how many look at the CE (the community bootstrap code)...in that there is a cool Category_Tree class - this comes from v3. 
There is so much fantastic code in V3...osC could have been #1 cart easily, and I mean it would have hammered the other carts brutally.

 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, frankl said:

Can I put you down for the Management Team?

Or perhaps part of the Development Team?

Dan

Share this post


Link to post
Share on other sites

This is the last chance to "get away" with breaking osC compatibility, so let's make the most of it. We don't have to maintain compatibility with existing osC releases, so if something needs fixing (by changing it), now is the time.

There are a lot of things in osC that appear to have been initially implemented in a simple manner, and more and more cruft was grafted on over time to accommodate user needs. For example, product information update was done as an edit page. Later, someone wanted to bulk-import product data, and CSV-import add-ons came along. Perhaps we should think in terms of a CSV (and/or XML) update file or data array, with the edit page merely creating this file, and the base mechanism is the file import/process. In general, a clean architecture for both importing and exporting data (such as accounting data) is needed, as well as APIs to talk to other applications in real time (e.g., your warehouse inventory system, or your brick and mortar store POS system). Perhaps the inventory could be separated out so it could be easily integrated with another system? Even as a different database than the rest of the new Cart uses! Another area that has gotten very complicated is figuring taxes -- something very modular to insert tax at the appropriate time should be considered. Prices too have gotten well beyond a single number in the product database -- coupons, membership clubs, discounts, credits, sales, etc. I don't think we can cover all the bases in a first release, but if the architecture is suitably modular, new capabilities can be plugged in later.

Speaking of "plug-ins", the ideal would be for the new product to be considered as easy as Wordpress to install, configure, and upgrade. Yet, you don't want developers (function or theme) to be put in a straitjacket and severely limited in what they can do. It's a difficult balance to strike in consistency and structure, versus freedom to innovate. Beginners have constant struggles with osC, and anything we can do to streamline things for them would be much appreciated, while not putting a ball and chain on developers. We seem to forget that most store operators are not Computer Scientists or even programmers; they're not looking for a new hobby, but for a tool (appliance) to help them. For instance, why are there two configure.php files? It it really still necessary? Do we still need to separate out all the code for admin so it is in a separate directory structure? If security concerns require a separate directory under password control, can we have a single source of files (especially just one configure.php file) that somehow automagically gets copied over to the other side when updated? Besides the configure.php files, I'm thinking of all the utility files that have over time slightly diverged, and are no longer compatible between storefront and admin.

Speaking of modular structure, I think it would be great to have a Cart provided as a module library that are to be plugged into an application framework. The framework provides session control, signon, theme, common utilities, etc., and the Cart library modules do the Cart work. The Cart would provide a simple framework to use out of the box, but that could be replaced by something more elaborate if so desired. We should get away from applications that think they own the entire website and won't play nice with your forum or blog or gallery application. An example would be a cart status page module (with leads to checkout) that could be plugged into your standard page header. Even if you were over in the forum, you could still see your cart with a reminder that you have stuff in it. If you logged out while in the forum, the Cart would remind you that you're about to lose your shopping trip -- do you really want to log out? That sort of thing. With the right framework, other parties could provide forums, blogs, galleries, and whatnot that just plug right in, and you can bounce between applications on the same sign-in and session.

One of my biggest gripes with osC is that a product is dead and buried if it doesn't have at least an annual major release -- and osC can go many years between releases, necessitating a reintroduction to the ecommerce community! The new ownership of this osC follow-on will need to commit to frequent releases so that the world sees it as alive.

Don't fall into the OpenCart trap, where almost everything has a price tag (and some authors get really wound up over people not wanting to buy their code), which discourages people from getting on board. I would have no problem with a free basic system, with payment for more deluxe or capable content. If someone wants to offer free code, great, so long as they don't steal code copyrighted by someone who is trying to make a living selling it. If someone wants to sell a deluxe version of something, great, so long as they aren't stealing someone else's code given to the community.

I may or may not be able to contribute much in the way of code, but am willing to discuss architecture, and am willing to write documentation once others have provided the information. I think this is an opportunity to make something that's not just another "me too" shopping cart application.

  • Like 4

Share this post


Link to post
Share on other sites

We should be thinking of structuring it in such a way that it plays well with others. If it's more model-driven then integrating other applications (stock, accounting etc) is much more straightforward. Orders and products, even customers, have lifecycles with key points where you might want external things to happen. A built-in (or framework based) REST server (or is that old hat already?).

A wordpress plugin that installs it into a subfolder on a wp site and lets you embed stuff via the visual editor would offer a chance of infiltrating a huge market. Clearly not part of the development but made easier by the above.

I think that the app/plugin/... marketplace should have both free and paid offerings, the latter being a way to keep raising a little money on an ongoing basis. Free plugins with an option to upgrade for more functionality work well. The plugin search and download should be built in, like for wordpress. Some indication of popularity (# downloads) and feedback (star rating, comments).

eg a free database backup plugin could back up to your server at the allotted times (database, files, both). A paid one might do something fancy like stick it in a cloud, email it somewhere, run some db maintenance etc. No need for any of that to be core (lots of shared hosting backs up your database daily without even asking).

Has anyone mentioned themes? Free and paid, visual themes for starter layouts, functional themes for types of store. Installed with one click. All the settings on one page.

Absolutely no FTP, SQL or any other nonsense required for stuff whether it's in the main distribution, the marketplace or outside. Upload a zip available in admin for stuff you find outside the distro.

Core features like a pseudo cron and both admin and catalog ajax handlers. Likely more like this.

All this in the vision from the word go, even if they're a release or two from getting off the whiteboard.

  • Like 2

Share this post


Link to post
Share on other sites

About 'I would like found in NewCom':
Well, I see that there are a few 'commons' desires and a lot of 'dipherent' desires. I think that we must get the common and take as a priority (database import, templates, marketplace, pluggins 'as world press' doing, minimize that shopowner put their 'little nervous hands' into core files -config, languages-, etc).

With code we will use for starting point?:
- Start from 0 = I hope none think in it. Even if we use a framework to help development, right?
- 2.3.4-Edge = With not agile coging but with a lot of contributions that made life easy (I think that is as Windows 10, at first none uses it, but at last...).
- 2..4- = I'm agree with Burt, may be is a steep forward but if he breaks contributions compatibility and there are some zones that are not 100% complete, may be it need a lot of work.
- 3.0 = Yes, the more 'updated' architecture but also whitout contributions.

My choice should be the Edge because almost all we are there 'know' how it works. In my case the 2.4. and 3.0 are a little unknown for me, I will need to learn to try help / make suggestions. If this (my) issue is 'general' - lack of knowledge- , so there will get less people to coding.

I don't know if it should be a good idea to make a 'online live trainings' where some guru may talk to the rest of the mortals about the 3.0 or 2.4 architecture. I'm not this guru but I can help in the post-editition to make 'instructional videos' available in the NewCom, subtitles (in Spanish) or helping in the creation of the powerpoint that should be interesting for a posterior documentation that everybody can consult.

For example:
- Architecture: General overview
- How Files / directories are involved (in general)
- How actions works
- How handle/work with modules, languages files, options, subtotals, etc.
- Talk about the classes, functions more importants in the system
- Recommended reading (about architecture, coding, etc)

I don't care the version (if any) we will choose for a starting point but AS IMPORTANT than this choice is to think if the 'commons desires' will be in a 'near' future soon or not. I know that depends where we star and where we want to be in the next (realistic) steep. I hope if the desires never will become facts, so we will repeat the same history...

Of course depends of the 'general feeling' (if we can be patient or not) and OF COURSE the people involved... I know.

Share this post


Link to post
Share on other sites

Love reading ideas... 

I can only give a shopowners perspective - so ultimately don’t give a rats ass about the framework or architecture. 

My perspective would be build it backwards: so it’s “capable” of being the “ultimate” store... with tens of thousands of products and any (what we would call addons now) app that you could possibly imagine.... and probably/hopefully some apps that currently are impossible.

These apps don’t have to be included, or free. In fact, as mentioned above - maybe some more simple apps would be free while (understandably) more complex, proprietary ones would not.

So - Is now the time to build a system where incrediblely complicated apps can be installed, run and updated independent of the core? 

My vote is yes. And while we’re at it fix some of the issues built in from the beginning - like the tax calculation.

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, MrPhil said:

Speaking of modular structure, I think it would be great to have a Cart provided as a module library that are to be plugged into an application framework.

reading through the documentation, the osC website appears to be an extension (and part of) osC 3.0

https://github.com/haraldpdl/oscommerce_website

Quote

This repository contains the development of the new osCommerce website powered by the osCommerce Online Merchant v3.0 framework.

 

Share this post


Link to post
Share on other sites

'Backward compatibility' with existing add-ons allows us to hit the floor running with a large library of add-ons.

BUT, it also holds us back!

IMHO, I would prefer to learn from the past, but don't let it hold us from moving forward. The goal is to build something that fixes the shortcomings in what exists now, and can grow to meet future needs. Even if that means an entirely new app store, and for that matter, an entirely new app concept. Make the core lean, and design it from the start to utilize apps, themes, etc.

Share this post


Link to post
Share on other sites

and speaking about add-ons ....

Develop a SDK for add-ons. Make the tools available for people (developers or store owners) to write the apps they need in the proper way.

Also, maybe look at the top 25 add-ons (I know, no-one is going to agree which ones those are ...). Are they upload, install, and configure? Great! If not, what core changes are needed, and why? I'm not saying to add hooks into the core for individual add-ons, but look at what it currently takes to add functionality, and anticipate that need when designing the core.

  • Like 1

Share this post


Link to post
Share on other sites

Another area to consider is in Admin, either including a built-in report builder, or having simple instructions on how to use a 3rd party report builder. As a store owner, what want in a report is probably going to be different than another store. I have QuickBooks, and am constantly frustrated at the built-in reports!

Make a place in the (future) app center where store owners can share their reports. Helps to build the community :classic_cool:

Share this post


Link to post
Share on other sites

Also agreed. I would like reports on products sold over time by manufacturer, or category, or price but I've always found it a bit daunting to write them.

Share this post


Link to post
Share on other sites

I am not code-savvy enough to say which framework to use for this new venture but I say it here again as I said in the other forum already the base shop should be as light as possible and additional features should be added via one-click (if possible) apps. There are things I would like to see improved though like;

Catalog side:

- Modern and fresh looking shop front face (responsive)
- Lot better sample products

Admin side:

- Better looking admin interface (responsive)
- Better categories and products handling. (multi -> copy, edit, link and status settings like hide or deactivate, select all checkbox(es)? )
- Better product registration interface (with more features for images, and additional extra fields if needed, block to add product options)
- Better customer handling interface. (create new customers manually, merge accounts)
- Better order handling interface. (edit orders!, manually create orders, batch print shipping labels and invoices)
- Better sales reports (just look at some of the opensource admin interfaces)
- Better product attributes! (AJAX! no more page loading after each click, more types of options and not only drop downs, stock and weight control)

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

"no" is a good answer. My opinion would be this is probably not the stage to address any specific requirements. A robust rat-ass* framework should easily address any future requirements. The Magento's V2 framework gives a great example for this. *Note: my definition of rat-ass framework = framework agnoastic, non-bias on any framework, of course this is not up to me  🙂

I am not sure of 3.0's timeline nor its framework, I could imagine it was caught with its MVC pants down--to go on or to a complete rewrite that's meant for couple man-year.

I did not know that Cat tree class was from 3.0. Yes, it was a good piece of codes, and it was extended to have categories status and other menu functionalities for my BS store. I could easily had roll that out as an app had 2.4 App MP been released.

I don't know, but Magento V2's factory pattern, dependency injection, and object CRUD model are pretty awesome to work with, too. I just hate their XML layout and template systems. Our front-end guy hates them too.

 

16 hours ago, burt said:

The short answer is "no". 
2.4 is an "on the fence" release designed to pacify those people who want a forward movement from the official osc, whilst also pacifying those who want to stay "close" to how 2.3 works.

The longer answer:
3.0 (which was in its time, absolutely the most brilliant piece of code I had ever seen) was unreleased. 
I won't say why it was unreleased but it was a personal choice of HPDL to nuke it.  Prestashop (which is now well regarded, has, at its core, that 3.0 code).

So, 2.4, with some backports from that older 3.0 - would be a hammer.  Backports such as products class, attribute variants, and so on.  

I'm not sure how many look at the CE (the community bootstrap code)...in that there is a cool Category_Tree class - this comes from v3. 
There is so much fantastic code in V3...osC could have been #1 cart easily, and I mean it would have hammered the other carts brutally.

 

 

Edited by clustersolutions

Share this post


Link to post
Share on other sites
16 hours ago, frankl said:

reading through the documentation, the osC website appears to be an extension (and part of) osC 3.0

https://github.com/haraldpdl/oscommerce_website

 

Reading through that GitHub entry, I'm not quite sure how HPDL intended to integrate v3.0 with other stuff. How much of that is actively running today? Is the osC forum actually integrated with an osC apps store, or is there an umbrella or shell over a discrete set of applications? What I have in mind is an application-agnostic framework that handles login, session, permissions, theme, and provides commonly-needed utilities. Then, an application (such as the new Cart) provides a library of modules to plug in to the framework. One would be to manage the shopping cart, which connects to checkout. Another would be catalog search and display (as well as sales, clearance, new, featured, etc.), where you could instead choose to have your own hard coded product or service pages with a "buy now" or "add to cart" call to a Cart shopping cart module (the same call as used in a catalog page). That is, you would not have to use the provided catalog pages, database entries, etc. but can roll your own (such as needing very different pages for different categories of things, or offering just a few items). The Admin side (however separated that is) might largely be a DB view of your store POS product database, rather than using the provided admin functions. Mix and match type of thing. As shipped, the Cart would provide a basic store-only framework, which you can use to get going quickly, or you could plug in the various pieces to a more elaborate framework that will eventually drive a separately-offered forum, blog, gallery, etc. I think that ecommerce is far more complicated than any of the other applications, so something that works for ecommerce should make forums, etc. easy. Note that things like product reviews and feedback could share a lot of code with a forum or blog application. Pages in any application could be hard coded PHP like osC currently is, or could be more of a CMS-style of page content (preferably PHP + HTML, not just HTML like most CMS's) being in a database. A given site might have a mixture of the two styles.

Anyway, that's the dream. It may be too much for an initial release of the new Cart, but we should consider architecting the system so that it could become reality some day.

  • Like 1

Share this post


Link to post
Share on other sites

The 3.0 you see on Github is not the 3.0 that was almost released years back.  It's certainly similar...
The existing 3.0 also has a website, as well as the apps marketplace and live shops gallery built in (if I recall correctly).

The 3.0 from years back...was beautiful.   Such a wasted opportunity there.

Share this post


Link to post
Share on other sites

A solid framework may be build from the ground by us or use one that has a lot of people developing / using / creating documentation / updating it from time to time.

Option 1 may be done with people that have solid knowledge about architecture, DDD, etc, etc, etc. to create only the framework. Late it must be propertly documented to be easy understandable to create the 'modules' of this core.

Option 2 have 2 suboptions:

2.a Or we use something like Laravel or symphony (with good documentation, places to ask/consult, bla, bla bla)
2.b Or we use OsCom 3.0 with almost NO documentation where almost all of us need learn from 0 reading the code if we need to know to add / create / change everithing. Of course newbies as me in 3.0 may waiting how github is goin on to help understanding.

Examples of 2.a (simple cart created in less 10 hours):

Laravel Shopping Cart               (laravel)

Build a Shopping Cart with PHP (symphony)

Of course there are a third option... to use a code that are NOT VMC, whit a lot of extra contributions from developers and users, multilanguage, multicurrency, etc.

No, I'm NOT talking about Woocommerce but our lovely EDGE.

If you try to understand how wordpress works, you can see A LOT of code that are clearly procedural, mixed with some class files there, a REST API there. The magik of wordpress is that they try to avoid breaking compatibility in every new release (the one that OsCom does NOT). Of course that you cant' run a 1.0 ver with a new pluggin, but you can find functions or code labeled as 'depeprecated in next versión' but active in the file. You can add PHP code in a widget, editing the functions.php file or making a pluging (with 3 lines of code you can add a form field in a page!).

This option (worpress way of coding), I know, has less risk because don't break (again) the compatibility. You code is inteded to ADD functionality and/or make clean code for next versión. The price is that the code is NOT modern, clean and well structurated. Maybe is why wordpress is so popular...:classic_rolleyes:

You can create a 'product' class that may be used in core of nex versión but it can be designed to let old code to work. A proper documentation may help people to use it and update the old files.

An example:

$products_query = "select p.products_id, pd.products_name .... from products p.... where p.products_id = ' . $pID . '"';

A string that must be converted in an array with fields, tables, conditions, pagination.

$products_query = tep_db_query ($products_query);

later check if there are rows, then the  while....

How many times we need the info of the product (may be including price) in osCom? Only 1 ?!? Not. So why no create, at least, as first steep create a function that return an array / object  to be used.

The resulting array may be added / edited or inside the function or in the page by a hook.

In my limited knoledge osCom need:

- Change procedural queries with the use of arrays / objects to be easy modified by hooks / actions.
- Objects that can be maped in an template wia variables. So we can separate php to html (js)
- After that, CAREFULLY create a series of places (hooks) where 'add/edit' content/funcionalities (as modules does in this moment) as wordpress does to avoid edit core.
- Create new classes (including changin naming/dir where will be conventions if necessary): Product, attributes, etc. and create new functions (used in template catalog/admin) a kind of revitalized html_ouput.php that creates not only the input but the label, icon, insert outline div or span, etc (as wordpress does).
- Later creating interfaces for avoid duplicate code in modules, etc.
- A class for editing languages (agnostic). If you want use defines, ok. No I want .ini, don't worry. Why not database languages? Of course, why not...
- A class that handles updates wia .zip files downloaded in a first stage in a 'regular' marketplate (later via our faboulus marketplace the Nuveau will be able to conect with the web and click and download and continuing dreaming).

Don't worry, the options has their advantages or disavantages. I think that we must consider how many steeps want to run until new improvements of 'our code'.

We are talking not only about lines of code we need write, but also the time we will be allow to wait for a new 'son'.
 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×