Adding a field to Category/Products page, Can this been done?

Hello,

I would like to add a field called Product Color in the Category/Products page in the admin area. I would like to do this for my Google feed. I know it can be done in attributes, but I thought it would be easier to set the color while adding the product. Can this been done? if so would it be picked up in Google feeds? I use Magneticone M1Export.

Thank You,
Randy

While it can be accomplished - it would require considerable coding and mysql work
admin files
store front files
mysql addition

Thanks, I guess I will continue with the attributes.

Numinix offers something that provides additional fields. Understand that if you use it, more than likely you will be one of the first to identify sql install errors for poorly written contribution installers.

I added additional product fields to my products so I think I am not understanding what the question is. Can someone please clarify if you have time, for my own knowledge.

Thank you

lruskauff:

I added additional product fields to my products so I think I am not understanding what the question is. Can someone please clarify if you have time, for my own knowledge.

Thank you

So the question here (based on the original post) would be basically, okay so how did you add additional fields, what steps would one need to take/follow to duplicate the effort, and to the point, could it be used to display such a field that could be presented to things such as google feeds...

Ok then. The only thing I don't know then is "can it be presented to things such as google feeds". My guess is that it can because it is just another field but at this point it is just a guess.

Randy, if you are still reading, I followed a thread from crazy_chris that pretty much lays out what you need to do. In general terms you:

1. Add the new product fields to your database products table
   2 Edit collect_info.php to add your new field.
2. Edit preview_info.php
3. Edit update_product.php
4. Edit main_template_vars.php
5. Edit tpl_product_info_display.php

The drawback is that you have to edit files that are going to be rewritten with each update, so you will have to go back in and add your fields each time. Just make sure you make backups of everything.

