Skip to main content

Adding custom Yahoo Store fields - Catalog Manager vs. Store Editor

In a non-legacy Yahoo Store, there are two ways to add custom fields: through Catalog Manager under "Manage my Tables" and through the Store Editor, under "Types" (the Store Editor's "Types" are essentially the same as Catalog Manager's "Tables".) Whether you add custom fields from Catalog Manager or from the Store Editor does make a difference as each has its advantages as well as disadvantages.

Catalog Manager

To me the main advantages of using Catalog Manager to add custom fields are:

1) You can add multiple fields quicker
2) You can later change the field's name and even type
3) You can delete the field if you no longer need it.
4) All the fields that are available in Catalog Manager are included in the data.csv file if you download your catalog.
5) All the fields that are available in Catalog Manager are also included in the catalog.xml datafeed file, which is used by the comparison shopping engines, for example. (See the Search Engines settings in your Store Manager page.)

However, Catalog Manager has its limitations when it comes to custom fields.

1) There are certain field types that are considered to be "editor only". These are references, symbol, color, ids, font, objects, references, and orderable. Because these field types are editor only, any field with these field types is invisible to Catalog Manager, which means you cannot add a custom field using any of these fields types, nor can you access any field (from Catalog Manager) that has one of these types. Furthermore, since these types are not seen by Catalog Manager, if you download your catalog, none of these types of fields are in the downloaded CSV file.

2) There is a limit as to how many custom fields you can add, depending on what Merchant Solutions package you have subscribed to. In Merchant Starter, you can have a total of 50 fields in Catalog Manager. In Merchant Standard, you can have 80, and in Merchant Professional, 100.

Store Editor

Everything I listed as an advantage of Catalog Manager is a shortcoming of the Editor, and everything that's a limitation in Catalog Manager is an advantage of the Editor.

1) If you find yourself the need to add editor-only fields, your only option is the Store Editor's "Types".
2) Fields that you add in the Store Editor, unless you check the box that you want the field to be available in Catalog Manager, are not counted toward the maximum allowed custom fields limit.
3) You can exceed the maximum number of fields even if you check the box that you want your field to be available in Catalog Manager, however, if you do this, you will not be able to make changes to the existing fields in Catalog Manager until you delete the excess fields.

Which method you use is up to you and the particular task you are trying to solve with your custom field. If you are adding a field that you are sure you won't ever need to change or delete, you won't need it to be included in the downloaded data.csv file in Catalog Manager, or the catalog.xml datafeed file, use the Store Editor. If the field you are adding is an editor-only field, you have no choice but to use the Store Editor to add it. If on the other hand, you may at some point want to delete the field, or the field needs to be included in the download or in the catalog.xml file, use Catalog Manager to add it.

Comments

Unknown said…
I can add a field to my default-table, but how do I get the custom field to display on the items page?
You need to modify your templates to do this, but how or where you display your custom fields depends on your circumstances and your templates so I can't tell you where to put it or what templates to change to make it happen.

Popular posts from this blog

CPR for a Yahoo Store on Google's Supplemental Index

Recently a client of mine came to me and said that most of his store pages disappeared from Google, and he did not do anything to make this happen. I was a bit skeptical, so I went to Google, did a search on his store, and sure enough, there were only two pages indexed, his home page and his site map (ind.html) page. The rest were in the supplemental results, which means that Google thought the rest of the pages were not much different than these two pages. When I looked at the supplemental results, the little excerpts under each link were exactly the same, and I also noticed that what Google showed under each result was actually text from the ALT tags of the header image. I looked at some of these pages in my client's store, and they were actually different. This was a bit puzzling, but then I thought perhaps Google saw that the header and left navigation was the same throughout the site (which is pretty normal), but that the text that made each page different was too far down ins

What to expect when your redesign goes live

At Y-Times we roll out new designs, redesigns and other major upgrades to Yahoo stores on a fairly regular basis. Some of the main questions our clients ask are how to prepare for a roll-out and what to expect in terms of SEO and conversions when the changes go live? For any functional Yahoo store how well the site ranks and how well it converts are probably the two most important metrics. Since pretty much ANY change you make to any page can potentially alter either or both of these metrics, merchants may understandably feel nervous about far reaching alterations to their sites. However, when those functionality and design changes and additions are done right, there is really very little to fear. First off, what does it mean for a design or redesign to be "done right?" From the technical stand point, search engines look at the underlying structure of your site (the HTML, and increasingly also the CSS and JavaScript code) to try to extract information and meaning from i

Smaller is Better

You often hear the phrase "bigger is better". Sometimes it's true but not when it comes to JavaScript or CSS code in your Yahoo! Store pages. If you include JavaScript code or CSS either as linked files (the preferred method) or embedded inside your pages (obviously not preferred), making these files as small as possible should be your goal. Why? This is no rocket science: smaller files mean faster page loads = happy customers. Ok, so what bloats JavaScript code? In general, white space (tabs, carriage returns, non-used spaces), comments, and the actual code, such as variable and function names. You have control over all of these, however, if you don't use white spaces, carriage returns or comments, it will be immensely difficult to understand and modify your code. And not just for others, you too. There are many commercial JavaScript compression tools around, but I've been using this handy and free utility: http://www.andrewkesper.com/jscrush/ This little utilit