Jump to content
Kuuzu Forum
frankl

What the software should be

Recommended Posts

54 minutes ago, Antonio García said:

lovely EDGE

You must get away from the idea of using Edge as a base. 

It was made solely to keep osCommerce alive, and that, looking back, was a mistake on my part.

Edge is not the way forward.

Share this post


Link to post
Share on other sites
4 minutes ago, burt said:

Edge is not the way forward

ok. I know that the osCom 3.0 is your option (a good one, I know).

How many people need you to ReCommerce, ejem, recommence the 3.0 code?

Mow many people here are familiar with 3.0?

Who knows where 3.0 is faulty (it's a beta or alpha) or incomplete or buggy?

3.0 is a good horse, but it needs care, time, patience & of course a motivation.

As I see, the 'motivation' then IS NOT attract users from 2.3 series (even some of 2.2) because we will talk in almost another 'dipherent language' that they don't understand. No audience there waiting your(our) new proposition.

We will create a piece of code that must be there, alone, naked, young, nudging us with hooligans like woo, open, big, shopi, presta....

Well, this option also has their challenges that we will need to accept...

Share this post


Link to post
Share on other sites

3.0 is an option.  It is not my particular favoured option.  I go with whatever Frank says, this is his party; I'm just here to stand in the kitchen listening to 80s music and drinking cider.

 

What I can tell you, as I think I probably know Edge better than anyone... it is held together with string and duct tape, and if we pile any more code onto it...it is likely to fall apart.  I cannot tell you how hard it has been to want to move forward with it, but having my hands tied so I can't.

Edge is doing a job for a number of shopowners, but...for the future...it is best forgotten about.

  • Like 1
  • Haha 3

Share this post


Link to post
Share on other sites

Any version of 2.3 is best left behind.

It's a workhorse that has carried the burden for a long time and is now worn out, tired and old; and while not deserving of a trip to the knackery, it can live out its days in a pasture somewhere until it finally fades away and dies.

One thing I'm looking forward to is not seeing messages which begin with "I'm still running osC 2.2 and I..."

  • Like 2

Share this post


Link to post
Share on other sites
49 minutes ago, burt said:

Edge is doing a job for a number of shopowners, but...for the future...it is best forgotten about.

Yes, I may agree with you. I only try to put all the advangages / disadvantages of each of the options I can imagine. By the way, today I listened King Crimson's 'Frame by Frame' :classic_tongue:

46 minutes ago, frankl said:

One thing I'm looking forward to is not seeing messages which begin with "I'm still running osC 2.2 and I..." 

If we use 2.4 (sorry for not put it in the available options) also no one from 2.3 will ask for nothing, right? or in the hipothetical roadmap are you thinking that will be a kind of portability / update from 2.3 -> 2.4 ?

I saw that both of you need fresh air.

We are here for try help, if needed, if can, in this NEW era.

Share this post


Link to post
Share on other sites

@Antonio García I see where you're coming from but I don't think a little step from Edge is where we need to go next. People complain often that they have put so much effort into making their store how they want that they can't face doing it all again on another version or even remember what was done. We can only achieve that by starting somewhere else. We need to make it as easy as possible to move an existing store design into the new thing but that's a set of tools for the near future, it shouldn't be a determinant of the architecture from the start.

If people can readily migrate their data, can make a pretty design simply and easily find and install code widgets that make it do what they want they will be happier to move into it than if it's closer to their current platform but harder to achieve. Oh and cheap.

Between us we know osc inside out, we'll know the new thing too and we can make it a painless transition however big it is. Let's not get hung up on verson numbers or close to the old one it will be.

  • Like 3

Share this post


Link to post
Share on other sites
1 minute ago, BrockleyJohn said:

If people can readily migrate their data

 

3 minutes ago, BrockleyJohn said:

We need to make it as easy as possible to move an existing store design into the new thing

So, I agree with you, I vote for add into the roadmap to make an update tool for people from OldCom to the NewCom. I would like take care of 'ours' potentials future users, mainly (I hope) from osCom universe. I Only beg take care of shopowners that uses osCom. We need seduce them at least in a first stage.

"Easy" and a software that must complain the Domain-Driven Design paradigm is not 'easy', nor 'fast'.

I only try to note that we must be aware of it.

Share this post


Link to post
Share on other sites

We need migration software not just from old osC but also Magento, Shopify, PrestaShop, etc, etc.

That's a daunting task, but I do think it needs to be a part of the project at some stage. Make it easy to convert and the user base will bulid up quickly.

It's a conversation for further down the track though.

  • Like 4

Share this post


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

We need migration software not just from old osC but also Magento, Shopify, PrestaShop, etc, etc.

+ 1 vote (at least osC, later in future steps the rest...) :classic_smile:

Share this post


Link to post
Share on other sites

Before we get too far into deciding all of the detailed software features, we need to decide where we start. From the discussions here, these seem to be the options:

  1. osC 2.3.4.1 Bootstrap.
  2. osC 2.4.
  3. osC 3.0alpha5. I think that's this one. Gary can say for sure.
  4. The current osC 3.0.2 framework.
  5. Some other framework.
  6. Start coding from scratch.

All of these will take work to make them usable, some more than others. How do we decide this?

Regards

Jim

Share this post


Link to post
Share on other sites
Posted (edited)

There u go, name this the Rocking80scommerce.com. I am all for it! LOL!

Just checkout 3.0's github, it was definitely nicely written. It was also written around 2011, I would think there will be some catching up to do.

V3 could be a nice start, because it will maintain OSC's heritage. I don't think Kymation's option 1 or 2 are good choice, too.

I bet a lot at the end will be depended on the dev team's capability, and writing your own could be a longer road. From my time spent on Magento I believe it was originally based on the Zend framework, but if you look at V2, you will see it also had adapted Symphony. So may be it isn't that important in what you choose now. Modern software are build to be robust, a part of the open source movement was to share and reuse and reduce redundant efforts. Having said that, not all frameworks are the same, some are more rigid and not great in facilitating resource sharing between apps.

Question: have anyone thought about what to do with the DB schema? Hold it fixed at 2.2/2.3 for the ease of migration and all changes will be put into new tables (also apps are not to be modifying core tables and should have its own)? That's what I had in my mind before as I saw there will be the need to have a config_mgmt table.

Oh, I have a thought that this software should be forward looking more instead of looking at old shops that r still using 2.2. I mean it should allow them to migrate easily, but I can't imagine there are many bu$ine$$ powerhouse in that group. Also, this software should also provide turn-key solutions, in a sense that it should be more than just a shopping cart (it should have ERP, CRM, BI, and etc. functionalities).

 

4 hours ago, burt said:

3.0 is an option.  It is not my particular favoured option.  I go with whatever Frank says, this is his party; I'm just here to stand in the kitchen listening to 80s music and drinking cider.

 

2 hours ago, Kymation said:

Before we get too far into deciding all of the detailed software features, we need to decide where we start. From the discussions here, these seem to be the options:

  1. osC 2.3.4.1 Bootstrap.
  2. osC 2.4.
  3. osC 3.0alpha5. I think that's this one. Gary can say for sure.
  4. The current osC 3.0.2 framework.
  5. Some other framework.
  6. Start coding from scratch.

All of these will take work to make them usable, some more than others. How do we decide this?

Regards

Jim

 

Edited by clustersolutions
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

So, for shits a giggles I decided I would go remind myself about v3. 

Long story short the public github hasn’t been touched in 5 years - a life time in the ecom world. And reading through some the posts in the v3 forum - it reads as the roadmap of OsC to failure. 

Back in 2009, just around the time I started hanging around here, there was a tremendous amount of interest from users wanting install v3 - but it would seem not much forward momentum in the code (getting to a stable release). It would seem the community was left in the dark.

BUT, I can’t imagine it would be easier to start from scratch...

Smarter people than I will answer this question (but it needs to be asked for us non-coders to understand the path forward) - is the risk of starting with an already out dated (3.0.5a) framework outweighed by the amount of work to start fresh (or maybe I really don’t understand how things like this are built and nothing is really started “fresh”)?

Edited by Greasemonkey
Typo
  • Like 1

Share this post


Link to post
Share on other sites

Just installed v3 from github. Never did before. Database tables are mostly the same as v2.

Just wondering if the orders admin page just wasn't still there or I'm missing something...

 

 

Share this post


Link to post
Share on other sites
15 hours ago, BrockleyJohn said:

People complain often that they have put so much effort into making their store how they want that they can't face doing it all again on another version or even remember what was done.

I can sympathize with that, but inertia is poisonous. First of all, they screwed up if they did not keep good records of what changes they made (anything that's not pure vanilla out-of-the-box release). Not just what they did, but also why they did it. Sometimes a new version comes with something built-in, and an old add-on or tweak can be dropped or done much more easily. That's why you must record why you did something. We can help by clearly documenting such things and how to move from the Old Way to the New Way. I know it's tempting to iteratively twiddle and tweak files until it looks "just right", but you'd better write down what you did and put it in a safe place, before you forget.

Sure, making a fresh start can be daunting -- who enjoys looking at a blank sheet of paper when you have to write an essay and the clock is ticking? What we can do is make configuration and getting everything "just right" a simple task for shop owners. Some people prefer WYSIWYG, and others like text configuration files (.ini, etc.), and still others appreciate a Wizard to lead them around, and in an ideal world you have all available. You might use a Wizard to do the initial work, then WYSIWYG to tune feature selection and layout (once you know what's there and what you can do with the system), and finally edit .ini files to get the last little changes in. Data (database and images) should have an easy, mechanical one-button transfer process. What programmers and hobbyists keep forgetting is that most of the people using this system will be business people -- mom & pop store owners for the most part -- who have no interest in learning a complex system... they just want an appliance to help them sell, and to take as little time and effort on their part as they can.

  • Like 1

Share this post


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

I can sympathize with that, but inertia is poisonous. First of all, they screwed up if they did not keep good records of what changes they made (anything that's not pure vanilla out-of-the-box release). Not just what they did, but also why they did it. Sometimes a new version comes with something built-in, and an old add-on or tweak can be dropped or done much more easily. That's why you must record why you did something. We can help by clearly documenting such things and how to move from the Old Way to the New Way. I know it's tempting to iteratively twiddle and tweak files until it looks "just right", but you'd better write down what you did and put it in a safe place, before you forget.

Sure, making a fresh start can be daunting -- who enjoys looking at a blank sheet of paper when you have to write an essay and the clock is ticking? What we can do is make configuration and getting everything "just right" a simple task for shop owners. Some people prefer WYSIWYG, and others like text configuration files (.ini, etc.), and still others appreciate a Wizard to lead them around, and in an ideal world you have all available. You might use a Wizard to do the initial work, then WYSIWYG to tune feature selection and layout (once you know what's there and what you can do with the system), and finally edit .ini files to get the last little changes in. Data (database and images) should have an easy, mechanical one-button transfer process. What programmers and hobbyists keep forgetting is that most of the people using this system will be business people -- mom & pop store owners for the most part -- who have no interest in learning a complex system... they just want an appliance to help them sell, and to take as little time and effort on their part as they can.

I agree with this one hundred percent.... as shopowner.... the hardest part was moving from 2.2 to 2.3.

For less inclined shopowners it was the same amount of work to move from 2.2 or 2.3 to a new platform than continue to with OsC. And the other platforms have made "staying" SOOO much easier.

  • Like 1

Share this post


Link to post
Share on other sites

Either way, starting from fresh slate or using a already made base...I want to make sure that everyone realises this is going to be loads of hard work.

I poured *hundreds* of hours into Edge.  It might not look like it at first glance, but what you see in the code is the tip of the iceberg.  Don't see all the coding, testing, tweaking, sending things out to be tested more, getting feedback, recoding, retesting etc.  Multiply that by almost every change made and you can see time adds up...

Be certain that you want to be involved, as it's going to be a time sink, and I know that it'll take a lot of hands on deck to get anywhere...

  • Like 1

Share this post


Link to post
Share on other sites

No joke, or I would had started it on my own way back. We re gonna have to address the architecture side, put some effort into understanding V3 and 2.4, B.S we already hv the expert here, pick/combine them into a framework and start laying down the foundation and hack away. And when that's ready, the frontend, backend, DB, apps (I like to call shop owners the app steering committee) and etc can all dive in.

I think we should take away a little from all the versions of OSC, there was a reason that Harold had dropped V3, but had picked a few things and put them into 2.4. Let's go figure that out...I pick up codes from previous developers daily and they rarely hv good doc. I always try to put myself into that person's position and try to figure what was it that he/she was trying to do and start reverse engineer things or hack away that way...

May be we'll just have to adopt the Magento framework...haha...it's opensource and it works...

All right, let's go for it and have another thread started on that whenever whoever is ready.

 

Share this post


Link to post
Share on other sites
19 hours ago, burt said:

I want to make sure that everyone realises this is going to be loads of hard work.

Agree... and a lot of work making a decent web (& template) where tell people to see how we are going (github button) and asking people for enroll on 'this' (another big button) where they will be redirected to another page where they  can find the places where they  can/want to help (coding, templating, testing, bug, documentation, ideas, etc). That web should be based in 'OUR thing', so one of the first modules to develop should be a kind of blog / news or whatever is named).
Yes, our 'NuevauThing' is mainly a shop. That kind of products we may sell? Well, we will may 'sell' our 'ThingThinkNewCart' (free),  our second comunity template, and may be a kind of merchandaising to pay the cost t-shirt with our logo (a good place to test our new brillant attr. system), a mug, a key chain and also a kind of 'discount coupont' that the user can use in their first order when they buy a (paid) module designed for everyone - or official or made by raiwa, for example...

When the point of start will be decided, yes, a lot of work. I think that we will need a kind of paralell working groups (coding new update core - with bug group, templating (I would like to help here), a few creating the doc (the first, a 'developer' handbook where find a easy way what we tell what going on with code principles and describing - in an humanable way - the code, from the general to the more detailed <= Here I would like to contribute also...)  & a few shopowners testing  & asking /telling improvements).

By the way, the docs may be laid into github (yesterday I read how doing it).

image.png.8058bfdd328152703194cf75ed7b6ee2.png

Share this post


Link to post
Share on other sites

From a old post from OldCom takling about ver.3:

https://forums.oscommerce.com/topic/375773-so-what-happend-to-oscom-3/

"From April we are going to:

 Be active in the community to help developers understand the framework and store owners its user features

Update remaining Applications and Modules that were not finalized for the v3.0 release

Provide a database import tool for existing v2.2RC2, v2.3.1 and v3.0A5 users

Start a localization site for translators to use and build language translation packages

Document v3.0 framework and user features

Finalize MS SQL Server database abstraction queries

Extend the CoreUpdate Application to also support installed Add-Ons

Allow Phar packaged Add-Ons to be tested without the need to install them first

Continually improve existing features and introduce exciting new features"

 

... in orange the ones listed yet in this tread... the others so important that the orange ones, of course...

May be this can help in the 'making of a road map'

 

Share this post


Link to post
Share on other sites
On 5/1/2018 at 1:16 AM, ArtcoInc said:

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:

From my point of view as a store owner the first report I would like to see is stock costs. Its as simple as a small database change and adding a box where the selling cost is added in the admin area.

From this one figure you could have all the standard stock cost, profit, margins,  and god knows what else, but it all starts with product cost, which most carts never add. It would be easy to see what you are paying for an item before you add it as a special. The list could go on. Having something simple like this in the core as standard opens up a whole field of apps or addons that can be sold or given away free by developers, but should never need to be altered again in the core code.

Share this post


Link to post
Share on other sites

With everyone currently volunteering for different language translations, is there any way to make the core software so its easy to change the basics of the store like address format and layout and date formats, and what ever else may be changed, to suit individual countries. Years ago there was an addon in osc that would turn the standard osc core code to suit UK stores. I dont know whether anything like this has been considered, but it may be a selling point that with a few changes the stores could comply with different countries styles and legislation. <maybe make it so it can be included in the different language packs.

Share this post


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

I dont know whether

me neither.

If we chose osC 2.4, the languages are 'pure text' => WHEN_I_SAY_NO_I_SAYS_NO = 'No'     (I think they are .txt files instead php defines).

The local way to write an address, place for symbol in currency, etc I think that will be in php code...

May be it should be a good idea is the 'Translation Army' can be also help in the 'zones' thing (If they can help, of course).

Share this post


Link to post
Share on other sites

May be its time to move away from what is considered the norm then and do something different.

There is nothing saying language packs/translations cant include the files required to change everything to country specific layouts is there. It would make it so easier for store owners and i thought that is who the software is aimed at or nay be i am wrong in that assumption. Those packs could then also include code to make sites country legal.

Share this post


Link to post
Share on other sites

@14Steve14 About languages and localization - there's much work to do.

Localizing a shop for a single country is not difficult at all - the hardest part is making a site multi-country, multi-language.

By default, in current oscommerce you don't have a localized configuration, you don't have a localized install routine, you don't have a way to automate localized emails, you can't choose the countries you sell to or translate their names, managing language changes is terribly boring... and many other flaws.

But, most important of all (at least for a company that sells to several countries with different languages): Every page has the same URI regardless of the language you choose. That means that spiders can't indent localized versions of the site - and be sure that's terrible for a multilingual shop! We can not take advantage of SEO in oscommerce because of that. An URL rewriter is needed for that. AFAIK the only one that does it for old oscommerce is seo URLs 5 - and its language support is incomplete and not mantained. It's a must for core.

If kuuzu wants to be an international sofware all language issues must be solved by core.

 

  • Like 2

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

×