The thread that I followed is How-To: Add new Properties to your Products. It was written by crazy_chris on Feb 8, 2007.
He writes:

 Idea or Suggestion How-To: Add new Properties to your Products

    hi folks,

    this is a little howto add new properties to general products
    (like guarantee time, color, oem-number, compatible models, whatsoever)

        think
        decide which new properties you want to add to your products
        (in this example we take guarantee-time (in months) and color)
        .
        db manipulation
        open the table "products" in your zencart-database and insert new rows at the end of the table called "products_guarantee" and "products_color"
        ALTER TABLE `zencart_products` ADD `products_guarantee` INT NOT NULL , ADD `products_color` VARCHAR( 32 ) NOT NULL;
        .
        edit 'collect_info.php' (in /admin/includes/modules/product/)
            at the very beginning there is the variable $parameters set. add your row-names to the end:
            'products_guarantee' => '0', 'products_color' => '' );
            .
            just below there is the db-query set [$product = $db->Execute("...]
            add your rows with a 'p.' in front (before the "from ..." part)
            select ......., p.products_guarantee, p.products_color from ....
            .
            now you can add the input fields in the product-mask (lets say somewhere around line 450 or so):
            <tr>
            <td class="main">Guarantee Time (in months)</td>
            <td class="main"><?php echo zen_draw_separator('pixel_trans.gif', '24', '15') . ' ' . zen_draw_input_field('products_guarantee', $pInfo->products_guarantee, zen_set_field_length(TABLE_PRODUCTS, 'products_guarantee')); ?></td>
            </tr><tr>
            <td class="main">Color</td>
            <td class="main"><?php echo zen_draw_separator('pixel_trans.gif', '24', '15') . ' ' . zen_draw_input_field('products_color', $pInfo->products_color, zen_set_field_length(TABLE_PRODUCTS, 'products_color')); ?></td>
            </tr>
            .
        edit 'preview_info.php' (in /admin/includes/modules/product/)
        somewhere around line 10 is the variable $product set. like in step 3.2 add the new rows with a 'p.' in front just before the 'from'
        select ......., p.products_guarantee, p.products_color from ....
        .
        finally, edit 'update_product.php' (in /admin/includes/modules/)
        around line 20 is the $sql_data_array set. add to the last lines before ');' the new rownames.
        $sql_data_array = .......... 'products_guarantee' => zen_db_prepare_input($_POST['products_guarantee']), 'products_color' => zen_db_prepare_input($_POST['products_color']) );
        .
        Setup All Done!
        .
        .
        .
        .Of course, now we want to display our cool new properties .
        .
        edit 'main_template_vars.php' (in /includes/modules/pages/product_info/)
        around line 46 you find the variable $sql set. like in step 3.2 add the new rows with a 'p.' in front just before the 'from'
        select ......., p.products_guarantee, p.products_color from ....
        .
        last step: display the new infos
        edit 'tpl_product_info_display.php' (in /includes/templates/template_default/templates/)
        now, wherever you want, you can add to the html:
        <?php echo $product_info->fields['products_guarantee']; ?> and <?php echo $product_info->fields['products_color']; ?>


    enjoy!

Linda

lruskauff:

Ok then. The only thing I don't know then is "can it be presented to things such as google feeds". My guess is that it can because it is just another field but at this point it is just a guess.

Randy, if you are still reading, I followed a thread from crazy_chris that pretty much lays out what you need to do. In general terms you:

1. Add the new product fields to your database products table
   2 Edit collect_info.php to add your new field.
2. Edit preview_info.php
3. Edit update_product.php
4. Edit main_template_vars.php
5. Edit tpl_product_info_display.php

The drawback is that you have to edit files that are going to be rewritten with each update, so you will have to go back in and add your fields each time. Just make sure you make backups of everything.

The thread that I followed is How-To: Add new Properties to your Products. It was written by crazy_chris on Feb 8, 2007.
He writes:

Idea or Suggestion How-To: Add new Properties to your Products

hi folks,

this is a little howto add new properties to general products
(like guarantee time, color, oem-number, compatible models, whatsoever)

    think
    decide which new properties you want to add to your products
    (in this example we take guarantee-time (in months) and color)
    .
    db manipulation
    open the table "products" in your zencart-database and insert new rows at the end of the table called "products_guarantee" and "products_color"
    ALTER TABLE `zencart_products` ADD `products_guarantee` INT NOT NULL , ADD `products_color` VARCHAR( 32 ) NOT NULL;
    .
    edit 'collect_info.php' (in /admin/includes/modules/product/)
        at the very beginning there is the variable $parameters set. add your row-names to the end:
        'products_guarantee' => '0', 'products_color' => '' );
        .
        just below there is the db-query set [$product = $db->Execute("...]
        add your rows with a 'p.' in front (before the "from ..." part)
        select ......., p.products_guarantee, p.products_color from ....
        .
        now you can add the input fields in the product-mask (lets say somewhere around line 450 or so):
        <tr>
        <td class="main">Guarantee Time (in months)</td>
        <td class="main"><?php echo zen_draw_separator('pixel_trans.gif', '24', '15') . ' ' . zen_draw_input_field('products_guarantee', $pInfo->products_guarantee, zen_set_field_length(TABLE_PRODUCTS, 'products_guarantee')); ?></td>
        </tr><tr>
        <td class="main">Color</td>
        <td class="main"><?php echo zen_draw_separator('pixel_trans.gif', '24', '15') . ' ' . zen_draw_input_field('products_color', $pInfo->products_color, zen_set_field_length(TABLE_PRODUCTS, 'products_color')); ?></td>
        </tr>
        .
    edit 'preview_info.php' (in /admin/includes/modules/product/)
    somewhere around line 10 is the variable $product set. like in step 3.2 add the new rows with a 'p.' in front just before the 'from'
    select ......., p.products_guarantee, p.products_color from ....
    .
    finally, edit 'update_product.php' (in /admin/includes/modules/)
    around line 20 is the $sql_data_array set. add to the last lines before ');' the new rownames.
    $sql_data_array = .......... 'products_guarantee' => zen_db_prepare_input($_POST['products_guarantee']), 'products_color' => zen_db_prepare_input($_POST['products_color']) );
    .
    Setup All Done!
    .
    .
    .
    .Of course, now we want to display our cool new properties .
    .
    edit 'main_template_vars.php' (in /includes/modules/pages/product_info/)
    around line 46 you find the variable $sql set. like in step 3.2 add the new rows with a 'p.' in front just before the 'from'
    select ......., p.products_guarantee, p.products_color from ....
    .
    last step: display the new infos
    edit 'tpl_product_info_display.php' (in /includes/templates/template_default/templates/)
    now, wherever you want, you can add to the html:
    <?php echo $product_info->fields['products_guarantee']; ?> and <?php echo $product_info->fields['products_color']; ?>


enjoy!

> 
> Linda

So a couple of things.
1) The above can be accomplished through the use of a plugin designed specifically to add new product fields. (Numinix additional fields)
2) The above modifies files that will be overwritten on an upgrade or require merging, but many of those changes can be in a separate file that will not be overwritten on an upgrade. Ie template override directory instead of template_default.)
3) Language files are not used in cases where the template displays text information. This may not be a problem for a specific site, but if the audience is expanded or in the case of others reading this thread, ideally the construct of a site using ZC should meet those standards. It also becomes easier to maintain consistency throughout as one can change the text in one place and see the result everywhere used.

