Attribute weight range restricted

Yeah, I think the default range for weights is -10..10. I know that if I make this claim, someone's going to challenge it, but a range of -50..50 should be enough for anybody. That's how much room the menu admin pages give, so it should work here, too. I'm also changing the classes used for tabledrag to describe the field they are actually on.

#1 Works well.

I've run into this before and +/- 50 seems sufficient to solve the issue.

Ben, interesting approach for a more generic weight_range solution.

Alright. Patch committed.

This patch simply extends the same fix to the Product > Attributes form (node/%/edit/attributes). I think I've run into of those rare use cases-- my client has a complex form accompanying the product which requires many (many!) attributes.

Please change the CSS class to ...table-ordering instead of ...table-weight, as was done in the original patch in #1.

Actually, I did change it, but it seemed that when set to 'uc-attribute-table-ordering' the drag events weren't firing properly (Firefox 3). That is, when I'd click to drag, the table row would "stick" to my mouse, even after I released the button. I didn't have time to try to figure out why. It resumed its normal behaviour after I changed it back to -weight.

You probably missed changing it at one spot in the code.

Can you clarify? I tried it again, and got the same result. Is there a conflict elsewhere, something else I should be changing? Looked to me to be pretty straightforward.

Ah, of course. That accompanying theme function. My first patch, so be gentle. :) Try this:

Patch should be created from the root dir of ubercart.

I think a delta of 50 could be too much? If there's 100 attributes how many options will there be! Maybe a delta of 25?

@fenstrat: Can you clarify? The patch was created from ubercart/uc_attribute/uc_attribute.admin.inc. And my client has around 35 attributes-- simple form fields, few with options. Not the most ideal application, I'll admit, and not one I anticipated when I handed it over-- it's a membership form. I was expecting it to be set up as a downloadable file after purchase. If there's an add-on module that handles this type of scenario, I'd love to hear about it.

Thanks for your patience!

No worries. Look at the patch in #1, the path to the modified file starts from the root dir of ubercart. This isn't a requirement but good practice when creating patch files for a given module.

A delta of 25 would still allow 50 attributes - that'd be enough to get in the 35 you're talking about. I just think 100 attributes is too many and points to needing another solution.

To that end you may want to look at uc_node_checkout which is designed to handle things like membership by allowing you to purchase the rights to create a piece of content.

Thanks for the advice. Much appreciated.

Patch modified as suggested:

The patch in #16 the same as the patch in #12

Yep #16 is the same as #12 apart from the fact that the patch in #16 is made correctly - i.e. from the root dir of Ubercart.

Can we get the delta changed to 25?

Patch didn't apply to 2.x-dev. Here's a reroll.

This will need to be forward ported to 3.x

#20 is a simple reroll of #19 so going to mark as rtbc.

Delta of 25 sounds good to me, but I think we should also use it on the main attributes admin page. When new products are given attributes, those values are copied over, and someone probably doesn't want to reorder their umpteen attributes over and over again as they're making products. The change looks like it should be made in uc_attribute_form().

Good catch, here it is again with a delta of 25 on the main attribute admin page.

Also noticed a stray delta of 50 missing from the main attribute option edit form.

Committed, needs porting to 7.x.

Committed to 7.x.

Sorry to ask but why limiting it to a delta of 25 (thats 50 attributes no?) I have a case where i have to have countries as an attribute.. thats 200+ countries (options)... another where I have states/provinces which is over 75 options... and anytime I make a change to either of these options i have to manually go into the database each time and try to 'fix' the sorting. Agreed its not a 'usual' situation to have that many options, but it does happen... Does having a higher delta really affect performance or could a 250 delta be used without hindering performance? It really is a drag to have to keep manually editing the database weight everytime you make a change...

The current limits are 50 attributes (delta 25) with 100 options (delta 50) each; this patch only changed the attributes and not the options. I don't see why the options limit couldn't be increased, but the attributes limit has already been discussed in #13 and #15 and I am wary of increasing this any further.

Oh I see, I misunderstood then, sorry. Yes I meant the options per attributes should be increased.. it has the same -10 .. +10 range (or did)... and for me thats caused a lot of problems with large options lists like States, Countries.. etc.

The committed patch in #23 ups the attributes from 20 to 50 and the options from 20 to 100. I'm not sure of any performance implications of upping it more. However I'd still say that having over 100 attributes is too many and points to needing another solution.

Also, you can use hook_form_alter to up the delta if your special case needs this.

I don't think there are any particular performance implications, just a usability issue - 100+ items in a dropdown or radio buttons in a set is not going to be particularly friendly.

Agreed.

Agreed as well... but necessary in my case. I have to have a dropdown of Countries... and there are well over 200+ countries...

So this points to another post/point I made... we need a way to be able to user other controls than the ubercart built in ones of dropdown list, text box, check box... etc...

Something like being able to use the "Date" module for example which is a great module for picking dates complete with pop-up calendar, and configurable to dropdown lists for months, days, years, hours, minutes, secs.... or the "Countries' module which builds a dropdown list of countries for plug-n-play input... or even the "Address Field" module which created a mini-form for xnl formatted international addresses...

It would REALLY open up the options (and simplify the administration) if we can specify these for options... instead of creating a dropdown list for Countries and having to put in something like 248 separate country entities, just drop in the "Countries" control... instead of having to create "month", "day" ,"year", "Hours", "Minutes" "AM/PM" drop down list with all its options, just create one "Date" control which handles all of it. Instead of having to created "address 1", "address 2", "city/town", "state/province", "zip/postal", just use the "Address Field" control and it will handle all of the necessary options.

I realize it might be a lot of work to implement such capabilities but they have done this in Drupal Commerce and it was really impressive... It would allow for a high level of flexibility and low maintenance/administration to set up complex options for products (not all options are as easy as 'black/white/red/green/blue").

As fenstrat notes in #29 you could write a custom module that implements hook_form_alter() and increases the delta for your case.

Regarding extending the attribute system, this is something I've thought necessary for some time, but haven't had time, money or inclination to do so. I suggest you open a new feature request, as it's way outside the scope of this issue.

BTW: I should note these are not just theoretical possibilities... I am working on a site for a client who sells custom published horoscope books which require users to input their date/time of birth and geographic location at time of birth so the forecasts can be customized more granularly to the purchaser, which involved creating 15 attributes and like close to 400 options to those attributes (which is a lot of maintenance)... and to make matters worse, they also sell 'relationship' books/horoscopes so it involves not just inputting the purchasers information (15 attributes/400 options) but their partner as well (another 15 attributes/400 options) which was truly tedious and time consuming to do (and open to mistakes obviously which had to be carefully tested for spelling of countries, states, sort orders which had to be manually done through the database table since any attribute with more than 20 options gets messed up sort-wise on save.. all options after +10 became +10 throwing off sorting)... The current system for attributes is just far too limiting. The thing that bothers me most is when the client will have to take over maintenance of their system and make any adjustments/changes... they do NOT have the capability to manually edit the database to fix sorting which will cause them grief.

@JohnDoranNY, sounds like uc_node_checkout was made for your situation.

Only available for v6, in his post about drupal 7 the author said he has no plans to port to v7... and reading the description I am still unsure what it exactly does :D

uc_node_checkout allows customers to "buy" nodes. That way you create a content type, add fields to it with cck, then allow the customer to "buy" the right to create nodes of that type. It appears someone has made a start of a D7 port #1172060: UC Node Checkout - D7 Port.

If you're building on D7 you might also want to look at http://drupal.org/project/commerce