Help Rebuild OsCommerce
Moderator: General Moderators
i think all contributors should register with the wiki to make tracking changes easier (at least it does for me (: ).
somehow i am in a cleaning mood and so i would propose to move all coding related stuff into its own sub hierachy (like requirements).
any comments?
cheers
Christian
(chra at the wiki)
somehow i am in a cleaning mood and so i would propose to move all coding related stuff into its own sub hierachy (like requirements).
any comments?
cheers
Christian
(chra at the wiki)
I think most of us are, but the wiki forgets who you are between sessions even if you check the "Remember Me" option. I added a few things earlier without realising so they went in anonymously.sike wrote:i think all contributors should register with the wiki to make tracking changes easier (at least it does for me (: ).
Add it to your sig: http://www.astions.com/projects/wiki/
Added. If anyone has any clues about the wiki not remembering you let me know. For some reason it is remembering me even if I close the browser and reopen it. It may only remember people for a certain amount of time. I looked through the configuration file but I don't see anything in there that allows you to change it.
Some sections which need more discussion / rewriting:
http://www.astions.com/projects/wiki/in ... Processing
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
P.S
About the "Visual Cart" module:
Someone wrote "I will explain this later... just an idea I have" - so now explain yourself this is the time to that.
http://www.astions.com/projects/wiki/in ... Processing
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
http://www.astions.com/projects/wiki/in ... ction=edit
P.S
About the "Visual Cart" module:
Someone wrote "I will explain this later... just an idea I have" - so now explain yourself this is the time to that.
I would suggest that a single payment option be bundled with a default install, this being payment via check (cheque for us aussies) / money order.
It's one of the only payment options that are really usable out of the box anyhow. That and/or direct deposit. I've done many osc installs and it's really frustrating that it comes with all these payment and shipping modules that you must turn off and then replace with more relevant modules.
There are of course allowances that must be made for future modules to function, especially payment modules, but why clutter a brilliant core application with modules which are redundant for many users.
Also, when it comes to designing the product input / storage / display sections, alot of consideration should be given to the complexity of products to be sold via the cart. Pretty much all of my installs require AT LEAST the nightmare which is the 'product attributes' function, and one case in particular required some extensive work to allow single click addition of multiple instances of a specific item(pastels in this case) from a range of up to 6 shades per color with over 30 different colors available.
This last is an extreme case obviously, but I really think it would pay to consider the different products that the system may be used to sell. At the minimum I would hope to see the ability to give basic options such as color or type per product. Even better would be to alow child products and / or alternate product versions, all with or without the ability to provide images or in the case of colors, even an html color swatch.
It's early days I know, and it doesnt pay to dwell on these complexities now, but still, I thought it would be good to put the ideas out there for consideration.
Actually, I'd really ove to help out with code and the like, but yeah ... with the caliber of some of the code contributors, I fear I would be more or a liability than an asset.
Cheers guys and good luck. If there is anything that needs a complete overhaul, osc is it.
It's one of the only payment options that are really usable out of the box anyhow. That and/or direct deposit. I've done many osc installs and it's really frustrating that it comes with all these payment and shipping modules that you must turn off and then replace with more relevant modules.
There are of course allowances that must be made for future modules to function, especially payment modules, but why clutter a brilliant core application with modules which are redundant for many users.
Also, when it comes to designing the product input / storage / display sections, alot of consideration should be given to the complexity of products to be sold via the cart. Pretty much all of my installs require AT LEAST the nightmare which is the 'product attributes' function, and one case in particular required some extensive work to allow single click addition of multiple instances of a specific item(pastels in this case) from a range of up to 6 shades per color with over 30 different colors available.
This last is an extreme case obviously, but I really think it would pay to consider the different products that the system may be used to sell. At the minimum I would hope to see the ability to give basic options such as color or type per product. Even better would be to alow child products and / or alternate product versions, all with or without the ability to provide images or in the case of colors, even an html color swatch.
It's early days I know, and it doesnt pay to dwell on these complexities now, but still, I thought it would be good to put the ideas out there for consideration.
Actually, I'd really ove to help out with code and the like, but yeah ... with the caliber of some of the code contributors, I fear I would be more or a liability than an asset.
Cheers guys and good luck. If there is anything that needs a complete overhaul, osc is it.
We have discussed using an SKU number as the product ID, so adding multiple variants of the same product won't be an issue. (The SKU is unique for each product and variant)
However, grouping products (with drop downs or checkboxes or radio's for variants) seems a plausible route to take. It won't be difficult to get the group functionality, and neither should being able to create/ammend groups and add them into the catalog. Perhaps even separate it to a module.
However, grouping products (with drop downs or checkboxes or radio's for variants) seems a plausible route to take. It won't be difficult to get the group functionality, and neither should being able to create/ammend groups and add them into the catalog. Perhaps even separate it to a module.
In my opinion all products should have seperate SKUs. A red T-Shirt should have a different SKU to a green T-shirt. There should be a table (or multiple tables) to define how they relate to one another, but they should definitely be seperate products in the database.Jenk wrote:We have discussed using an SKU number as the product ID, so adding multiple variants of the same product won't be an issue. (The SKU is unique for each product and variant)
However, grouping products (with drop downs or checkboxes or radio's for variants) seems a plausible route to take. It won't be difficult to get the group functionality, and neither should being able to create/ammend groups and add them into the catalog. Perhaps even separate it to a module.
But I'm not designing this, so it's not up to me.