mc12345678:

So a couple of things.

1. The above can be accomplished through the use of a plugin designed specifically to add new product fields. (Numinix additional fields) didnt you just say DONT use it!
2. The above modifies files that will be overwritten on an upgrade or require merging, but many of those changes can be in a separate file that will not be overwritten on an upgrade. Ie template override directory instead of template_default.)didn't I say that when I said the drawback....,
3. Language files are not used in cases where the template displays text information. This may not be a problem for a specific site, but if the audience is expanded or in the case of others reading this thread, ideally the construct of a site using ZC should meet those standards. It also becomes easier to maintain consistency throughout as one can change the text in one place and see the result everywhere used.

Ok, here is my problem. First we get a lot of " go search the forums for an answer " and then when we do we get told " don't do that". I knew when I added the code to my own site that there had to be a better way, but I didn't have the skill, or time at the time. And numinex code wasn't there at the time. Now I actually have some of that knowledge and will work on doing my code better in the future. But I still think this is an option besides attributes that he should have been told of ( sorry cobra, but your answer was in the form of it not being an option.)

Then, I'm trying to be a better Zener and put back into the community but YOU GUYS are so confusing. Here I see two experts telling someone that it is quite hard to do and that their other option is to use some flawed code. But I did it when I knew nothing so I thought I'd share. It is raw, yes but much simpler than attributes. And if he/she has only one field why not.

If I had to redo mine I would go the route of another product type and I would do it better, but I still have a lot to learn so I'm sure I would still do some of it wrong. I guess what I'm saying is show us the possibilities but let us decide if we want to go that route. Thanks for listening.

Comments in quote block don't carry over when replying with quote, so to address the red text...

