Let admin push class attribute/option changes out to existing nodes

Do you think this should be a constant message, or just a one-time notice that appears when the product's attribute form is submitted? I don't know if anyone actually does it, but it's conceivable for someone to intentionally leave off the product options because they want the text field for that product.

I agree. For what I do it is much easier to uncheck the items that are not used. Since people have already set certain options for the attributes, I think they would expect them to by enabled by default for that attribute.

I agree that having the options checked by default would be a big time-saver and it makes sense for my purposes.

I've got the same problem, although I don't seem to be able to resolve it either at a global level for the attribute or at a specific level for the individual product. Both are set to Drop down box and I end up with a text field.

I'm going to reassign this issue b/c it's more a feature request now than a bug report. I like the idea of having global defaults that get pushed out to products, though it sounds like there was some interest in changing the way options work by default. The attached patch can be a beginning to addressing the situation... it allows you to do this for D6, and we can see if cha0s can re-roll it to change it so options are enabled by default. This patch itself needs testing, too.

(Pasted from http://www.ubercart.org/forum/support/6321/refresh_all_products_after_ad....)

webchick, your feature request in #5 has been granted as of #326352-6: Document Enabling Product Attributes. I decided it was the most common use case, but it's not really part of this issue's scope. Perhaps it will alleviate it some.

I'm not 100% sure on this, and Eaton would know better than me (cause he was the one giving the talk at DCC) but I think that views2 administrative actions (I can't even remember the name for certain ... still gotta get my notebook I left down there :P) will allow us to do things like this, like batch operations modifying some aspect of a node. We probably just have to define some action to views to allow that.

Wanted to post the patch since the discussion has moved here.

I'm marking it as CNW because Postgres doesn't have any way to do ON DUPLICATE KEY UPDATE. Even though the update doesn't do anything, there isn't even INSERT IGNORE available.

The comment next to the default option raises an interesting problem. Should there be a similar mechanism to push options out to the products as well? I'm starting to realize the serious limitations of the API. As is, you still have to go to each product to enable all of the options for the attribute, even though this is taken care of when the attribute is added to the product through the form.

I think I have a more recent version of this patch here.

Patch was great, but uc_attribute.module has changed a lot since then. I tried merging a patched version of the file with the latest, but far more has changed than I am familiar with. Can someone else who is more familiar with this module give it a shot? Would be most appreciated!

Thanks!

.:Joshua

I'd be very interested in this functionality as I have literally thousands of products and it will be a major headache going into each and every product to add the attributes for each!

I tried downloading the latest version of dev and applied the patch (manually, automatically didn't work as with Joshua) and I got the checkbox that says "Push this attribute to these product classes"... But for some reason even when I ticked this it didn't work?

Here are the steps I took:

1. Created a product type (class)
2. Created a new product (node/add) of that product type
3. Went to the attributes and added an attribute "Flavour"
4. Ticked the new class under "Push this attribute to these product classes" and submitted the form
5. Added options for the "Flavour" attribute
6. Went to the product (node) for the new product type but no "Flavour" dropdown was present
7. Clicked the product type (class) attributes and noticed no "Flavour" attribute there already either (I guess which is why the product itself had no dropdown)

Did I miss something? I have a feeling I have... But can't think what? I also tried adding an attribute directly for the product type and selected the "Push this attribute..." but that didn't do anything either.

Any ideas?

By the way I'd be more than happy to help test (and even contribute if I can get my head around the code ;)) any patches etc... So let me know if there are any further steps I can take to help get this feature on the go! :)

Thanks :)

Attaching new patch.

Some documentation:
This patch will allow to flush products attributes. Under flush I mean that product attribute settings set on node level will be ERASED and then class settings will be applied/

• BACKUP your database & files
• Apply patch
• FLUSH CACHE
• Edit any product class and set necessary attributes with options
• Patch should add "Bulk" tab when you're on class edit pages
• Click on bulk menu item
• Check products you want to flush

drupalprojects,

