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

[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

[mc12345678]

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.

[lruskauff]

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.

[rtfulk]

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

[mc12345678]

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.

[rtfulk]

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

Thanks.