1. No didn't say don't do it, said that to understand the potential results/effects of using it. This statement is based on the proper coding used by Numinix to add fields to ZC whereas "typical" plugin coders may base their sql work on a standard ZC installation without considering the possibility of the database tables being modified. There is a strong push throughout all of the (supported) plugins to go to the route of addressing fields and their values rather than addressing tables and their fields and their values. Way to think of it is treat the new data as water running through a round hole instead of trying to push a square peg through that same round hole. (ie. Table normally has 3 fields, but program comes along and adds a fourth. Now any program that tries to claim that the table only has 3 fields and the values for them are this will/may error.... But if the program instead said for field 1 I want it to be this, for field 2 I want it to be that, and for field 3 I want to be something else; then there is no conflict as field 4 was never addressed. Maybe not best way to describe, but it's the concept.)

2. Indicated that there was a potential "problem" with the way it was implemented, but I was attempting to offer some of the solution, which negates the concern in all cases except the collect_info.php, preview_info.php, and update_product.php files which being admin files do not currently have template overrides. (I think/thought that ZC 1.6.0 was going to lead more to that possibility.) I haven't looked in a while, but even the changes needed there may be able to be made outside of the files themselves using an observer class to account for the additional fields.

lruskauff:

Ok, here is my problem. First we get a lot of " go search the forums for an answer " and then when we do we get told " don't do that". I knew when I added the code to my own site that there had to be a better way, but I didn't have the skill, or time at the time. And numinex code wasn't there at the time. Now I actually have some of that knowledge and will work on doing my code better in the future. But I still think this is an option besides attributes that he should have been told of ( sorry cobra, but your answer was in the form of it not being an option.)

Then, I'm trying to be a better Zener and put back into the community but YOU GUYS are so confusing. Here I see two experts telling someone that it is quite hard to do and that their other option is to use some flawed code. But I did it when I knew nothing so I thought I'd share. It is raw, yes but much simpler than attributes. And if he/she has only one field why not.

If I had to redo mine I would go the route of another product type and I would do it better, but I still have a lot to learn so I'm sure I would still do some of it wrong. I guess what I'm saying is show us the possibilities but let us decide if we want to go that route. Thanks for listening.

So to the recent post... Yes, searching the forum is valuable, look at the information that was found... But also as pointed out take note of the date of that information... 8 years ago... A lot has changed... So, while the basic concept is present like any such code, there are likely to be changes to either make it work (which is not so much a case here other than line numbers) or to bring up to the current standard... Nothing about what was posted is broken (again line numbers being an exception), and unfortunately everyone has their opinion about how to do something. The OP has a viable solution currently but is seeking an alternate method where attributes are not used. Personally not sure why that is an issue, but their site (like yours) is personally made... The part about not having the time... That's exactly why one should be focusing on the profit of their business instead of the nuances of the code perhaps and as necessary request the help of others to do the work... But that is a separate issue/point.

There is nothing flawed about the Numinix code, in fact it is because it is properly written to modify the ZC database that it identifies that other's code is improperly written or flawed... Certainly in an open source situation like this, Numinix could have gone and created new tables independent of the core ZC tables, but that isn't in line with good database programming/usage. In fact, if every item is not to have this field populated then technically in line with database optimization the extra field should exist in its own database table. But that too is a separate issue as the majority of users will get by just fine with the database structure as is.

Kobra's answer was in line with what it actually takes... The interpretation of the answer is left to the individual reader. The question was is it possible, the answer was yes, but requires work and/or experience... Ie. not for the feint of heart, there will be mistakes made, aggravation had, and a sense of giving up, but the accomplishment, result, and its use is what makes it worth it in the end. (again assuming that it is a "task" that is integral to the business model.)

Not sure how it is considered easier than using attributes, but if that is/was the understanding, then that may be (or perhaps may have been) a good reason to switch... I can see either method being possible/usable where as an attribute, the "word" can be changed which would affect all such product that have that one attribute. A product having the data field requires entry/reentry into every product that is going to have that "attribute". Sure there are tools that can support that quick entry (EasyPopulate for example), but even with it, either method is rapidly updateable... So there is no "time" savings really when using something like that other than the potential of misspelling a word one time out of the many that it is updated/pasted and from there on out it will not get updated with any grand replacement scheme.

Even a different product type is yet another overtaking of a scale... Those same 3 files have to be modified as well as template files, header files, sql run to recognize the options available for display/modification, any plugins that are checking for particular aspects need to now be looking for this new product type, etc...

Two programmers given equivalent design requirements are more than likely to provide two completely different products. One may for example simply provide the bare minimum of what meets the criteria, which sure provides the product requested, but what now that it is determined that either a new feature, or a new look is desired? Potentially back to the drawing board... Where the other may fit the expectations into areas that are flexible and with sufficient variation to allow additional requests not to interfere with the existing expectation and to provide something that is that much better off... They may complete at the same time, or different times, etc... But the point being adequately explaining the goal, expectations, requirements, etc... May get the result desired/requested but may not be able to do anything else. I'll use an example in that there is at least one template making group that creates stunning looking templates, but as soon as this or that plugin is installed the template falls apart and serves broken pages... Not ZC friendly although built for ZC... Then there are those that are put together as ZC compatible, offered for free, and compatible relatively with all recent versions of ZC... Works like expected/desired; however, still a few minor things discrepant because each version of ZC has potentially modifications to the template that need to be incorporated into the template being used... Nothing wrong with that either...

So, I understand the potential frustration. Do understand that I am not in any way affiliated with the ZC core team and that the offers/suggestions provided are of my own making, they are not "requirements" as again this is open source, and at least one suggestion was offered where there are installation instructions that are maintained by someone else (presumably up-to-date) with code that is also presumably maintained up-to-date and support to go with it (though the forum does provide a lot of support as well. :) )

Kobra offered a solution, go code it.. :) You've offered a solution, slightly dated... So far haven't seen anyone say don't use that at all, but instead built on what was provided at each step of the game.

Keep up the offerings...

Hi MC

