Need some sorting help with menu index in ditto

Hi, after searching , and playing around for a few hours, I need the ouput the ditto to match the document tree menu index exactly to make my client happy.

running mysql 5.0.90 so it’s not the mysql bugs

doc tree order for the catagorys
shop (51)
summer (219)
necklaces (220)
earrings (221)
bracelets (222)
spring two (168)
spring (58)
Listing for The Onion Tree (198)
necklaces (60)
earrings (61)
bracelets (59)
pearls (68)
necklaces (70)
earrings (71)
bracelets (69)


What i dont get, is why


doesn’t output properly i think.

It should and the desired output is to output all products in category summer necklaces, then all products summer earrings, then all products in summer brackets, then the spring category ect.

but instead it gives me the listing all products with a menuindex of 1 from all the categorys, then all products with menuindex of 2.

http://www.jewelrybyharlow.com/shop.html is the page working on

i need each category’s products displayed in whole as it’s listed in the document tree.

current ditto call


This gets me close to whats wanted but not correct, it just happens most of the doc ID’s are in same order as the menu index at the moment.

Any help, or links would be much appreciated

if i need to make a new template for the category container pages to have a different ditto call, let me know. currently shop, category container pages, and product pages (just a container for the TV’s) all use the same template.


I have also noticed that if a category is unpublished, but still has published children. they will be displayed. even though it’s set to only show published items. if the parent is unpublished, shouldn’t it not show anything in that sub folder?

I have also noticed that if a category is unpublished, but still has published children. they will be displayed. even though it’s set to only show published items. if the parent is unpublished, shouldn’t it not show anything in that sub folder?

&seeThruUnpub=`0` should get you out of jail on this one.

&showInMenuOnly=`1` if all else fails and untick the ones you don’t want to display.

You can use a TV to set the order, so how about an uberMenuIndex tv of you own, say "displayOrder", using a large offset for each category. So "summer necklaces" starts at 100, "summer earings" at 200, "summer braclets" at 300, "Spring necklaces" at 400 etc., making sure you have gaps where future categories may be needed.
The downside is ensuring you have enough space to fit in the category you didn’t predict you’d need, and a lot of work renumbering if you decide to swap a couple of categories around.
KP

In using a TV for the display order, it creates extra work on the clients end to make sure the display order of the products is always correct, and then always double checking the product listings to make sure the right numbers are in, ect. i just see my client complaining about this. of course this a method that can work, it just seems like there should be a better option here. I’m just not seeing it.

it’s easy for the client to change the menu index of an item and can see it’s order from the document tree.


My next thought is that some kind of nested ditto call is what will do the trick. but i’m having a brain fart thinking of how to implement this.

Or i guess a tv for the display order of the category pages. which is easier to maintain than a order TV for each product.

Guess time, to find time to tinker with it more.

Quote from: hotdiggity at May 26, 2010, 04:13 AM

I have also noticed that if a category is unpublished, but still has published children. they will be displayed. even though it’s set to only show published items. if the parent is unpublished, shouldn’t it not show anything in that sub folder?

seeThruUnpub=`0` should get you out of jail on this one.

&showInMenuOnly=`1` if all else fails!!

Awesome that did the trick. Thanks a ton

If i understand you correctly (and without knowing the doc depth required), I think kp52 was on the right track. By using menuindex instead of a TV, it might look similar to this:

shop (51) MI=0
summer (219) MI=100
necklaces (220) MI=101
earrings (221) MI=102
bracelets (222) MI=103
spring two (168) MI=200
spring (58) MI=300
Listing for The Onion Tree (198) MI=301
necklaces (60) MI=310
earrings (61) MI=320
bracelets (59) MI=330
pearls (68) MI=400
necklaces (70) MI=410
earrings (71) MI=420
bracelets (69) MI=430

A quick fix I know, but it should give you some flexibility with inserting products/categories.

I started thinking along the lines of big numbers for the actual menu index, but wasn’t sure how big it can be (now checked - a ten-byte integer should cater for quite a big business), and also because you would have the convenience of DocManager for major reshuffles. Then I realized DocManager would renumber everything from zero again when you saved it. Bit of a risk, really.

I’m sure you can achieve the net result of a single Ditto call producing the categorized products in order of their plain, simple menuindex plus offsets from their parents (and grandparents?) by using a wrapper snippet for the call with a calculation to look up the relevant values for each product. Sorry I won’t have time today to play around with the idea.
KP