It would be awesome if product attributes could be individually exposed to Views.

Although the potential to leave out attributes by accident is possible, this would significantly improve the ability to create a step-by-step product configuration process and add the final result to our cart with little to no store modification.

In doing this, it may be necessary to add a customizable "Next Step" button; like the "Buy it now" button already available to Views.

Anyone else that's interested in this, I'd like to see your feedback as well.

CommentFileSizeAuthor
#113 ubercart-n895236-113.patch21.98 KBDamienMcKenna
#113 ubercart-n895236-113.interdiff.txt803 bytesDamienMcKenna
#108 895236-n108.patch21.92 KBhanoii
#108 interdiff-107-108.txt8.81 KBhanoii
#107 interdiff-76-107.txt21.09 KBhanoii
#107 895236-n107.patch22.33 KBhanoii
#99 ubercart-uc_attribute-views-895236-99.patch22.33 KBjoelstein
#95 ubercart-uc_attribute_views-895236-95.patch23.62 KBbisonbleu
#94 ubercart-uc_attribute_views-895236-94.patch23.81 KBbisonbleu
#92 ubercart-uc_attribute_views-895236-92.patch22.52 KBbisonbleu
#83 ubercart-uc_attribute_views-895236-83.patch21.75 KBbisonbleu
#76 interdiff-64-76.txt529 byteshanoii
#76 ubercart-uc_attribute_views-895236-76.patch22.21 KBhanoii
#70 ubercart-uc_attribute_views-895236-70.patch22.21 KBsin
#64 interdiff-59-64.txt1.56 KBhanoii
#64 ubercart-uc_attribute_views-895236-64.patch22.19 KBhanoii
#63 mattbk_view.txt8 KBmattbk
#62 dropdown.PNG11.91 KBmorybel
#62 attribute.PNG11.88 KBmorybel
#59 ubercart-uc_attribute_views-895236-59.patch22.05 KBhanoii
#59 interdiff-57-59.txt1.76 KBhanoii
#17 uc_attribute_views_filter-895236-17.patch3.76 KBsin
#20 ubercart - uc_attribute.zip12.6 KBhockey2112
#23 895236-exposing-cost-weight-price-attributes-on-views.patch2.91 KBhanoii
#25 895236-exposing-cost-weight-price-attributes-on-views.patch2.91 KBhanoii
#28 895236-exposing-cost-weight-price-attributes-on-views.patch2.91 KBhanoii
#31 895236-31-exposing-cost-weight-price-attributes-on-views.patch2.93 KBhanoii
#32 895236-32-exposing-cost-weight-price-attributes-on-views.patch0 byteshanoii
#33 895236-33-exposing-cost-weight-price-attributes-on-views.patch3.28 KBhanoii
#39 uc_attribute_views_filter-895236-39.patch3.66 KBsin
#42 attribute.png31.07 KBbellagio
#49 ubercart-uc_attribute_views-895236-49.patch21.21 KBhanoii
#53 ubercart-uc_attribute_views-895236-53-U39-do-not-test.patch1.25 KBhanoii
#54 ubercart-uc_attribute_views-895236-54-U39-do-not-test.patch21.3 KBhanoii
#56 ubercart-uc_attribute_views-895236-56.patch22.25 KBhanoii
#56 interdiff-49-56.txt3.23 KBhanoii
#57 interdiff-56-57.txt1.43 KBhanoii
#57 ubercart-uc_attribute_views-895236-57.patch21.83 KBhanoii
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

devkinetic’s picture

I second this, disappointed that I can't create views that lists a nodes attributes

wjaspers’s picture

Whoops, I guess I didn't look close enough at other modules available.
To all interested, we may want to try out Ubercart Views.
There's a sub-module which provides some of this functionality.

EDIT: It looks like the module stated above provides access to these things in "Views"; however, the "Attributes" access is more-or-less the output of a configuration for a particular product. This module doesn't appear to provide the ability to selectively display product's attributes during the "add to cart" process.

TR’s picture

Version: 6.x-2.3 » 7.x-3.x-dev
Issue tags: -views, -product attributes

This should be implemented in 7.x-3.x first.

webhippies’s picture

Any news about this?

benitezv1ang’s picture

how are we doing with this Issue

DanZ’s picture

It appears that nobody is working on this. While this sounds like a great idea, I know that I have too many other projects that are higher priority. I expect that the other contributors are in the same situation.

In other words, if you want this to get done any time soon, the best thing to do is to write a patch yourself, or hire someone to do it. You will get support here if you do that. If you want to hire someone, see https://drupal.org/paid-services, https://drupal.org/drupal-services, and http://www.ubercart.org/forum/bounties for starters.

The first thing to do is to specify exactly where these will show up. Cart products, maybe? Start by describing exactly what a view using this stuff would look like and how it would be used.

jlockhart’s picture

I think this would be great as well, but I think for different reasons. For my clients, they want to be able to allow their customers to filter the products on a view based on the attributes the products have. My immediate need is a jewelry store that would like customers to be able to view all rings of a certain size. The sizes are attributes, but I don't see any ability to create Views Filters based on attributes (unless I'm missing something :) I can also see this being extremely important for clothing stores (show me all Large T-Shirts), housewares (show me all green flatware), etc.

I understand this can also be accomplished with taxonomies, but that requires double data entry and management if you want to use the attributes sku# and stock handling. I'm currently looking into how to create custom views filters but must admit its a bit above my pay grade. I'm reviewing the views documentation, but if anyone knows a great tutorial on getting started please message me.

Triskelion’s picture

I just started looking at the underlying tables with the intent of creating uc_attributes.views.inc. I found the roadblock.

Attributes will never be meaningfully exposed until the table uc_product_adjustments is upgraded. It presently records the product nid, and the adjusted SKU (model) along with an array of key:value pairs of the form Attribute ID => Option ID.