Thank you SO MUCH for this patch!! It worked perfectly for me. Absolutely great and just how I imagined/hoped it would work!! The only issue is that I couldn't actually apply the patch automatically (I'm using TortoiseSVN) but by applying it manually everything seemed to transfer over so thanks!!

Setting the status of this to "reviewed & tested by the community" however if anyone has any issues with the patch then feel free to change it.

Hoping this can get adopted soon :)

This worked fantastic for me also. As already mentioned, I needed to manually apply the patch, but that was probably more of an issue with my environment than the patch file. Thanks so much. This has saved me a ton of time.

This patch #18 is absolutelly brilliant and perfect
This must be committed into ubercart.
Thank you very much !!!

Where and how?

Where does this patch go exactly. folder and file? I am not a developer, sorry if this is obvious to everyone, bu not to me...

Henrik

How to apply a patch to a module - beginner's version
http://drupal.org/node/620014

Can I copy paste the code or do I need Cygwin? If yes, where does the code go?

@hebhansen,

You can also use a subversioning tool (such as Tortoise SVN) which is how I create/apply patches personally.

If you'd like you can do it manually... All you have to do is open up the .patch file and look at which file needs changing (some patches have multiple files in one patch) and then work out where in that file the patched code needs to go...

Lets look at the first bit just as an example, as that may be a bit clearer... The first 13 lines are:

diff --git uc_attribute.admin.inc uc_attribute.admin.inc
index 243e10a..878e8b6 100644
--- uc_attribute.admin.inc
+++ uc_attribute.admin.inc
@@ -174,6 +174,58 @@ function uc_attribute_delete_confirm_submit($form, &$form_state) {
   }
 }
 
+function uc_bulk_attributes_form($form_state, $object)
+{
+  $form = array();
+  // select all products with current class
+  $node_type = $object->pcid;

You can see from the 3rd and 4th lines which file is being changed (uc_attribute.admin.inc) so open that file. Near the end of line 5 you can see:

function uc_attribute_delete_confirm_submit($form, &$form_state) {

All the lines prefixed with + are the newly added lines... So you can see that function uc_bulk_attributes_form($form_state, $object) needs to come directly after function uc_attribute_delete_confirm_submit($form, &$form_state).

Keep going through the patch file until you've gotten to the end. Also note that lines prefixed with a - are lines that need to be REMOVED. There are none in this particular patch file, but it's worth noting for future use...

Obviously this method is a lot more time consuming (and is prone to errors!!!) so I'd only suggest using this method if the patch file can't be applied any other way. If you are going to try the manual way I'd also HIGHLY SUGGEST you make a backup of the original file before trying to change it to include the patch...

But seriously, Tortoise SVN (and I'm sure other subversioning tools) are your friends when it comes to this... They do all the hard work for you, so I'd recommend looking into that... It's not very complex :)

Best of luck and hope that helps :)

Thanks a lot Marc. Just what I needed :-) and did not know. I will go the Cygwin way . I thought this was likke adding a script.

Tried out Cygwin and requires urls and more. Chesked the link above and FAQ at cygwin, I am still a "?" what url will cygwin need for this?

Sorry for using this thread.

Or is this patched to a module/file/folder anywhere for me to grab?

I've tested the patch and it worked, but not quite in the way I would have liked that it worked. If I only change the price of an option, not only that price get flushed, but everything get flushed. That's okay if all the products needs the same attributes and options, but not if there are products were some options should not have been available.

An example:
Let's say we have a product class for t-shirts. T-shirts can be available in some colors and there are differences in the prices per color.
Colors and prices:
- white (+$0)
- red (+$0.5)
- green (+$0.5)
- blue (+$0.5)
Then I create some t-shirts-products. T-shirt 1 and t-shirt 2 are available in all the colors, but t-shirt 3 is not available in the color green.
Suddenly the price for red-colored t-shirts changes. The price for red-colored t-shirts is now (+$1). I change the price in the product class and choose the bulk-update. The prices for all the t-shirts got updated, but suddenly t-shirt 3 is available in green!

So I think the attributes and options should be organized in a different way (like it has be done in Views for example, with overriding or using the defaults), or there should be an option to only update the prices or even only update one option.

you are right MegaChriz
we need to add an "override" checkbox to attribute options in each product.. so.. if the checkbox is active.. the bulk operation would have to ignore to update attributes for that product.

Thanks for info, guys. I will see if I can make it a bit better.
Small donations also welcome :)

