There are many different answers to satisfy different online store needs.
A lot of the example I see don’t take into consideration **inventory and images ** and treat styles and sizes as attribute like tags and try to be flexible. This seems wrong to me. My Product that hasMany styles/color that hasMany Sizes.
Here is how i want to layout it out
Product
id | name | price
1 | shirt | 10.00
^ Styles < Images
id product_id name id styles_id filename
1 1 red 1 1 image.jpg
2 1 blue
^ Size
id sku styles_id name inventory
1 n1 1 m 50
2 n2 1 l 50
I don’t see many examples of this but this is what makes sense most to me. Am i totally wrong and bad to do it this way? With styles having its own table I can use a FK with images to load different looks of each style
I know one flaw is that what if I have a product that has only one style and one size. Like a winter coat. Then I to use extra tables. Visually with PHP I will just make it all one form. Will I run into an issue when i start working on cart and orders?
Note: I am using CakePHP
Response to the parent child method
Yes I have seen that before, Wouldn't you have repeated fields or empty fields, for example your table would look like this
id role color size inventory price name
1 parent - - - - artShirt
2 child red m 20 50.00 -
3 child red l 20 50.00 -
4 child blue s 20 50.00 -
5 child blue m 20 50.00 -
how would you link img to products that are red?
id product_id image
1 2 redImg.jpg
1 3 redImg.jpg
the concept i really like is called Parent Product - Child Products.
The Parent Product is given a sku for reference, but its not a buyable product. It represents the product, like the ArtSir Shirt. It contains a product description for ArtSir Shirt, qualities, keywords, etc.
the Child Products are the actual buyable products. the shirts. there is one record per child product with the sku, color, size, price, weight, inventory, etc. they are related to the Parent product by the parent product sku. for most merchants inventory is critical so having a db record per sku is really the only practical way to do this. (not to mention if you need distinct UPC or EAN codes)
the parent products and the child products can all be in - one simple happy db table. like a family :-) You call the parent product with its sku, then get the child products with the parent product sku.
and then when you get the child products, you have the option to filter out the ones with no inventory and not show them.
Showing product pictures on a product page for specific colors -- so this has nothing to do with the products being buyable or not. this is the presentation. the simplest (hack) is to put that information in the Parent product record. fields for Color 1, photo link, Color 2, photo link, etc
Otherwise you could have a separate db table to do this. Just try and confine its tasks to the presentation.
Always pass a product id to the cart - then the cart looks up the product price in the product table. If you pass the product price openly, then it can be easily hacked. When you look up the price you can also confirm inventory.
Suggest that there be one step before billing - where you check price and inventory again to confirm everything is correct before charging the customer.
==============
edit in response to question. you asked:
"Wouldn't you have repeated fields or empty fields, for example your table would look like this"
yes you will have empty fields. in 1985 or 1995 that was important. its not important any longer unless you are running your web site on a machine from that era.
bottom line you have to be able look up a sku and get the price and inventory. you could put arrays or data structures into a field.
but then you are having to pack and unpack them every single time you make a db call.
how would you link img to products that are red?
you can hack it by creating fields for the parent product to hold the image links, a color reference, a name, etc. color01, photolink01,color02, photolink02, etc. its a hack but it will work.
remember you are pulling all the page display information from the parent product. so this is just more display data.
you also have the option of having a photo field in the child product record. which you might need for product feeds. so then you could take the color - photo results from the child products, and use that to create the display.
otherwise make a db table for the display. and that table could also help with uploading the product photos and assigning them to the correct product.
Related
I've tried to export products + category from X magento to Y magento with this https://www.siteground.com/tutorials/magento/import-products.htm
FYI, the exported files are correct, even XML or CSV type.
But, i found error when i importing it. it says i found 84 rows, but it's only Imported 1 records, when i check the Manage Products, none of products is imported. I tried on CSV and XML files, the result are same.
The magento version of both are similar, any possibilities to debug it?
In your import process 84 records means there is 84 lines in your csv file not 84 products!
I guess you're using just one sku for all of your products and that's why you have just one imported product. It's good to know that
magento uses sku as ID to identify products, so you need to assign an unique sku to every single product.
Update:
To insert new products by CSV Import check this columns in your csv file.
Required Product Attributes for New Products (written as they should appear in the CSV file column):
sku
Stock Keeping Unit - a unique value to identify the product. No two items can share the same SKU in Pixafy.
_attribute_set
Unless you have already set up Attribute Sets, set this to "Default"
_type
What type of product is this? Your options are: simple, configurable, virtual, and downloadable. Grouped or bundle products can not be imported at this time and must be created in the Control Panel.
name
The product's name- such as "Magic Wand". This should not be longer than 60 characters
description
The long description with detailed information regarding the product.
short_description
The shorter description that appears to the right of the Product Image on the Product page
price
The amount you are charging your customers for this product before sales or discounts.
status
Is the product Enabled or Disabled? Enabled is 1, Disabled, 2
visibility
How will the customer be able to view this item?
Visible in Catalog and Search = 4
Visible in Catalog =2
Visible in Search = 3
Not visible individually = 1
tax_class_id
Tax Class ID as set up under Set Up > Tax > Product Tax Classes. By default, Taxable Goods are 2
weight
Enter a numerical value for the weight of this product. This will be used by any calculated shipping methods.
_product_websites
At this time, your only option is base
Update 2:
To learn how to add product images to your csv file, read this post:
Update Magento products with multiple images
My questions is basically I have 2 products that can be sold separately and together.
What I want to do is take these 2 individual items, create a new product in Magento for it with a new image that will show both of them together for a combined price. When this particular item is sold then it will reduce the qty from each of the individual sku's that were created. Is this possible?
As an example,
SKU 1 - Wii Remote - $30
SKU 2 - Wii Nunchuk - $15
SKU 3 - Wii Remote + Nunhcuk - $45
So when sku 3 is sold it will reduce the qty of sku 1 and 2.
Thank you
Maybe a "bundle" could help you?
http://www.magentocommerce.com/knowledge-base/entry/creating-a-bundled-product
I don't know for sure, because I have never used Magento. I just Googled your problem.
A bundle product will do if your rules are within these:
Points to Remember
A Bundle is a “build your own” product type
Bundle Items can be Simple or Virtual products, but without Custom Variants and Options
The Price View of a Bundle can be set to display a price range or “As Low as”
The SKU and Weight of a Bundle product can be set to either “Fixed” or “Dynamic”
Items can have either a preset or user-defined quantity
Items can be shipped together or separately
Bundle product data cannot be imported into your catalog.
Means : bundle product cannot have a configurable product within.
so if your SKU1 and SKU2 are not configurable or rather just simple or virtual then you can create a bundle product and sell the way you have stated.
I don't necessarily agree with the way magento wants us to sell our "Bundles"
It lets users decide which products they want to combine, it's really similar to a "Grouped product".
To me a bundle is predetermined by the store owner, If A is Bought together with B & C, then the customer saves X amount of money... It's not up to the customer to decide what's part of the bundle.
SO I ended up creating the Bundle, adding all the products I want in the bundle as a "Multiple Select", ticked them all as "Default",
and I'm hiding the options with CSS, only showing the price and the add to cart button (Every product has it's own class in ): body.product-name #product-options-wrapper { display: none }
So of course if you have thousands of bundles then this won't work for you.
I'm really happy with this solution because 1. It updates the inventory & 2. All of the SKUs are displayed on the invoice! (For me they are also lot numbers)
In a normalized database schema, the manufacturers would have their own attributes like, for example, name, description, address, phone number.
The manufacturer description is something that is useful for the product pages. Many ecommerce sites show a manufacturer description on every product page.
As far as I know, in Magento you would have to create a product attribute, "Manufacturer description" or something like that. If, for example, ABC Corporation has 1,000 products, you would have to update all 1,000 every time you changed your description for ABC Corporation.
Is that the only reasonably easy way to do it?
Or is there a more database normal way of doing it, where a single, atomic update would result in all the manufacturer's items showing an updated value on the front end?
Create a module with the following contents:
setup script that creates a manufacturer table like desired
model and resource model classes for manufacturer
grid to manage the manufacturers (this is quite complicated, you should follow a tutorial like this or copy the basics from another module)
manufacturer block and template to render HTML for manufacturer info. You will use it as frontend model for the manufacturer_id attribute (see below)
setup script that adds a product attribute manufacturer_id
source model for the manufacturer id, so you can select the manufacturer from a dropdown instead of typing in the id
To display manufacturer description on product page without using product attribute you need to create new table "manufacturer_info" and this table contains information of manufacturer id as well as description.
Table is something like this
manufacturer_id | description
To add description, you need to create new module which will display all the shop brand s and description in grid. When you edit manufacture one form will appear and in that form add description and save it to database.
After saving description, You can display it on product page based on manufacture_id.
To get current manufacture use following code
$_product = $this->getProduct();
$manufacturerName = $_product->getAttributeText('manufacturer');
$manufacturerId = $_product->getManufacturer();
Use manufacturer_id for getting description from newly created table
I hope this helps.
I am upgrading a website to enable product variants - currently the website only provides standalone products but there is now a requirement to provide variants of a particular product, e.g. size or colour. The aim is to enable the site admin to easily insert/edit product variants.
The current structure is as follows:
table product
=============
id
name
description
category_id
price
stock_level
The fields 'price' and 'stock_level' will now need to be relevant to each product variant.
A product can have multiple combinations of variants, e.g:
Product ID 5 - Size: Small, Colour: Black
Product ID 5 - Size: Small, Colour: Brown
On the front end there are two dropdowns to select the variants (Size and Colour). Upon selecting the required variants, the values are posted to a PHP script which runs an SQL query to check if that particular variant combination is available.
I am struggling to come up with a solution for this. I have currently created the following functionality, which I think is the starting point:
Ability to create/edit variant TYPES e.g. Size or Colour:
table variant_type
==================
id
name
Ability to assign values to variant types, e.g. Small, Large, Black, Brown:
table variant_type_value
========================
id
name
variant_type_id
I am struggling to come up with the design for the table(s) that will store the product variant combinations (including their price and stock level).
Bear in mind, on the backend, there will be a form to "Add a new Variant" - on this form the admin will need to select 'Size', 'Colour', 'Price' and 'Stock Level' when adding/editing a variant.
I think the easiest way would be to have a Product table; that would have all the details of the variants in it, by including the foreign keys for the Product table, as well as the Size and Colour tables:
table variant
=============
variantID
productID
sizeID
colourID
stock
price
table product
=============
id
name
description
category_id
table size
==========
sizeID
sizeName
table colour
============
colourID
colourName
So you can get the details for the variants by joining all four tables together. Information that relates to the product in general goes in the product table, and you can add extra types of variant by creating new tables and linking them in the variant table.
Editted to add:
This way, you'll need to add extra tables if you want to add a new type of variant. You could also get around it by merging all the variant possibilities into one variant table:
+--+------+------+
|ID|Type |Option|
+--+------+------+
|1 |Colour|Brown |
|2 |Size |Small |
+--+------+------+
You'd then have multiple foreign keys from variantInfo in the main product table.
I don't tend to like that - I don't like have multiple types of information stored in the same table. I just think it's confusing, and you need to make the programming logic more complicated. If you want to have extra variant types, I'd recommend just setting them all up now - it's a little extra work, and some of them won't be used, but I think it's a lot easier to maintain.
I'm currently building a retail e-shop for a jewellery manufacturer which also sells wholesale to other shops and I'm looking for an efficient way to "hide"/"camouflage" the product id's for all products so that other competitors wont be able to see the product's barcodes and find out that the manufacturer is doing direct sales at lower prices.
All products on the website have a 4-5 digit id which is also the name of the products' images, ie for Product #1234 image filename is 1234.jpg
One thought was to add a 3-digit random int before and after the product ID that would make it quite hard for someone to figure out the product id. Another thought would be to reverse the id's or perform some sort of scrambling. This would work fine for all the links within the site and all i'd have to do would be to strip off the first and last 3 digits off the product id's or de-scramble before using in the queries but what can I do when it comes to displaying product images? I don't want visitors to be able to see the filenames, that would completely blow the cover for a ll product id's.
Suggestions and ideas are very welcome.
You shouldn't allow direct access to your images like that. Instead, use a php wrapper which translates your fake product id to the actual image file and return that.
Ie http://.../getimage.php?fakeid=1337 which translates that into the actual product id 123 and then readfile("/path/to/123.png");
The products don't need to be identified by barcode - you could use a meaningless identifier for the products, and only look up the barcode when you actually need it. Example:
product_barcode | product_identifier
7310791268002 | deadbeef01234cafe
Then, you'd use deadbeef01234cafe both for identifying the product in the store, and for the image name.