To expose this information to Views, this table will have to be changed to four fields (nid,aid,oid,model), so relationships can be established with uc_product_attributes and uc_product_options. Once this is done, exposing the attributes will be trivial.

Hopefully one of the maintainers who is familiar with uc_attributes can get back to this thread with some suggestions on how to proceed.

longwave’s picture

mattbk’s picture

Just wanted to add my support to this feature request. @Triskelion, if I knew how to start with that, I would :-(

hom3chuk’s picture

Doubling #7 and subscribing. This feature is a must.

acdtrp’s picture

Subscribing. Really need this feature.

mattbk’s picture

An additional reason for this is that I could then have a single SKU for a race registration (and therefore be able to use the stock module) but still split up the roster page according to division or other attributes.

Problue Solutions’s picture

also need this to use in conjunction with views data export to export attributes to a csv file

mattbk’s picture

Could the values in https://drupal.org/project/uc_who_bought_what be exposed to Views as a workaround?

varsharani’s picture

Thanks! But That is not compatible with drupal7 version.
I have four different size attributes and assigned different prices. how can view in only view instead of add to cart form. and it redirect to product page in drupal7.

sin’s picture

Issue summary: View changes
Status: Active » Needs review
FileSize
3.76 KB

Here is the patch to uc_attributes adding Views filter for each attribute. The filters are in Product group. It searches uc_product_adjustments.combination column for substring using LIKE. Works with exposed filters.

docans’s picture

I have installed the patch and it works.

I am trying to find a solution to this issue https://drupal.org/node/2202341. With the pathc i can see a way to filter products that have an attribute associated with them.

Is there a way to filter based on Attribute options that are in a cart. Please refer to the issue at https://drupal.org/node/2202341 for more details.

Thanks

hockey2112’s picture

I installed the patch from #17 and it did add the attributes as filters in the View. However, when I choose any of those attributes in my exposed-filter search box and run a search, it returns no results. I definitely have products that have those attributes assigned... what would cause them to not show up in the search results?

Basically, here's what I was expecting to happen:

  1. Product A has "blue" as an available option in its "Color" attribute.
  2. When I choose "blue" from the exposed filter for my Products view, Product A should show up in the search results since it has "blue" as an available option.

Instead, zero results were returned.

Here's a link to my testing site: http://192.185.163.44/~drupal72/?q=product-search
It is a fresh Drupal 7.26 installation with only these contrib modules installed:
Ctools (latest version)
Entity (latest version)
Rules (latest version)
Ubercart (7.x-3.x-dev from 2014-Jan-18)
Views (latest version)

Here's an export of my View, in case it might be helpful:

$view = new view();
$view->name = 'product_search';
$view->description = '';
$view->tag = 'default';
$view->base_table = 'node';
$view->human_name = 'Product Search';
$view->core = 7;
$view->api_version = '3.0';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['title'] = 'Product Search';
$handler->display->display_options['use_more_always'] = FALSE;
$handler->display->display_options['access']['type'] = 'perm';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'none';
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['row_plugin'] = 'node';
/* Field: Content: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['label'] = '';
$handler->display->display_options['fields']['title']['alter']['word_boundary'] = FALSE;
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = FALSE;
/* Sort criterion: Content: Title */
$handler->display->display_options['sorts']['title']['id'] = 'title';
$handler->display->display_options['sorts']['title']['table'] = 'node';
$handler->display->display_options['sorts']['title']['field'] = 'title';
$handler->display->display_options['sorts']['title']['order'] = 'DESC';
/* Filter criterion: Content: Published */
$handler->display->display_options['filters']['status']['id'] = 'status';
$handler->display->display_options['filters']['status']['table'] = 'node';
$handler->display->display_options['filters']['status']['field'] = 'status';
$handler->display->display_options['filters']['status']['value'] = 1;
$handler->display->display_options['filters']['status']['group'] = 1;
$handler->display->display_options['filters']['status']['expose']['operator'] = FALSE;
/* Filter criterion: Content: Type */
$handler->display->display_options['filters']['type']['id'] = 'type';
$handler->display->display_options['filters']['type']['table'] = 'node';
$handler->display->display_options['filters']['type']['field'] = 'type';
$handler->display->display_options['filters']['type']['value'] = array(
  'product' => 'product',
);
/* Filter criterion: Product: Attribute: Color */
$handler->display->display_options['filters']['attr_1']['id'] = 'attr_1';
$handler->display->display_options['filters']['attr_1']['table'] = 'uc_product_adjustments';
$handler->display->display_options['filters']['attr_1']['field'] = 'attr_1';
$handler->display->display_options['filters']['attr_1']['exposed'] = TRUE;
$handler->display->display_options['filters']['attr_1']['expose']['operator_id'] = 'attr_1_op';
$handler->display->display_options['filters']['attr_1']['expose']['label'] = 'Color';
$handler->display->display_options['filters']['attr_1']['expose']['operator'] = 'attr_1_op';
$handler->display->display_options['filters']['attr_1']['expose']['identifier'] = 'attr_1';
$handler->display->display_options['filters']['attr_1']['expose']['remember_roles'] = array(
  2 => '2',
  1 => 0,
  3 => 0,
);

/* Display: Page */
$handler = $view->new_display('page', 'Page', 'page');
$handler->display->display_options['defaults']['hide_admin_links'] = FALSE;
$handler->display->display_options['path'] = 'product-search';
$handler->display->display_options['menu']['type'] = 'normal';
$handler->display->display_options['menu']['title'] = 'Product Search';
$handler->display->display_options['menu']['weight'] = '0';
$handler->display->display_options['menu']['context'] = 0;

hockey2112’s picture

FileSize
12.6 KB

I'm still stuck. Here are the patched (and new) files. Can someone take a quick look and let me know if anything is amiss? Thanks!

sin’s picture

hockey2112, can you post records from uc_product_adjustments database table? The patch searches it, I guess you should have some sku assigned to attribute combination.

hockey2112’s picture

sin,

That was the problem... I did not have SKUs assigned to the attribute options. Once I assigned the SKUs, the exposed filters worked perfectly.

Would it be possible to allow the exposed filters to work when options do not have SKUs assigned?

Thanks!

hanoii’s picture

I am doing some work with uc_attributes and views myself. I was once a developer in uc_views and most of it got included in D7 so now I kept contributing patches to ubercart. I wanted to combine this patch and my own, but I found some issues with it. The main thing that I found is that the filter relies on the product adjustment table, which might not always be the case. You could have products with attributes that doesn't get ever to the adjustment table because they might not get it's own SKU.

The filter should rather apply to the uc_product_attribute_option table instead.

Only if interesting to someone, I am currently working in a master/slave set of sites in which one master ubercart site should feed product details to a bunch of slave sites. A lot of things is there but the output of attributes was missing. What I worked on was a way to output the price, cost and weight of each product option to views so that it can be added to a feed.

I was also accepted in uc_feeds so I will contribute some things there as well, but it already has some good attributes support.

I wasn't sure if I should open a second issue or share my patch here, so I am gonna start with here, if better to follow it up separately on a different issue, I can upload it then.

Status: Needs review » Needs work

The last submitted patch, 23: 895236-exposing-cost-weight-price-attributes-on-views.patch, failed testing.

hanoii’s picture

patch without that php error that was added accidentally

TR’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 25: 895236-exposing-cost-weight-price-attributes-on-views.patch, failed testing.

hanoii’s picture

I must have been tired with submitted and resubmitted previous patch, now for real, without the php issue.

hanoii’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 28: 895236-exposing-cost-weight-price-attributes-on-views.patch, failed testing.

hanoii’s picture

Status: Needs work » Needs review
FileSize
2.93 KB

Without the PHP notice

hanoii’s picture

Improved patch that adds additional fields to the weight handler of the attributes as well as adding more data to the field handlers for being float and sortable.

hanoii’s picture

hanoii’s picture

jodyfr’s picture

Many thanks for providing the patch in #33. Is there a way to enable the views support without uninstalling and re-installing the uc_attribute module? I've applied the patch manually, updating uc_attribute.module and creating the new uc_attribute.views.inc file in the uc_attribute folder. I cleared my cache but still don't see any attribute field options in my product view.

hanoii’s picture

there's a views clear cache button in the advanced settings of views, but clearing all caches should have cleared it. Bear in mind this patch only exposes fields, not filters, not sure which one you were using.

hockey2112’s picture

Can this functionality (filter by attributes) be added to a View of type "Orders"? I added the new patches from #33 (and also tried the ones from #17), but cannot get the attributes to sow up as filters.

kopeboy’s picture

When this will be included in a stable release?

If I update to dev version can I use this functionality right away or do i have to disable/re-enable anything?
Thanks

sin’s picture

I rewrote my patch so it now queries uc_product_options table instead of uc_product_adjustments. SKU for attributes is not required now. But I have to use subqueries so there might be performance issues with this variant.

I tested only filter product nodes by attribute options, both single values and multiple selected values with OR works. Attributes as fields and arguments are not tested.

hockey2112, orders might work if you add a relation to product nodes in your view.

hanoii, if you can review my patch again and combine with yours that would be awesome :)