Thanks again. Just to clarify when you said: ```
Numinix offers something that provides additional fields. Understand that if you use it, more than likely you will be one of the first to identify sql install errors for poorly written contribution installers.

you didn't mean Numinix offered the poorly written contribution installers but "others".  I took it the other way around which is why I was confused and wondering then which contributors that I could/trust.

When you said:

There is a strong push throughout all of the (supported) plugins to go to the route of addressing fields and their values rather than addressing tables and their fields and their values. Way to think of it is treat the new data as water running through a round hole instead of trying to push a square peg through that same round hole. (ie. Table normally has 3 fields, but program comes along and adds a fourth. Now any program that tries to claim that the table only has 3 fields and the values for them are this will/may error.... But if the program instead said for field 1 I want it to be this, for field 2 I want it to be that, and for field 3 I want to be something else; then there is no conflict as field 4 was never addressed. Maybe not best way to describe, but it's the concept.)

I'm understand the two concepts you describe, but am not sure which one you say contributors are for.  The way my mind works is don't even try to squeeze that square peg in.  I would say if there is a table, don't assume that there are only 3 fields.  Do what you need to do to each field until you don't have anymore fields.  Is that what you are saying?

I could ask you more but I will stop.  Sorry about the red text but I wanted you to see where I put my comments and red just popped out :)

If I had my way (and unlimited funds) I would spend it at school learning.  I'm one of those kids who always wants to know the "why" about things so I apologize for all of my questions.

Linda

lruskauff:

Hi MC

Thanks again. Just to clarify when you said: ```
Numinix offers something that provides additional fields. Understand that if you use it, more than likely you will be one of the first to identify sql install errors for poorly written contribution installers.

