As indicated in Yahoo Small Business's recent blog post of upcoming features, the long-awaited "incremental publish" feature is being rolled out this month. They are going server by server, so some merchants will see the change sooner then others.
What is incremental publish?
Incremental publish keeps track of what pages you edited and changed since the last time you published the store. Instead of the single "Publish" button, you will now have two buttons, one that says "Publish All", and the other that says "Publish Changes". "Publish All" does the same as the current "Publish" button, it generates and publishes all pages in the store. "Publish Changes", on the other hand, will only publish the pages that changed.
This can be a huge potential time saver especially for large stores whose publish takes hours normally.
Monday, September 05, 2011
Monday, June 27, 2011
Multi-Add and Yahoo Floating Cart Blues
Although the Yahoo! Floating Cart is considered pretty much bug free by Yahoo (you can look at the official open issues list here http://help.yahoo.com/l/us/yahoo/smallbusiness/store/floatingcart/floatingcart-09.html) , there are some pretty "interesting" issues still, so since I keep running into them, I decided to post them here along with the work-arounds. The following issues all occur with multi-add forms only.
1) If you have your quantity set up as anything other than a simple text box (for example a drop-down SELECT box), the floating cart will not take the quantity value. It will take vwquantity as a customer-selected option. The workaround: use a text box instead. Nothing else works currently.
2) If you have a script that checks if the shopper made a selection from a drop-down (basically, any kind of an "onsubmit" handler), the floating cart will still receive the item, even if you cancel the submit event. The workaround: put the event handler on the click event of your add to cart button. This is of course not fool-proof, but this is the only way to prevent the adding of an item to the floating cart. Canceling the submit event does not work with the floating cart.
3) This may be the strangest, but you need to put the following hidden form fields right after the opening FORM tag of the order form, otherwise customer-selected options are not passed on to the floating cart:
multiple-add, allow-zero, vwcatalog, and vwitem0
1) If you have your quantity set up as anything other than a simple text box (for example a drop-down SELECT box), the floating cart will not take the quantity value. It will take vwquantity as a customer-selected option. The workaround: use a text box instead. Nothing else works currently.
2) If you have a script that checks if the shopper made a selection from a drop-down (basically, any kind of an "onsubmit" handler), the floating cart will still receive the item, even if you cancel the submit event. The workaround: put the event handler on the click event of your add to cart button. This is of course not fool-proof, but this is the only way to prevent the adding of an item to the floating cart. Canceling the submit event does not work with the floating cart.
3) This may be the strangest, but you need to put the following hidden form fields right after the opening FORM tag of the order form, otherwise customer-selected options are not passed on to the floating cart:
multiple-add, allow-zero, vwcatalog, and vwitem0
Wednesday, June 08, 2011
What screen resolution should I use?
I get this question often. Or variations of it such as "is it safe to expand my site to 1200px now?"
According to W3Scools, as of January of this year, about 13% of all internet users are still on 1024x768, which is a high enough proportion to make me play it safe and set the max width at 980px so that these folks can see the site OK. If you go any higher, these people will have to scroll sideways, which is traditionally a major "no-no" (simply because it's annoying.)
However, you should check your own stats to see what percentage of YOUR visitors have that resolution, because your demographic segment may very well be different from the average.
According to W3Scools, as of January of this year, about 13% of all internet users are still on 1024x768, which is a high enough proportion to make me play it safe and set the max width at 980px so that these folks can see the site OK. If you go any higher, these people will have to scroll sideways, which is traditionally a major "no-no" (simply because it's annoying.)
However, you should check your own stats to see what percentage of YOUR visitors have that resolution, because your demographic segment may very well be different from the average.
Thursday, October 15, 2009
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.
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.
Friday, July 17, 2009
Once again ONCE
Back in September of 2007 I wrote a post here about using the ONCE RTML operator to speed up the yahoo store editor. In that article I mentioned that the ONCE operator has two modes, one to evaluate the operator's body once per publish and the other, once per page. What I said there was that while ONCE :publish has great potentials and practical uses, ONCE :page wasn't too useful. Well, today I must correct that statement, as I recently discovered two ways to use ONCE :page.
To recap, a statement like this:
Now consider this: some Yahoo! Stores have a breadcrumbs trail both at the top and at the bottom of the page. In case of long pages, this can help visitors navigate the site. In that case, you would have to call the breadcrumbs template twice on each page.
To digress here a little, the breadcrumbs template typically walks through the pages leading up from the current page to the home page (index), and puts up a hyperlink for each page along the path, something like this:
Ok, what's the problem with this? Maybe I'll write another post about this, but the main problem with breadcrumbs is that when writing breadcrumbs code, you have to use either the WITH-OBJECT or the FOR-EACH-OBJECT operator to switch the context to each of the pieces in the breadcrumbs trail, so that you can grab the name of each of those pages (in the above example, Home, Countertop Appliances, Beverage Appliances). Using the WITH-OBJECT or FOR-EACH-OBJECT operator is "exensive", meaning it slows down your editor and your publish process, because the editor has to "fetch" those pages from storage (disk). So, if you have two breadcrumbs trails, you will do this twice per page. That's where ONCE :page comes in!
Take a look at the above code segment. Here, you have the top breadcrumbs, the page body (where the .... part is), and then the bottom breadcrumbs trail. However, in this case, the actual breadcrumbs code is evaluated exactly once, not twice. You essentially get the second one for free!
My second idea came from a small project I was working on recently. In a Yahoo Store, we had pages that had 3 types of "components" you could order: a kit, the individual kit components, and the tools used to put a kit together. We had three "references"-type fields for these called (you guessed it) kit, kit-components, and tools-used, so data entry personnel could put product IDs in all three of these fields. The twist was, they wanted to label each of the "sections". Below is a sketch of this setup.
In RTML, you could write three separate loops to achieve this:
In our case, the table was a little complicated, so splitting the code up into three segments was going to be a problem, but luckily, I was able to solve this using ONCE :page.
Instead of having three loops, I combined the 3 fields into one list using the APPEND operator, so I could have just one loop, but then, I used ONCE :page to put up the headers:
This is somewhat simplified of course, the headings had to go into their own table rows with table cells spanning the entire table width, but that's not the point here.
The point is, that using ONCE :page for the headers, I didn't need to care about where to output the headers, it just worked! Even if I had 20 items in, say kit-components, the "Kit Components" heading would only appear once thanks to the fact that it was output within a ONCE :page construct.
One final point: why did I save the values of the "kit", "kit-components", and "tools-used" properties into local variables? Well, this is a common mistake I see from RTML programmers: they forget that once they are inside a FOR-EACH-OBJECT or WITH-OBJECT expression, they are referencing the local properties of another page. By saving these properties in local variables, I can be sure that I can reference those instead of accidentally grabbing the values from each of the component pages.
To recap, a statement like this:
TEXT ONCE :pagewill evaluate the body of the ONCE operator once on the page and output its result. So in the example above, it would only call the template called some-template once on each page and output whatever some-template writes to the page. So far so good, if you have this block only once on the page, then having ONCE :page in it makes no difference.
GRAB
CALL :some-template
Now consider this: some Yahoo! Stores have a breadcrumbs trail both at the top and at the bottom of the page. In case of long pages, this can help visitors navigate the site. In that case, you would have to call the breadcrumbs template twice on each page.
To digress here a little, the breadcrumbs template typically walks through the pages leading up from the current page to the home page (index), and puts up a hyperlink for each page along the path, something like this:
Home > Countertop Appliances > Beverage Appliances > Electric Tea Kettles
Ok, what's the problem with this? Maybe I'll write another post about this, but the main problem with breadcrumbs is that when writing breadcrumbs code, you have to use either the WITH-OBJECT or the FOR-EACH-OBJECT operator to switch the context to each of the pieces in the breadcrumbs trail, so that you can grab the name of each of those pages (in the above example, Home, Countertop Appliances, Beverage Appliances). Using the WITH-OBJECT or FOR-EACH-OBJECT operator is "exensive", meaning it slows down your editor and your publish process, because the editor has to "fetch" those pages from storage (disk). So, if you have two breadcrumbs trails, you will do this twice per page. That's where ONCE :page comes in!
TEXT ONCE :page
GRAB
CALL :breadcrumbs.
....
TEXT ONCE :page
GRAB
CALL :breadcrumbs.
Take a look at the above code segment. Here, you have the top breadcrumbs, the page body (where the .... part is), and then the bottom breadcrumbs trail. However, in this case, the actual breadcrumbs code is evaluated exactly once, not twice. You essentially get the second one for free!
My second idea came from a small project I was working on recently. In a Yahoo Store, we had pages that had 3 types of "components" you could order: a kit, the individual kit components, and the tools used to put a kit together. We had three "references"-type fields for these called (you guessed it) kit, kit-components, and tools-used, so data entry personnel could put product IDs in all three of these fields. The twist was, they wanted to label each of the "sections". Below is a sketch of this setup.
In RTML, you could write three separate loops to achieve this:
TEXT "KIt"
FOR-EACH-OBJECT @kit
<... generate one line of the table ...>
TEXT "Kit Components"
FOR-EACH-OBJECT @kit-components
<... generate one line of the table ...>
TEXT "Tools Used"
FOR-EACH-OBJECT @tools-used
<... generate one line of the table ...>
In our case, the table was a little complicated, so splitting the code up into three segments was going to be a problem, but luckily, I was able to solve this using ONCE :page.
Instead of having three loops, I combined the 3 fields into one list using the APPEND operator, so I could have just one loop, but then, I used ONCE :page to put up the headers:
WITH variable kit
value @kit
WITH variable kit-components
value @kit-components
WITH variable tools-used
value @tools-used
WITH variable list
value APPEND
@kit
@kit-components
@tools-used
FOR-EACH-OBJECT list
WHEN POSITION element id
sequence kit
ONCE :page
TEXT "Kit"
WHEN POSITION element id
sequence kit-components
ONCE :page
TEXT "Kit Components"
WHEN POSITION element id
sequence tools-used
ONCE :page
TEXT "Tools Used"
<... generate one line of the table ...>
This is somewhat simplified of course, the headings had to go into their own table rows with table cells spanning the entire table width, but that's not the point here.
The point is, that using ONCE :page for the headers, I didn't need to care about where to output the headers, it just worked! Even if I had 20 items in, say kit-components, the "Kit Components" heading would only appear once thanks to the fact that it was output within a ONCE :page construct.
One final point: why did I save the values of the "kit", "kit-components", and "tools-used" properties into local variables? Well, this is a common mistake I see from RTML programmers: they forget that once they are inside a FOR-EACH-OBJECT or WITH-OBJECT expression, they are referencing the local properties of another page. By saving these properties in local variables, I can be sure that I can reference those instead of accidentally grabbing the values from each of the component pages.
Wednesday, January 14, 2009
What is product-url anyway?
I keep having to field questions about the product-url field, and since it came up yesterday, I figured I'd try to clear up all the confusion about it.
So the name product-url suggests that whatever you type in there will become the URL of that product. Unfortunately, this is not the case, or rather, not in the intuitive way. The URL you enter there will be used as the URL for that product in Yahoo Shopping, on the built-in search results page, and on the shopping cart page, however, the URL you type in there DOES NOT actually change the physical URL of the page.
For well established pages (those with good ranking) I would not mess with the URL.
You also need to fill out the product-url field if you participate in Yahoo Shopping. All items with blank product-url entries are rejected by Product Submit and will not be included in Yahoo Shopping.
So the name product-url suggests that whatever you type in there will become the URL of that product. Unfortunately, this is not the case, or rather, not in the intuitive way. The URL you enter there will be used as the URL for that product in Yahoo Shopping, on the built-in search results page, and on the shopping cart page, however, the URL you type in there DOES NOT actually change the physical URL of the page.
What is te URL of a page in a Yahoo Store?
In any Yahoo Store built in the store editor, the URL of a page is the store's domain name and the page ID + .html. For example, in my store at www.ytimes.info, I have a page whose id is rtml101, thehrefore, the URL of that page is http://www.ytimes.info/rtml101.html.Why would you want to change the URL?
For SEO reasons, it is believed to be better to have a URL that includes keywords. When you simply create a page in the editor, the ID (therefore the page URL) gets generated automatically based on what you type in the "Name" field. This would normally be Ok, however, what the editor does is it sort of munges the words of the Name field together to come up with the id. For example, Book about yahoo store became bookabyahsto. Well, not particularly useful for SEO....Can you change the URL then?
The short answer is no. Once a page has been created, it's ID - therefore its URL - is set for good. The only way to "change" it is to delete that page and re-create it with a different ID.How can you specify the ID for a new page?
There are two ways to do this. If you are using database upload and generally manage your store from a CSV file, you can add a column called ID to your data file, and specify the ID there. Or, if you usually use the editor to create pages, then switch to Advanced Mode, then click "Contents", then "New". There you can specify the ID for your new page.For well established pages (those with good ranking) I would not mess with the URL.
Ok, so what is product-url for then?
When Yahoo Store was transformed int Yahoo Merchant Solutions, one of the ideas was to make it possible to build a yahoo store on the web hosting platform and not in the store editor. Since stores that are built using store-tags on the web hosting platform of yahoo are on a different sub-domain than the store editor pages, there had to be a way to point the built-in search results page, the shopping cart page, or yahoo shopping to those alternate locations. That's where product-url came in. So if your store is built with store tags on the web hosting side, then you can (and should) continue to use product-url to specify your product's location.You also need to fill out the product-url field if you participate in Yahoo Shopping. All items with blank product-url entries are rejected by Product Submit and will not be included in Yahoo Shopping.
Wednesday, November 05, 2008
Rapid Edit for the Yahoo! Store Editor
If you are like me, you spend most of your day editing pages in the Yahoo Store editor. And if you do that, you probably spend quite a bit of time navigating to pages and waiting for those pages to load in the editor before being able to edit them. All this waiting really drives me crazy so I kept thinking of ways to speed up my work while working in the editor. One shortcut I always use - if I know thet ID of the page I want to edit - is to erase the last part of the URL while in the editor, and enter the page's Id I want to edit with .html?dired=1 appended to it. For example, if I'm in the editor, and I want to edit the ind.html page, I'd look at the Address field of my browser:
http://ytimes.us-dc1-edit.store.yahoo.net/RT/NEWEDIT.ytimes/d695ff542abb/CD7fAAIJ (just an example)
erase CD7fAAIJ and add ind.html?dired=1 to it so it looks like:
http://ytimes.us-dc1-edit.store.yahoo.net/RT/NEWEDIT.ytimes/d695ff542abb/ind.html?dired=1
and hit Enter. This will take me to the edit form of the ind.html page - in this example but without loading the page itself. This is all great provided that you know the ID of the page you want to edit. But what if you don't know the ID?
Rapid Edit to the rescue!
I came up with a very useful template that can be installed into any Yahoo Store, and while in the store editor, it will put a red asterisk next to all text hyperlinks. When you click that red asterisk, it will open up the page belonging to that link in the edit form, without actually loading that page first. Imagine going to any section page, and without loading the target page, click this "magic" asterisk next to any link to open up that link in the editor! I only started using this a day or so ago and it already saved me hours of time - time otherwise I would have spent waiting for pages I wanted to edit to load. If you are familiar with Rob Snell's Magic Edit button (described in our Yahoo! Store Tips & Tricks book), this is like the Magic Edit button on steroids.
Read more about it at Rapid Edit.
http://ytimes.us-dc1-edit.store.yahoo.net/RT/NEWEDIT.ytimes/d695ff542abb/CD7fAAIJ (just an example)
erase CD7fAAIJ and add ind.html?dired=1 to it so it looks like:
http://ytimes.us-dc1-edit.store.yahoo.net/RT/NEWEDIT.ytimes/d695ff542abb/ind.html?dired=1
and hit Enter. This will take me to the edit form of the ind.html page - in this example but without loading the page itself. This is all great provided that you know the ID of the page you want to edit. But what if you don't know the ID?
Rapid Edit to the rescue!
I came up with a very useful template that can be installed into any Yahoo Store, and while in the store editor, it will put a red asterisk next to all text hyperlinks. When you click that red asterisk, it will open up the page belonging to that link in the edit form, without actually loading that page first. Imagine going to any section page, and without loading the target page, click this "magic" asterisk next to any link to open up that link in the editor! I only started using this a day or so ago and it already saved me hours of time - time otherwise I would have spent waiting for pages I wanted to edit to load. If you are familiar with Rob Snell's Magic Edit button (described in our Yahoo! Store Tips & Tricks book), this is like the Magic Edit button on steroids.
Read more about it at Rapid Edit.
Subscribe to:
Posts (Atom)