Colin @ PCMarket’s picture

Have been able to apply the patches supplied here on to a 3.7 installation and even after clearing caches cannot seem to get attribute exposed to views fields.

am i missing something here?

mattbk’s picture

I'm not seeing any new fields either, unfortunately. Patched #33 onto 7.x-3.x-dev, 10 Sep 2014.

EDIT: It also made the attributes no longer appear on the product pages, so I repaired from backup.

bellagio’s picture

FileSize
31.07 KB

after applying the patch #39, i see the attribute exposed to views fields, but my views disappears from content bottom block... When attribute field is removed, my views appears again.

TR’s picture

Status: Needs review » Needs work

I would very much like to see this go into Ubercart, but there seems to be problems with the patch in #39 as mentioned in #40, #41, and #42.

pipicom’s picture

#39 did not work for me either.
#33 does the job - but had to do some tricks since it displays fields but doesnt allow filtering of nodes.

aev_fly’s picture

After applyd #39,
I have this
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'uc_product_options.attr_2' in 'field list'

mattbk’s picture

I have tried all the patches again today (on the most recent dev) with no success.
- I can add product attribute filters, but they fail with SQL errors.
- I cannot see product attributes as fields.

I am willing to offer a $100 bounty on closing this issue so that
- attributes are able to be added as individual fields to a view,
- attributes are able to be added as individual filters to a view, and
- the code is incorporated into the project.

This may be easy for someone to grab; I just don't have the experience with Drupal development. If there is a particular bounty platform that people prefer for Drupal development, I would rather offer the bounty there so others can contribute and make it more worthwhile for someone to put the time in.

mattbk’s picture

Okay, so I hacked around at this for a few days and have cut down uc_views_attributes (part of uc_views) into a module that will show individual attributes as fields.

Fields are listed as Attribute 01, Attribute 02, etc. through the list of attributes.

See at https://github.com/mattbk/uc_views_attribute_fork.

hanoii’s picture

Status: Needs work » Needs review
FileSize
21.21 KB

2 years later and I needed this functionality on a client. I have ported most of what was done on uc_views for attributes, which I happened to contribute to that at the time.

I have built my patch on top of #39 which was partly taken from it as well and make everything works, at least the initial bits, a lot more of what is now currently on ubercart, which is none.

Right now the patch adds several field handlers and some filter handles as well.

It allows you to add option/attribute fields to the products table, and also adds some relationship to and from stock table. It also has a price fields that display the adjusted price (base + option) and allows to filter by attribute in both products and order products base tables.

It's a bit of a big patch, so reviews are welcomed!!!

mattbk’s picture

I've attempted to apply this patch, but I've never been very good at applying patches. I don't seem to get any different behavior. Is it possible for someone to share a zip of the module with the patch applied?