> 
> you didn't mean Numinix offered the poorly written contribution installers but "others". I took it the other way around which is why I was confused and wondering then which contributors that I could/trust.
> 
> When you said:
> ```
 There is a strong push throughout all of the (supported) plugins to go to the route of addressing fields and their values rather than addressing tables and their fields and their values. Way to think of it is treat the new data as water running through a round hole instead of trying to push a square peg through that same round hole. (ie. Table normally has 3 fields, but program comes along and adds a fourth. Now any program that tries to claim that the table only has 3 fields and the values for them are this will/may error.... But if the program instead said for field 1 I want it to be this, for field 2 I want it to be that, and for field 3 I want to be something else; then there is no conflict as field 4 was never addressed. Maybe not best way to describe, but it's the concept.)

I'm understand the two concepts you describe, but am not sure which one you say contributors are for. The way my mind works is don't even try to squeeze that square peg in. I would say if there is a table, don't assume that there are only 3 fields. Do what you need to do to each field until you don't have anymore fields. Is that what you are saying?

I could ask you more but I will stop. Sorry about the red text but I wanted you to see where I put my comments and red just popped out :)

If I had my way (and unlimited funds) I would spend it at school learning. I'm one of those kids who always wants to know the "why" about things so I apologize for all of my questions.

Linda

Feel free to ask more, but also good to address a question at a time sometimes... Might answer/shape understanding for the next thought/question.

So a well written series can be shown from the ZC install/upgrade process... In the install a table is created (I've left off the drop statement that is included and I've left off several of the other table defines for simplicity.)

CREATE TABLE products (
  products_id int(11) NOT NULL auto_increment,
  products_type int(11) NOT NULL default '1',
  products_quantity float NOT NULL default '0',
  products_model varchar(32) default NULL
) ENGINE=MyISAM;

The above show the first four fields of the products table... Nothing "special" about it, a table is created with four fields.
If the demo data is chosen to be displayed, then one can see (again paired down for simplicity's sake) the following first five products:

Example 1-1:

INSERT INTO products (products_id, products_type, products_quantity, products_model) VALUES 
(1, 1, '31', 'MG200MMS'),
(2, 1, '31', 'MG400-32MB'),
(3, 1, '500', 'MSIMPRO'),
(4, 1, '12', 'DVD-RPMK'),
(5, 1, '15', 'DVD-BLDRNDC');

The above indicates that for field products_id assign the data that is first in the values row. products_type to the second, etc...

At the completion of that SQL the five products have each of those four fields assigned..
So what, if instead the above SQL were modified using the same table and applied instead of the above:

Example 1-2:

INSERT INTO products (products_id, products_type, products_quantity) VALUES 
(1, 1, '31'),
(2, 1, '31'),
(3, 1, '500'),
(4, 1, '12'),
(5, 1, '15');

Well then, the first three columns would be populated with the above data, but the fourth would be whatever the default is in the table (NULL in this case). No problem though, just now there is no products_model information.

So let's revisit the example 1-1 and make a change:

Example 2-1:

INSERT INTO products VALUES 
(1, 1, '31', 'MG200MMS'),
(2, 1, '31', 'MG400-32MB'),
(3, 1, '500', 'MSIMPRO'),
(4, 1, '12', 'DVD-RPMK'),
(5, 1, '15', 'DVD-BLDRNDC');

Notice how the field designations have been removed? With the above defined table, this SQL will not cause a problem... Four fields in the table, four fields of data being imported...
But let's think about this a little more/differently. Let's now add a field to the table, something done by another plugin. So the table would look like this:

CREATE TABLE products (
  products_id int(11) NOT NULL auto_increment,
  products_type int(11) NOT NULL default '1',
  products_quantity float NOT NULL default '0',
  products_model varchar(32) default NULL,
  products_new_field int(2) NOT NULL default '0'
) ENGINE=MyISAM;

now using Example 2-1 though, there are five fields of the table and only four fields of data... Which field of data should go to which field of the table??? That's where MySQL basically falls apart... Can't blame it either...

But the following would also work...

INSERT INTO products VALUES 
(1, 1, '31', 'MG200MMS', 5),
(2, 1, '31', 'MG400-32MB', 4),
(3, 1, '500', 'MSIMPRO', 2),
(4, 1, '12', 'DVD-RPMK', 3),
(5, 1, '15', 'DVD-BLDRNDC', 1);

That is until yet another table field is added or "worse" if the field's position is changed in the database... This last part is not frequently performed, but is one of "those possibilities"... But if we went back to something similar to the original assignment:

INSERT INTO products (products_id, products_type, products_quantity, products_new_field) VALUES 
(1, 1, '31', 'MG200MMS', 5),
(2, 1, '31', 'MG400-32MB', 4),
(3, 1, '500', 'MSIMPRO', 2),
(4, 1, '12', 'DVD-RPMK', 3),
(5, 1, '15', 'DVD-BLDRNDC', 1);

Then MySQL knows what value to assign to what field. This is regardless to the field sequence in the database, and doesn't matter how many fields are in the database provided at least the five fields above actually exist.

So with the second table setup, the Example 1-1 still would work, but it would leave products_new_field to be the default value from the table settings... Oh well, so all products_new_field data will be populated initially with '0'. Ideally the code that uses that field knows what to do when it comes across that default value. It may be that it performs an operation to reset the value, it may present something specific to the screen, etc... Basically the new code has to be able to successfully execute in absence of additional action after the installation meaning that site shouldn't bomb out just because the code has been installed, but instead only when there is a real problem that can not be addressed.

In a way this is what Numinix' software does, and it is the "early day" coders that addressed database data similar to example 2-1. There really wasn't a need back then as who would actually change the table structure? :) And there are possibly several plugins that still use that style of data assignment, mostly because it hasn't been a problem yet.. :) But the way to go forward (at this time) is to at least format the SQL to look like those in example 1. There certainly are other SQL caveats, like insert ignore, or use the update command, etc... but even those additional actions have some benefits where necessary and also allow the same field to value assignment ability.

Hope that helps a smidge with SQL design. I fully expect that some of the other avid coders will add to this for pure educational purposes, but wanted to get through the first tidbit and to further explain what I was discussing about various plugins.

Thank you. I didn't realize it was possible to do a statement like 2-1 and I can see how that could really screw up a database. And now I've got to download Numinex. Code to see how he does things.

Sorry I haven't replied sooner, but it has been a mad house in the shop this week.

I have read the thread and I installed Numinix Product fields. I was able to make a product field called Product Color, but when I ran a feed it was not detected. I figure Numinix and MagenticOne doesn't work well together. Manually adding Product color in the Attributes works, so it may be more work in the beginning I know it will work.

Thank You everyone for all the input.
Randy

If not mistaken have to go a step further once the field is created and to actually display it on the tpl_product_info_default.php page. In your case you would want to surround it with a class tag that can then be hidden using CSS.

The plugin, if I remember correctly, simply makes the field(s) available to be used as desired not that it automatically applies it to one use or another per se.

I will look into that, I don't really care if it is hidden or not.

Thanks.