Why is this apparently so difficult?

[MarkRS]

Could I just check out if I'm understanding this properly.

I'm looking at automating creating new product types, just a simple situation.

AFAICT there are two main reasons for using product types :

1) To have a group of products use separate values for the standard settings
2) To have completely new values for a new types of products.

The second one is quite involved, requiring new tables and stuff to handle all those.

The first one looks pretty easy.
The easiest situation just uses the default product values.

It looks to me as if to automate this all that's needed is

1) New product type name
2) Existing product type to base the new type on

And then the process is

1) Copy files based on existing product types or fallback to product default
2) Insert one line into zen_product_type

3) Optionally add lines into zen_product _type_layout and
autogenerate constant names and the corresponding file

Am I missing something?
Looks pretty simple, which is worrying me

I know it's just covering the simple case, but the basic set of layout values look pretty good to me, and certainly I don't need anything else for my first couple of extra product types.

It's only in the more complicated case that all the paraphernalia of boxes and filters &tc are required, shirley?

Regards
Mark

[kobra]

Not fully positive that I understand what it is that you are describing.

Zen Cart allows a products settings to be copied to another product as part of the in built functions. This seems at least part of what you described..

Enter a few products and play with the settings or load the demo products as these describe many of the features that can be setup.

[DrByte]

Alternate product types are also useful for displaying product details in a different manner than other products. In the product types supplied with Zen Cart, there is a music product type. This (in addition to the boxes/filters etc you mention) adds an additional display component for the customer to view ... namely the Media Manager, which is a collection of previewable audio clips tied to said product. It also displays the additional-collected information on that product such as artist, record company, genre, etc, along with the usual information such as model number, quantity on hand, manufacturer, etc.

Essentially, product types do two things: collect/store extra/specific information for said type of product, and display said information in a specialized way for said products.

You can find some rudimentary documentation on creating product types in the /docs/product_types_readme.html file in the Zen Cart ZIP file.


In addition to the steps you asked about, you will need to create the full supporting fileset for the new product type. You can follow these as an example:
/includes/modules/pages/product_info/*.*
/admin/includes/modules/product_info/
/admin/product_info.php
There are also the corresponding language files.

[MarkRS]

In addition to the steps you asked about, you will need to create the full supporting fileset for the new product type.

Yes, that's what I was referring to.

I used Moku's book type as a basis.
For the simple case there seem to me to be only 13 files to copy, the content doesn't change just the filenames and locations.

Presumably if I generate new lines in the product layout table with new constant names then another file is required defining those constants.

But still, that's all fairly short and sweet, unless I'm missing something

Regards
Mark

[DrByte]

You're on the right track.

Some of the constants (switches, not languages) would go in the product_type_layout table, using a similar pattern to what's already there. They could just as easily go in a PHP file.

[MarkRS]

Hey, you're an early riser!

You're on the right track.

OK great, thanx.

I'll give it a go and post back here to let you know how I'm getting on.

Regards
Mark

[MarkRS]

Do files have to go in the "English" part of the language tree in order to be part of the structure, and then able to be overridden, or is that just because I'm using it in English?

[kobra]

Files in any tree that also has a classic folder can be placed in a "your_template" folder that you create there. Files in anotherr tree with a classic folder go in another your_template folder that you create there. and so forth.

[MarkRS]

What I've seen seems to suggest that when I create an override there has to be a file in the standard directories that is being overriden.

What I'm asking is where does that file that is being overriden have to be.
Is is in the "English" directory, or in the users home language.

[DrByte]

1. What has your testing proven?

2. For the most part, there should not be a need to have a "base" file in the "english" folder; however, if you plan to support english on your site, then if you don't have a file in "english", your customer will encounter errors.

3. Here's an example: the "product_info" page looks for language files like this:

/includes/languages/MYLANGUAGE/MYTEMPLATE/product_info.php
then
/includes/languages/MYLANGUAGE/product_info.php
and
/includes/languages/MYTEMPLATE/MYLANGUAGE.php
then
/includes/languages/MYLANGUAGE.php

MYLANGUAGE is determined by:
- if selected language has a language file, selected language is used
- otherwise, english is used as default