I also just need to add my *THANKS* to drupalprojects and others for updating this for Ubercart 6.x-2.2 (patch #18 worked great). I was about to abandon Ubercart and Drupal because of this issue. There was no way my client was going to manually update hundreds of products every time her "Color Attribute" chart changed (which is fairly often). It was a complete deal breaker until I came across this patch. Thanks again for saving my project. They definitely need to get this into core.

Adding to successful testing of patch in #18, and adding to all the thanks as well! Hoping it's moving towards a commit, as this seems essential.

The behavior described in #28 indicates this patch still needs work. Also, the naming of the new functions is wrong - these are part of the uc_attribute module so should be prefixed by uc_attribute, not uc_bulk.

I think fixing for #28 would come later as a different patch. And surely this would need a warning and document that stuff like #28 could happen.

cf. #591160: Ordering of attribute options - not saved when added to product before forcing order

In reply to hedac:29, rather than an "override" checkbox, maybe have a "preserve existing" nomenclature/logic instead.

Has there been any more thought in how to make this work when using Postgresql? #12 seems to imply that this patch won't work for Postgresql.

The most recent patch, #18, doesn't use the MySQL-specific SQL that was mentioned in #12. No one has reported a problem with #18 on PostgreSQL, so if that's something you can check it would be appreciated. However, as I said in #33, there are still problems with what this patch does - it seems it can do more harm than good in some cases.

I agree that if the behavior in #28 is happening, which based on the code it would, it still needs work. for my purposes it worked great since i just needed to push out a new attribute to previously created nodes, all of which share the same attributes. i'll keep an eye out for an update on the other issue described, but just wanted to say thanks that the patch worked like a charm for me.

Yes, add "override" to each product is not a good option,

The "preserve existing" should be better.

I have a backup before I click the flush button, so I can restore the db after it, otherwise there would be a "disaster" for me, as I have over 150 products that all the attributes and options may lost after run the patch.

There should be a "WARNING" before you do it.

thanks

http://articlesforge.com

Your patch worked great! Installed it manually with no errors. The only question I have is, can I change the number of displayed products/nodes in the bulk view. I have over 20,000 products currently and its ever-expanding, so I would like to have it display them all at once, select all, then flush attributes ideally. Any ideas?

What about adding a 'update all?' checkbox in 'admin/store/attributes/%uc_attribute/options/%uc_attribute_option/edit'?

• If the checkbox is not checked, changes to an attribute's option will only affect future products.
• If the checkbox is checked, changes to an attribute's option will override all products that have that option (won't add or remove options from products like #18).

I think #18 is still very usefull for some but too aggresive for most.

Here are the proposed changes to uc_attribute.admin.inc.

  //add checkbox to edit option form
  $form['bulk_update'] = array(
    '#type' => 'checkbox',
    '#title' => t('Update All?'),
	'#description' => t('If selected, all products will be updated with options adjustments on this page.<br /><strong>Warning:</strong> all option adjustments set at product level will be overriden!'),
    '#default_value' => 0,
    '#weight' => 4,
  );

     //update products option with new values
     if ($form_state['values']['bulk_update'] == 1) {
       db_query("UPDATE {uc_product_options} SET cost = '%f', price = '%f', weight = '%f', ordering = '%d' WHERE oid = '%d'",
       $form_state['values']['cost'], $form_state['values']['price'], $form_state['values']['weight'], $form_state['values']['ordering'], $form_state['values']['oid']);
    }

Here is the patch for the above changes against Ubercart 6.x-2.x-dev as well as the patched uc_ubercart.admin.inc.

Testing...

Reassigning the issue, because patch #42 will undoubtedly need work but not before it gets reviewed...
(ok, ok, just a shameless bump really ;)

Subscribing, greetings, Martijn

I applied the patch that allows you to set a multiplier for attribute pricing, aka, I have a product that is $5, and if I select an attribute it make is $25 by multiplying $5 x 5.000.

This patch works great except if I apply an attribute to a class, then flush all the products, the attribute is applied to them all, but the price multiplier does not transfer.

What do I need to do to get this?

I was able to get it working by changing the 2 lines that have

(nid, oid, cost, price, weight, ordering)
to
(nid, oid, cost, price, multiplier, weight, ordering)

Works like a charm, now I have to sort some other issues with making a default attribute choice automatically select in the catalog grid view.

subscribe

subscribing.

subscribing

Has anyone tried patch #18 with Ubercart version 6.x-2.6 yet? I tried applying the patch locally on Mac but it failed:

$ patch < uc_attribute_1.patch 
patching file uc_attribute.admin.inc
Hunk #1 succeeded at 186 (offset 12 lines).
Hunk #2 FAILED at 1251.
1 out of 2 hunks FAILED -- saving rejects to file uc_attribute.admin.inc.rej
patching file uc_attribute.module
Hunk #1 succeeded at 155 (offset -1 lines).
Hunk #2 succeeded at 277 (offset -1 lines).

If anyone could upload working patched files that would be great thanks.

@howardbeale: Did you try the patch from #42?

@longwave: I hadn't done but just tried it now and it works yes. The reason I hadn't tried this one is because it only adds the option to update for changes to attribute options specifically, and not the rest of the attribute details. So the patch for a bulk update of everything would be ideal for me. Thanks for the input though

Ok for patch #18 I tried updating uc_attribute.admin.inc the old fashioned way and then patching only uc_attribute.module. When I tested bulk flushing for a class it erased all the attributes for the class and it's products rather than updating them unfortunately.

Has anyone got #18 working with a recent UC version? Thanks

*Edit: when I readded all the attributes to the class and did a bulk update it successfully readded the attributes to the products of that class. If I can narrow down the circumstances when attributes are erased I'll post them here

#18 is NOT going to get added to Ubercart because it has problems, as discussed above.

#42 is the patch being considered here.

#42 allows you to update an existing option, that's it. As advertised, it doesn't allow you to add a new option and push it out to existing products. And of course it doesn't allow you to add new attributes and push them out either. While #18 goes too far, #42 falls way short, is obviously inadequate for a lot of us, and hardly addresses the original intent here: allowing admins to push attribute and option changes to existing products.

Alrighty, here's a patch that combines and refines #18 and #42. I think we need to have both methods. The patch should apply to the latest dev release (place patch in main Ubercart directory and apply with -p1).

Like #18, it allows resetting/flushing attributes and options to the current class defaults. Like #18, this wipes out product level customizations only on the selected nodes. So the easy way to avoid the problem described in #28 is simply to not select any customized products when flushing attributes. Help text is now provided to explain what will happen. Also there's a 'flush all' button to reset all products in the class. This should work fine if you have several hundred products, but if you have several thousand to flush, I'm not sure it would be a good idea to use this button. The operation may take too long and something bad might happen. I suppose some sort of batch operation would be a good idea here.

Like #42, it also allows you to push out changes at the option values level. It enhances that method so that product class defaults are also updated with the new values on a bulk update, which is probably what people would expect.

Added bonus: a 'reset to defaults' button on product edit form (attributes tab) which resets that product to the default attributes and options for that product class.

Thanks to drupalprojects and cybis for providing their respective patches!

----------

One thing I noticed when messing around with this stuff. The table naming convention for attributes is not consistent, which may lead to confusion for developers. We have 'uc_attributes' / 'uc_attribute_options', then 'uc_class_attributes' / 'uc_class_attribute_options', yet at the product level we have 'uc_product_attributes' and 'uc_product_options'. While consistency purely for consistency's sake is often overrated, in this case it could be helpful to rename that last one to 'uc_product_attribute_options'.

Looking quickly at the patch, it seems that this could almost all be done in a separate module with form alters - I wonder whether we should split this out into uc_attribute_bulk_update or similar?

Regarding the table naming, yes it's not ideal, but we can't change this in a stable release as there may be existing modules depending on the current names.

I suppose it could be a separate module, but anyone who is going to utilize attributes will likely want some way to bulk edit them. So it seems to me that this should probably be an integral part of uc_attribute.

OK, fair enough. Patch is untested but looks good so far, except:

+  $result = db_query("SELECT n.nid FROM {node} n LEFT JOIN {node_type} nt ON nt.type = n.type WHERE nt.type = '%s'", $form_state['values']['node_type']);

Shouldn't this just be SELECT nid FROM {node} WHERE type = '%s'?

+    $message = 'Updated option %option.';
...
+      $message .= ' Bulk updates applied to all products and classes which have this attribute.';
...
+    drupal_set_message(t($message, array('%option' => $form_state['values']['name'])));

You can't use t() like this, as localize.drupal.org won't be able to pick up these strings for translation.

Updated patch to address issues.

Subscribing.

@jerry: Why not test the patch and tell us if it works for you or not?

Patch #63 works great.
This line was giving me an error:
drupal_set_message($message, array('%option' => $form_state['values']['name']));
Changed to this
drupal_set_message(t($message, array('%option' => $form_state['values']['name'])));
Also added some line breaks in the instructions on the product class bulk updates page to increase readability.

As longwave pointed out above, that's the wrong way to use t(). Sorry, I just removed the t() without thinking about it and didn't test again. We should do this on line 524:

$message = t('Updated option %option.', array('%option' => $form_state['values']['name']));

then, after conditionally appending to $message, on line 532:

drupal_set_message($message);

That'll teach me to read the thread a little bit more carefully...

And yes, obviously, fixes #67 works great.

patched with .diff in #58, and working great. Exactly what I was looking for. Subscribing for future updates.

#63 works well over here too.

Thanks for testing. Here's an updated patch with proper t() handling and the readability improvement by cybis. Also re-worded the help text for better clarity.

Just a very minor tweak to the help text.

I don't understand why that test failed.

#72: uc_attribute-bulk-edit-298395-72.diff queued for re-testing.

Testbot is ignoring patch in #73 because it ends with -D6. That's a magic name suffix that tells the bot to ignore the patch - this naming is usually used when you post a D6 patch in a D7 issue and don't want to try testing the D6 patch against D7.

@SeanA: Can you repost your patch in #73 without the -D6 in the name? That's the one that should be reviewed, right?

OK, here it is again. (I had added the -D6 ending because I thought automated testing wasn't useful for D6.)

Automated testing isn't useful for Drupal 6 *core*, because there are no tests in Drupal 6 core. Ubercart, on the other hand, has lots of tests for Ubercart 6.x-2.x.

Patch #78 works for me with 6.x-2.x-dev dated 31-OCT-11.

With a patch such as this which can potentially introduce destructive behavior, I'd really like to see more than a "works for me" review. It would be nice to hear that you read all the above concerns with the previous patches and verified that the current patch under consideration addresses those concerns and doesn't have any other complications. It would be great if there were some SimpleTest cases written for this new behavior.

#78: uc_attribute-bulk-edit-298395-78.diff queued for re-testing.

(Using this to test the testbot.)

#78: uc_attribute-bulk-edit-298395-78.diff queued for re-testing.

@TR, you are correct, this patch has the potential to be very destructive. This is why I submitted patch #42 as I found patch #18 too dangerous. In post #58, SeanA sums up the issue perfectly and explains his solution which he implemented in patch #58, #72 and #78.

I tested patch #78 both at the product class level and at the attribute option level and found no unintended behaviors. I looked to see if any unselected product classes or options were inadvertently affected and did not find any issues. It also left all my other attribute options, option’s images and dependent attribute settings alone.

I found the warnings and help texts adequate.

All in all I found patch #78 to behave as explained in post #58 with no unexpected behaviors. I can’t guarantee there is no issues but I looked and found none.

I am trying to implement this patch with Cygwin using this command:

diff < uc_attribute-bulk-edit-298395-78.diff

but, get the error message: diff: missing operand after `diff'

Anyone know the correct command?

Drupal 6.22
Ubercart 6.x-2.x-dev

Thanks

patch -p1 < uc_attribute-bulk-edit-298395-78.diff
"diff" is for creating diff files, "patch" is for applying them.

Thanks for the update but, with both Cygwin and PuTtyCyg I get:

bash: patch: command not found

I sure would love to use this. It would save me days of update work.

Thanks again,

Ralph

http://drupal.stackexchange.com/questions/15592/cygwin-patch-fails

I got it... I needed to update and install "patchutils".

To install patchutils in Cygwin you need to re-install by downloading the installer and selecting patchutils.

http://www.cygwin.com/install.html

When installing packages for the first time, setup.exe does not install every package. Only the minimal base packages from the Cygwin distribution are installed by default. Clicking on categories and packages in the setup.exe package installation screen will provide you with the ability to control what is installed or updated.

You will find the Patch plugin under: Devel, Default > patchutils: A small collection of programs that operate on patch files.

Thanks,

Ralph

New error...

$ patch -p0 < /cygdrive/j/domains/drupal6/sites/gardenofbeadin.com/modules/ubercart/uc_attribute/uc_attribute-bulk-edit-298395-78.diff
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -urp ubercart-2.x-dev-20110829/uc_attribute/uc_attribute.admin.inc ubercart-2.x-dev-20110829--298395/uc_attribute/uc_attribute.admin.inc
|--- ubercart-2.x-dev-20110829/uc_attribute/uc_attribute.admin.inc 2011-08-28 15:08:32.000000000 -0400
|+++ ubercart-2.x-dev-20110829--298395/uc_attribute/uc_attribute.admin.inc 2011-09-17 04:12:41.000000000 -0400

Anyone have any ideas?

Ralph

patch -p1 ...

I tried that, same error...

$ patch -p1 < uc_attribute-bulk-edit-298395-78.diff
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -urp ubercart-2.x-dev-20110829/uc_attribute/uc_attribute.admin.inc ubercart-2.x-dev-20110829--298395/uc_attribute/uc_attribute.admin.inc
|--- ubercart-2.x-dev-20110829/uc_attribute/uc_attribute.admin.inc 2011-08-28 15:08:32.000000000 -0400
|+++ ubercart-2.x-dev-20110829--298395/uc_attribute/uc_attribute.admin.inc 2011-09-17 04:12:41.000000000 -0400
--------------------------
File to patch:

Learning how to apply patches is outside the scope of this issue, please can we just keep this to discussion about the patch itself.

What directory are you in when you run the command? You need to be in the main uc folder (e.g. [drupal_root]/sites/all/modules/ubercart)
i.e.

cd /full/path/to/ubercart
patch -p1 < /full/path/to/patch-file.patch

Maybe there's an issue with backslashes vs. forward slashes? I'm just guessing, mind you - I don't use windows or cygwin.

That did the trick! With a trailing forward slash. I had the patch in the uc_attribute directory instead of the ubercart directory.

cd /cygdrive/j/domains/drupal6/sites/gardenofbeadin.com/modules/ubercart/

patch -p1 < uc_attribute-bulk-edit-298395-78.diff

Thanks you very much! This is going to save me a lot of pain.

Ralph

@Inifnitee: Now you're got the patch applied, reports of whether or not the feature actually works for you, or any bugs you find, would be greatly appreciated.

Works like a charm! I updated over 2,000 options on 400 products in less than 1/2 hour.

One thing that I think would make things even easier is... if, as well as having the "Update all products?" check box on the individual option admin pages, it would be great to have one on the originating Attributes admin page so that you could update all options and then apply to all associated products with one click from the Attributes admin page instead of each option admin page.

For products that have many and multiple attributes and options this would be very advantageous.

Thanks again,

Ralph

@Infinitee, did you take a look at the product class bulk update feature included in this patch? (admin/store/products/classes/your_product/attributes_bulk)
I think you may be able to accomplish what you described using that feature.

On my (admin/store/products/classes) I have "No product classes have been defined yet."

"No product classes have been defined yet." This must mean you are using the built-in Ubercart 'product' content type instead of creating a product class (content type) for your site. In this case you won't be able to use the bulk update feature.

(It's outside the scope of this issue, but it should be possible to create a new product class and switch your existing nodes over. You would have to manually hack the database so making a backup and being able to restore it if something gets messed up is Not To Be Avoided. See http://www.ubercart.org/forum/support/1837/change_product_class and if you need help doing this, you can ask on the Ubercart support forum, but please not in this issue.)

Is this function going to commited to the module, or is it going to remain strictly as a patch?

It will be committed when the maintainers find time to test and apply it. Further reports of whether it works or not from anyone who tries it out are appreciated, and will help get it committed more quickly.

#78 works for me, applied with 'git apply'

@Inifnitee
Thank you for putting exactly how you got the patch to apply, I have been fighting cygwin for a while. Worked perfectly.

@SeanA
You are a life saver!!! I have a site that has 14 different catalogs that use attributes. I would have been like 10,000 items that I would have had to update manually. This patched worked perfectly. I also think that this should be added to ubercart core.

Works for me too. I rearranged the code a bit and added a test, though only for the "update existing products" checkbox.

This patch adds more tests, a confirmation form to the "Reset to defaults" button on the node attributes page, and a few other minor cleanups.

Committed #106. Thanks to everyone who contributed to this issue!

Next step: porting to 7.x.

Subscribe -

Any progress on a D7 patch for this issue?

#106: 298395-uc_attribute-bulk-update-106.patch queued for re-testing.

Subscribe. Would be great to see this in D7.

Would also love to see this ported to D7. Would also love to see the uc_attribute module revised to allow multiple SKU's to be added to the cart (the original product SKU and the attribute SKU) and integrate each with the out_of_stock module.

I know this is a long shot but this functionality would be really handy. Any plans to port this still?

This functionality already exists, but only for product classes, not the default "product" node type. I'd love to be able to do this to all "products" separately from the other classes. 99% of my items are just "products" and I only create 1-2 classes for special items, so there's no reason to have bulk attribute changes for the classes, but rather the regular products.

I do use product classes actually and have not been able to find the option of allowing me to push the changes across all products within that product class. I am using Drupal 7 and UC 3.x

Sorry, my mistake. It works only in D6.

I would like to see it working in Drupal 7, but my other request still stands as well.

haysuess, in #115, it's been a long time since I looked at this, but I believe there's no way around creating new product classes in order for this patch to work. It's basically hardwired into Ubercart that way. Something like that. Anyway, you can manually convert your generic 'product' nodes so they have a proper product class, it's pretty painless using phpmyadmin, but backup your database first! Instructions are around here somewhere...

I don't use D7 much myself but I'm willing to do the work for pizza and beer money. How many on this thread are willing to pitch in 5 bucks to see this happen? 10% of all proceeds will be donated to the Drupal Association.

Guess there's not a lot of enthusiasm for funding work on this. =) Nonetheless, I'll port this to D7 sooner or later.

Dropdown Attributes for Drupal 8 fully implements attributes for product classes as of 8.x-1.0-alpha2. If a product does not have attributes defined then the attributes for the product class are loaded. If attributes for the product class are changed or deleted then they take effect immediately. There is no need to "push" them because they are the attributes that are loaded. If you want to override the attributes for the product class then define attributes for a particular product as those take priority.

The full support for attributes for product classes is provided by Dropdown Attributes even if you have no need for specifying dependencies between attributes. It is necessary because editing dependencies for every product is not reasonable for hundreds of products.

I have not backported this to Drupal 7 but it would not take long if there is interest.