EDIT: I do get filters for each of the attributes, but I don't think they are working. Like I said, I probably messed something up.

hanoii’s picture

@mattbk this should be ok for you to start applying patches: https://www.drupal.org/patch/apply

As far as not working, can you provide more description on what's not working? A views export might help. Also are you trying this on a working site or a vanilla install?

hanoii’s picture

hanoii’s picture

I just found out that the patch do not apply cleanly to ubercart 3.9 because of uc_attribute.info changes. I am honestly unsure on why this, but for the time being, attached is a patch that applies on 3.9, which I also need for my Makefile.

@mattbk probably this was the issue for you.

hanoii’s picture

Previous patch was wrong, this one is for Ubercart 3.9 if you want to quickly test it out.

mattbk’s picture

Thanks @hanoii, I did manage to fix the info part manually the other day. Will look at these when I get a chance.

hanoii’s picture

I found a potential bug with a huge matrix of attributes (too many combination), in which with one of the options that prints out all of them, it could led to a very time-consuming page load with a huge html output.

The attached patch adds a limit the views field.

I will maintain only the patch against git dev and will use that myself on the Makefile, so it will always likely fail for the info file on 3.9 or any other release, so this one will likely need to be patched manually while it fails.

hanoii’s picture

Attached is another fix for the patch. I removed a bit of a code that I am not entirely sure its purpose and was causing errors as well and fixed an unnotified notice.

TR’s picture

@hanoii: Thank you for your work on this!

I don't really have time to test this myself, but since the patch doesn't modify any of our current code (it just adds Views handlers) it's not going to break anything (the tests will always pass as long as the patch applies, because nothing that's being tested is being changed). And it's an important feature. So I'm inclined to just commit it once you've decided it doesn't need any more work. That seems to be the best way to get it out there and get people to use it - which in turn is the best way to find any remaining bugs.

hanoii’s picture

@TR that's the attitude :). Will let you know.

For now just another tiny fix, I moved some of the additional views data that is related to the attributes but adds to other views elements to hook_views_data_alter to prevent being used when creating new view, it;s just a fact of the order of the view data array.

morybel’s picture

Hi all,

I've been watching this tread for some time now. I've tried pretty most of those patches and none seems to work.

The last one, #57 shows all my attributes (Yay) but yields no results.

Here is what I get in the logs
Notice : Undefined variable: operator dans uc_attribute_handler_filter_product_attr->query() (line 34 in /home/mysite/public_html/html/sites/all/modules/ubercart/uc_attribute/views/uc_attribute_handler_filter_product_attr.inc).

seems to be this line:

if ($operator != 'not in' && $operator != 'in') {

Hopes this help. Thanks for your hard work.

hanoii’s picture

@mory that's just a notice, i will review but is harmless. Can you please provide more details on the query you are trying to run? What does list all attributes but no result mean? What would really really help if you can reproduce this on a vanilla install. Setup a basic product with basic set of attributes emulating your setup and export that view and paste it here or on some pastebin.

If that's not an option, export your current view if you can and I can try to look it up.

morybel’s picture

FileSize
11.88 KB
11.91 KB

hanoii

I can select my attributes in the views for exposed filters
attributes

But when I choose from filter, no results

dropdown

I will try to send you the export in a private message as this is for a client.
thank you so much.

mattbk’s picture

FileSize
8 KB

Using patch in #59, I get SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'S:8:"CATEGORY";A:1:I:0;S:8:"BEGINNER"; 'uc_order_products.data') )) ORDER BY uc_' at line 4 when testing a View with a filter on attribute "Category."

Exported View is attached.

Is your patch designed to expose fields for display or only for filtering?

hanoii’s picture

@mattbk, @mory and any other tester, if possible, could you setup the views to show the SQL query and pass on that as well.

@mattbk, I am confused with your error, I don't quite get where the SQL error is coming from. I have MariaDB as well on my local dev. See if you can provide the full query.

I am also submitting a new patch, this is mainly the undefined notice spotted by @mory and a slightly different approach for the order product attributes.

The patch should allow for attribute FILTERING as well for both Ordered product and product base tables.

mattbk’s picture

Title: Expose assigned attributes to views » Expose assigned attributes to views filters
hanoii’s picture

Title: Expose assigned attributes to views filters » Expose assigned attributes to view

Semantically speaking, it's for both filtering and output them as fields as well.

mattbk’s picture

The patches in this issue are all about filters, not fields. It might be worthwhile to split them apart so each use case can go its own way. For example, I don't need filters as a user, and it seems like many people don't need fields, so more clarity on what the issue actually is would be helpful.

hanoii’s picture

Title: Expose assigned attributes to view » Expose attributes to view
morybel’s picture

hanoii

I'm still running tests, but I'd say that patch #64 is working pretty fine. I can now expose attributes to my view and let user choose between sizes and colors.

Thank you for your availability and quick answer.

sin’s picture

Hi!

I just found a couple of minutes to test #64 on a clean install.

I found that setting up individual SKU for attributes is required for the view with exposed attribute filters to work. Otherwise the result is empty.

There is a notice:
Notice: Undefined variable: not in uc_attribute_handler_filter_product_attr->query() (line 63 of /var/www/ubercart/drupal-7.42/sites/all/modules/ubercart/uc_attribute/views/uc_attribute_handler_filter_product_attr.inc).

Attaching the patch to fix it.

Besides that it works as expected!

amh5514’s picture

If I create a view of user, and add a relationship of "Orders" and then "Orders Products", I will get the attribute fields in the fields list ((products) Ordered product: Ordered product attributes (Ordered product attributes)) and the attributes as a filter (Ordered product: Attribute: Membership duration). When the filter is selected, just like with #62, it doesn't show a result.

Also, I'm not sure what you mean by "could you setup the views to show the SQL query and pass on that as well.".

I'm using views export and would like to filter the export by a product's option. e.g. Term duration. Each option of the attribute has an individual SKU assigned.

morybel’s picture

@amh5514

Just to go http://yoursite.com/admin/structure/views/settings

and check the "Show the SQL query" on the bottom section.
Now when you preview your views, you should view the SQL queries just before the results.

peetrovich’s picture

Hello everyone.
First of all I want to thank you for awesome work and add my review.
I've tested all patches (Ubercart 3.9, Views 3.13).

For my task (just filter product by attributes) the easiest solution was #39. But in results I had duplicates. Solved by:
1. Go and edit your view
2. In Advanced » OTHER section by enabling Use aggregation: Yes
(https://www.drupal.org/node/1704962)

Also I used #70. For me it shows results after filtering only if you specify alter SKUs for attribute options in product.

Sorry for my English :)

mattbk’s picture

@hanoii, I don't know where that Maria error was coming from.

Tried again to apply patch #64, this is the SQL query (for an exposed filter on the attribute "Sex" with options of "Male" or "Female"), but no results are returned:

SELECT uc_orders_uc_order_products__users.picture AS uc_orders_uc_order_products__users_picture, uc_orders_uc_order_products__users.uid AS uc_orders_uc_order_products__users_uid, uc_orders_uc_order_products__users.name AS uc_orders_uc_order_products__users_name, uc_orders_uc_order_products__users.mail AS uc_orders_uc_order_products__users_mail, uc_order_products.data AS uc_order_products_data, uc_orders_uc_order_products_billing_zones.zone_code AS uc_orders_uc_order_products_billing_zones_zone_code, uc_orders.billing_city AS uc_orders_billing_city, uc_order_products.title AS uc_order_products_title, uc_order_products.model AS uc_order_products_model, node.nid AS node_nid
FROM 
{uc_order_products} uc_order_products
LEFT JOIN {uc_orders} uc_orders_uc_order_products ON uc_order_products.order_id = uc_orders_uc_order_products.order_id
LEFT JOIN {uc_orders} uc_orders ON uc_order_products.order_id = uc_orders.order_id
LEFT JOIN {users} uc_orders_uc_order_products__users ON uc_orders_uc_order_products.uid = uc_orders_uc_order_products__users.uid
LEFT JOIN {uc_zones} uc_orders_uc_order_products_billing_zones ON uc_orders_uc_order_products.billing_zone = uc_orders_uc_order_products_billing_zones.zone_id
LEFT JOIN {node} node ON uc_order_products.nid = node.nid
WHERE (( (uc_orders.order_status IN  ('pending', 'payment_received', 'completed')) AND( (uc_order_products.data  LIKE '%s:3:\"Sex\";a:1:{i:31;s:4:\"Male\";%') )))
ORDER BY node_nid ASC

Edited to show a simpler query (only filter is on an attribute).

mattbk’s picture

@TR wrote to @hanoii:
> So I'm inclined to just commit it once you've decided it doesn't need any more work.

Any movement on this? Doesn't seem like much in the past eight months.

hanoii’s picture

Just an up to date re-roll of the patch with @sin change from #70 and its interdiff to #64.

m.roma’s picture

When I try to perform this patch with 7.x-3.x, I'm getting:

patch -p0 < uc_attribute.module
patch: **** Only garbage was found in the patch input.

Is there something I am missing to do aside from the normal way of patching?

TR’s picture

The correct way to apply the patch is:
patch -p1 < ubercart-uc_attribute_views-895236-76.patch
Do this in the Ubercart base directory.

boyron’s picture

@hanoii, product attribute filter does not work in a multilingual site because attribute labels are translated and the filter includes source language label in the query. Why including labels in the query when attribute id are unique across all products? I have updated uc_attribute_handler_filter_attr::query() as follow that worked for me.

Notice the code inside `foreach`. Much simpler.

  function query() {
    $this->ensure_my_table();
    $this->real_field = 'data';
    $field = "$this->table_alias.$this->real_field";

    if (!empty($this->value)) {
      if ($this->operator == 'not in') {
        $not = 'NOT';
        $condition = db_and();
      }
      else {
        $condition = db_or();
      }

      foreach ($this->value as &$value) {
        $value = "i:$value;";
        $condition->condition($field, "%{$value}%", "$not LIKE");
      }

      $this->query->add_where($this->options['group'], $condition);
    }
m.roma’s picture

After successfully patching and making a block with Attributes, I get this error:

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM node node WHERE (( (node.status = '1') ))' at line 1

Any suggestions or ideas for getting around this or fixing it?

m.roma’s picture

Now, overnight, that error is gone (perhaps this was because of caching - though I had cleared them yesterday), I get this error when trying to add an attribute to view (block type):

"The handler for this item is broken or missing and cannot be used. If a module provided the handler and was disabled, re-enabling the module may restore it. Otherwise, you should probably delete this item."

There is also no longer a list of attributes when choosing Fields under Format - it is a list of every option for each attribute.....

bisonbleu’s picture

The patch in #76 applies almost cleanly (current or latest dev versions) except for one little glitch.

$ patch -p1 < ubercart-uc_attribute_views-895236-76.patch
patching file uc_attribute/uc_attribute.info
Hunk #1 FAILED at 7.
1 out of 1 hunk FAILED -- saving rejects to file uc_attribute/uc_attribute.info.rej

But it's pretty easy to manually apply those changes to uc_attribute.info.

I also used @boyron's code in #79. Works for my use case (filtering orders on product attributes). The function's closing '}' is missing. The dblog shows 1 php notice.

Notice : Undefined variable: not in uc_attribute_handler_filter_attr->query() (line 46 in /home/user/public_html/mywebsite/sites/all/modules/contrib/ubercart/uc_attribute/views/uc_attribute_handler_filter_attr.inc).

Line 46: $condition->condition($field, "%{$value}%", "$not LIKE");

Otherwise, awesome work! Kudos to @hanoii, @sin, @boyron and others!

bisonbleu’s picture

I've re-rolled @hanoii's patch in #76 to include @boyron's suggestion in #79 + fix for PHP Notice. Works for me.

  • As mentioned in #82, you will get Hunk #1 FAILED at 7 if you're not applying this patch to HEAD.
Joe Huggans’s picture

Patch won't apply to latest Dev Nov 2017, any ideas?

bisonbleu’s picture

Patch in #83 applies cleanly and without issues to HEAD.*

$ patch -p1 < ubercart-uc_attribute_views-895236-83.patch 
patching file uc_attribute/uc_attribute.info
patching file uc_attribute/uc_attribute.module
patching file uc_attribute/views/uc_attribute.views.inc
patching file uc_attribute/views/uc_attribute_handler_field_combination.inc
patching file uc_attribute/views/uc_attribute_handler_field_combination_price.inc
patching file uc_attribute/views/uc_attribute_handler_field_order_product_attribute.inc
patching file uc_attribute/views/uc_attribute_handler_filter_attr.inc
patching file uc_attribute/views/uc_attribute_handler_filter_product_attr.inc

* On Ubercart's project page, click on the Version control tab, it will take you there: https://www.drupal.org/node/129292/git-instructions/7.x-3.x/nonmaintainer

TR’s picture

Status: Needs review » Needs work

Yes, the patch applies cleanly to HEAD. And I just re-ran the tests and they run fine (which isn't saying much, because there are no tests for this new functionality - it's only really testing whether there are syntax errors in the new code...).

I'm in the process of trying out on my site and if it works for me I will be committing it.

But ...

You're adding about 580 lines of code, and at the same time you're adding 220 coding standards violations! That's one coding standards problem for every 2.5 lines of code!

I've been working very hard at cleaning up the Ubercart code base, so there's no way I'm going to commit this until the patch has been cleaned up and shows no (or very very few - often some of the errors are false positives) coding standards problems. Normally I would just clean up the patch myself - I do that all the time, but I don't have time to deal with 220.

To see a detailed list of the detected problems, go to https://www.drupal.org/pift-ci-job/821965 and click on the "220 coding standards messages". It will show you the files, line numbers, and a summary of each problem. You can also reach this page by clicking on the green test result in #83.

Joe Huggans’s picture

Any ideas why it is failing in my case, I am using git to apply the patch.

bisonbleu’s picture

You're adding about 580 lines of code, and at the same time you're adding 220 coding standards violations! That's one coding standards problem for every 2.5 lines of code!

Thanks for pointing this out @TR. I'll look into this asap.

TR’s picture

@joeuk31:

$ cd ubercart
$ patch -p1 <  ubercart-uc_attribute_views-895236-83.patch

That works for me.

I also tried:

$ cd ubercart
$ patch apply  ubercart-uc_attribute_views-895236-83.patch

And that also worked, but complained about a whitespace error after the end of the file (that's one of the codings standards problems I mentioned above).

Since you're using git, make sure you git pull and git checkout 8.x-4.x before you do this to make sure your copy is up-to-date.
If that doesn't work, post the error here.

Joe Huggans’s picture

Thanks TR,

But I thought the patch was for 7.x ?

I had the whitespace error but also a couple others.

TR’s picture

@bisonbleu:

Actually, I see it's not 220, it's 127 NEW coding standards issues. The 220 number includes issues that are already in uc_attribute.module (which was checked because you modified it).

You don't need to address all those existing issues in uc_attribute.module (although you can if you want!). I just don't want to introduce any NEW issues.

Thanks.

bisonbleu’s picture

@TR, I've given it a go (first time I dive into Coder). Revised patch is attached.

Note that I limited myself to only fixing coding violations introduced by the patch. The patch applies to latest dev. The bigger question is did I break something in the process...

Update: unfortunately this patch breaks the code. I will try again soon.

TR’s picture

Status: Needs work » Needs review

Thanks.

Yes, that's always the problem with coding standards - sometimes they make you change syntax, so it's easy to make a mistake and break the functionality. Trying to keep up with coding standards sometime leads to modules that stop working, which is really opposite to what standards should be doing. I've broken Ubercart multiple times trying to fix coding standards. That's why I always oppose arbitrary changes to the coding standards. But I usually lose those fights ... we've gone from NO standards to a large amount of irrelevant standards that are only imposed upon contributed code (like Ubercart) and are specifically excluded from applying to Core Drupal (excluded, because tests won't fail on core violations). Then there's the false positives from the coding standards checks - for most modules that's only a few but Ubercart has almost 200,000 lines of code so even a 1% false positive rate gives us thousands of violations. I've gone from being a coding standards proponent to being a curmudgeon.

bisonbleu’s picture

Here is a transition patch which applies cleanly to the latest dev and works for my use case: a Views table with an exposed attribute filter.

In many cases, Coder requires a function's visibility to be set - otherwise it complains. I've assumed public everywhere except for function _uc_stock_extra_combinations() in uc_attribute_handler_field_combination.inc which was set to private.

@ TR, this time around, I have refrained myself from renaming classes and functions as required by Coder. I'm thinking that perhaps this is what broke the previous patch. Please advise on next steps.

Finally, I've added TODOs where required. Cheers!

bisonbleu’s picture

Here is a reviewed patch with a few minor cosmetic fixes and proper UpperCamel class names. If this goes through, I don't mind cleaning up uc_attribute. Let me know.

i92guboj’s picture

Pardon my ignorance, but, what are the requisites when setting up a product for this to work?

I always get an empty result set, no matter what I use when setting up the filter.

I usually just create the product, add an attribute called "size" in the attributes tab, and then go to the attribute stock tab, put a mark on the first square on each line I need to and then set the size manually from the dropdown.

Some custom sql task I made fills the stock field every five minutes, just to keep it in sync with my real stock because I also sell directly in a shop. So I don't need to fill that manually. I just need to add the attribute and then add the available sizes.

I don't touch a thing in the adjustments tab, the options tab or the last tab. I am suspecting that maybe there's some special requirement in one or many of those for this patch to work. Isn't there?

Thanks!!

bisonbleu’s picture

@i92guboj, I used this patch in an orders based view to filter orders based on a product attribute. For this to work, I had to add a relationship of type « Order: Products » since the order is not aware of product attributes.

Hope this helps.

i92guboj’s picture

@bisonbleu, thank you for answering so quickly.

I seem I missunderstood the purpose of this patch, then. Admittedly, I didn't read the whole thread. Based on the first few posts I thought this was about filtering the product catalog, not about filtering orders.

I just want my customers to be able to quickly see the available shoes for desired size(s).

joelstein’s picture

MahmoodZidan’s picture

@bisonbleu can you please explain more?
I am using a view that views Content type Product kit. I have a relationship with the Product Kit:component, which is the product node in the product kit. I don't get an option (after adding the component relationship) to relate to the component (or product) attribute.

bisonbleu’s picture

@MahmoodZidan let me try explain.

What I needed to do was to make it possible to filter a table of orders by product attribute. My products is an annual hockey registration. But maybe we can change that to t-shirts for the sake of simplicity.

So let's say we're selling t-shirts. Common attributes for such products would be size, color, etc. Now the store owner wants to be able to browse through a table of orders and also filter them by size (S, M, L). Without this patch, it's not possible because out of the box, product attributes are not exposed in Views.

The patch created by @hanoii changes that. Here's how to do it.

  1. Create a new view of orders (not content) using a table format.
  2. Add the required fields e.g. order id, customer name and email, etc.
  3. Add a relationship: Orders : Products. You need this because the attributes are on products not on orders.
  4. Now you can add the Size attribute to the list of fields using this relationship.
  5. It should looks like this: (Products) Ordered product : Ordered product attributes (Attribute t-shirt).
  6. Under Filter Criteria, add: (Products) Ordered product : Attribute: Size (exposed)
  7. Save

The important part to understand is that you need a relationship to the products table in order to fetch the product attributes.

Hope this helps.

MahmoodZidan’s picture

I applied the patchusingcurl https://www.drupal.org/files/issues/ubercart-uc_attribute_views-895236-76.patch | git apply -and I get:

warning: uc_attribute/uc_attribute.info has type 100755, expected 100644
error: patch failed: uc_attribute/uc_attribute.info:7
error: uc_attribute/uc_attribute.info: patch does not apply
warning: uc_attribute/uc_attribute.module has type 100755, expected 100644
error: patch failed: uc_attribute/uc_attribute.module:11
error: uc_attribute/uc_attribute.module: patch does not apply
<stdin>:572: new blank line at EOF.
+

Does this mean the patch is already applied?
If yes, when I add the relationship Order : Products (You typed it "Orders : Products" I assume its Order not Orders). I only find the basic product info (the default) but none of the attributes I assigned.

bisonbleu’s picture

Here are the commands I usually use to apply a patch.

  • cd path/to/module (go into the module directory)
  • patch -p1 < /path/to/patches-directory/ubercart-uc_attribute-views-895236-99.patch

I would try this on the latest release - it might work.
If not, on the latest dev.

mattbk’s picture

I get one error when applying the #99 patch to the current dev version:

patch -p1 < "C:\Users\matt\Website\Attributes\ubercart-uc_attribute-views-895236-99.patch"
patching file uc_attribute/uc_attribute.info
Hunk #1 FAILED at 7.
1 out of 1 hunk FAILED -- saving rejects to file uc_attribute/uc_attribute.info.rej
patching file uc_attribute/uc_attribute.module
patching file uc_attribute/views/uc_attribute.views.inc
patching file uc_attribute/views/uc_attribute_handler_field_combination.inc
patching file uc_attribute/views/uc_attribute_handler_field_combination_price.inc
patching file uc_attribute/views/uc_attribute_handler_field_order_product_attribute.inc
patching file uc_attribute/views/uc_attribute_handler_filter_attr.inc
patching file uc_attribute/views/uc_attribute_handler_filter_product_attr.inc

In uc_attribute.info.rej I see

--- uc_attribute/uc_attribute.info
+++ uc_attribute/uc_attribute.info
@@ -7,3 +7,10 @@ core = 7.x
 ; Test cases
 files[] = tests/uc_attribute.test
 files[] = tests/uc_attribute_checkout.test
+ 
+; Views handlers
+files[] = views/uc_attribute_handler_field_combination.inc
+files[] = views/uc_attribute_handler_field_combination_price.inc
+files[] = views/uc_attribute_handler_field_order_product_attribute.inc
+files[] = views/uc_attribute_handler_filter_attr.inc
+files[] = views/uc_attribute_handler_filter_product_attr.inc

I tried to fix it manually, but seeing the same results as #102.

name = Product attributes
description = Extends product content types to support product variations that customers may select before purchase.
dependencies[] = uc_product
package = Ubercart - core (optional)
core = 7.x

; Test cases
files[] = tests/uc_attribute.test
files[] = tests/uc_attribute_checkout.test

; Views handlers
files[] = views/uc_attribute_handler_field_combination.inc
files[] = views/uc_attribute_handler_field_combination_price.inc
files[] = views/uc_attribute_handler_field_order_product_attribute.inc
files[] = views/uc_attribute_handler_filter_attr.inc
files[] = views/uc_attribute_handler_filter_product_attr.inc

; Information added by Drupal.org packaging script on 2019-01-21
version = "7.x-3.11+2-dev"
core = "7.x"
project = "ubercart"
datestamp = "1548101294"
TR’s picture

The patch still applies, as you can see from the test results in #99. I just re-triggered the tests, and this is still true. See https://www.drupal.org/pift-ci-job/1205498

The reason it doesn't apply for YOU is that "Information added by Drupal.org packaging script on 2019-01-21" and subsequent lines, which is not part of the actual codebase. If you remove everything after files[] = tests/uc_attribute_checkout.test from your uc_attributes.info file then you should be able to apply the patch.

mattbk’s picture

Thanks, TR. I got the patch to apply cleanly.

With a relationship "(products) Ordered product: node", I can see the "Product Attributes" group under the add field dialog and all the variations there ("Cost for", "Weight for", "Price for"...), but I don't see a way to display the value for a chosen attribute for a given order. In comment #101, it seems like this should be possible?

For example, if I have order #123 for a shirt with an attribute "size," what I'm looking for is a way to show the value chosen for "size," be it S, M, L, or whatever. Then I want to show the value for the "color" attribute. This way I can choose which attribute values to display on a given View.

hanoii’s picture

I recently needed to upgrade ubercart on the site that triggered most of the work on #76. I applied cleanly #99 but then performed a thorough review of the patch as I wanted to make sure I was not introducing any issue to my client's site, which was using my previous patch. My biggest worry was #79 but after reviewing that change and actually testing it worked good.

I am now re-rolling #99 for this comment as well as adding an interdiff against my patch.

@bisonbleu just a suggestion, specially with bigger patches like this one, an interdiff makes it so much easier for others to review the changes.

I will follow up some small tweaks to while I work a bit again on this and with something a problem I think I found.

I am also wondering if changing the classes names to CamelCase was worth it. I see it's the standard now, not sure if this was the case on D7, it's definitely not the standard used by views. The interdiff would have been much cleaner/easier to review. Was that out of the Coder module?

hanoii’s picture

So I did a couple small tweaks to the previous patch.

I removed most of the TODOs, having added something to it only to keep it cleaner.

Also tweaks a few coding things as well as did something similar to the improvement on #79 on the ajustment attr filter.

I also tweaked some texts. A fresh look at it and 2 more years working/reading in English and Ubercart made this tweaks more sense. The main text change is that I renamed "Products attributes" to "Products adjustments" where applicable. Attributes is likely the most complex part of Ubercart and this makes it more clear what exactly is being targeted with views.

I identified a couple potential tweaks, but I would tackle them on a separate issue unless the maintainer think otherwise:

1. The attribute filters file names and class names can be updated a bit to make it more clear what its doing. I.e. UcAttributeHandlerFilterAttr could be UcAttributeHandlerFilterProductAdjustmentAttr as it really filters by the adjustments table. A similar thing to UcAttributeHandlerFilterProductAttr where it really is UcAttributeHandlerFilterOrderProductAttr. I don't want to do this here as it will bother with reviewing.

2. In relation to the above, there's one "basic" think this patch doesn't allow to do which is to create a products view that filters by products with a specific option. It works only if the specific option has its own SKU (read uc_products_adjustments).

To add this feature some more tables/filter handles need to be added, like uc_product_options, and maybe uc_product_attributes.

I don't have time to add to this currently, so being this issue is years old, maybe worth noting it somewhere else.

If anybody is willing to support this addition It might speed it up, but otherwise the patch is still useful as it is.

hanoii’s picture

amh5514’s picture

Thank you. #108 worked. I had to delete the bottom few lines of the Attribute.info file like TR mention in #105 but once I did that, the patch ran clean. the "Broken/missing handler (in Array)" went away in my Views.

philsward’s picture

Status: Needs review » Needs work

Applying this appears to result in uc_attribute_load being called on EVERY front facing page, regardless of whether a view using attributes is on the page or not.

I believe the culprit is with:

+      foreach ($combination as $aid => $oid) {
+        $attribute = uc_attribute_load($aid); <------------------
+        $option = uc_attribute_option_load($oid);
+        $attributes[] = "$attribute->name: $option->name";

See #2276769: Loading all attributes rather than sub-set (Extremely slow page loads) for a possible solution. This is over my head to properly fix.

GCT’s picture

I've applied the patch, no worries there, but I see no Product Attributes among fields or filters in a custom view - am I misunderstanding what or where additions this patch (108) caters for?

DamienMcKenna’s picture

This adjusts patch #108 so it can be used with Drush Make (due to changes on the info file when the module is downloaded from d.o) but is otherwise identical.

philsward’s picture

Throwing these comments out there from someone who is doing some custom work for me. Don't shoot the messenger.

Comments regarding the latest patch of #113

1. There is a "SELECT *" in the uc_attribute_views_data() function, but the function clearly uses only the aid and oid values of the uc_attribute_options table. So "SELECT aid, oid" would be better.

2. The same attribute is loaded in the foreach loop over and over again in the uc_attribute_views_data() function. If an attribute has 20 options, this means that the same attribute is loaded 20 times!

3. The option is loaded by calling uc_attribute_option_load($row->oid), but only the name is used of the loaded option. Using "SELECT aid, oid, name" would make it possible to use $row->name.

4. Are you aware that loading an attribute by calling uc_attribute_load() loads all its options as well? This means that if a site has a single attribute with 20 options, then in this function 20 options are loaded by database query, then the same attribute is loaded 20 times including its 20 options by calling uc_attribute_load(), then all the 20 options are loaded again using uc_attribute_option_load(). Of course, cost, price, weight and ordering is loaded as well each time for each option, but never used. Imagine a site with over hundred attributes and many options, and loading, loading, loading, loading. What an overhead!

5. The same unnecessary waste of computing power happens in the render() function in the uc_attribute_handler_field_combination.inc file.

6. This comment is not clear:
* I think think this is very useful, probably worth removing.

7. The hook_views_data() is normally called by _views_fetch_data_build(), where data is built and stored in the cache. If an attribute or an option is added or removed or renamed, what ensures that the views data will be rebuilt? And if such a re-building is going to be implemented in the future, what are the performance implications of rebuilding the views data cache after simply adding or renaming an option? Regarding #58, to make this patch work correctly, is TR willing to clear the views_data cache after adding/renaming/deleting options, which would mean modifying the current code?

8. What if a view is created using a certain attribute, and then that attribute is deleted? Has it been tested? Is that view going to work somehow without major errors?