I upgraded to the latest dev branch a few hours ago, and it broke all the views I had set up for our products. The cause appears to be a filter field on the views that used variations:delta and set to 0, in order to only show the first variation of each product row, rather than a row for every variation of the same product.
After update, the filter field is reported in views as "Broken/missing handler", and I can't find another variations delta in the filter fields.
I assume I just missed something obvious, but what should I do? Is there a new process for limiting to just the first variation I'm unaware of?
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | 3095829-21-fix-views-update-functions.patch | 1.51 KB | bojanz |
| #15 | views-bug-3095829-15.patch | 26.1 KB | lisastreeter |
| #6 | screenshot.png | 80.27 KB | Gode.Agarunov |
Comments
Comment #2
bojanz commentedDid you run update.php after you updated the files? And tried clearing the cache?
Comment #3
Gode.Agarunov commented@bojanz
Yes sir:
Comment #4
bojanz commentedOkay, it was worth checking. Thanks for reporting back.
This was caused by #3002939: Convert order/product multivalue configurable fields back into base fields. We'll need to investigate why the "delta" filter disappeared and how we can bring it back.
Could you share an export of the view by any chance?
Comment #5
Gode.Agarunov commented@bojanz, sure, it's going to be a bit complicated and long though
Comment #6
Gode.Agarunov commentedHere is a screenshot of the what the configuration actually looks like on views config:
Comment #7
Gode.Agarunov commentedAfter doing some more digging, I believe the issue may be related to this:
Views does not add relationship data for entity_reference fields not defined in configuration and are multiple
I know it's old, and I know next to nothing about how views works internally, but it seems like views doesn't play nice with entity reference fields when they are defined in class rather than as a separate configuration, just figured it might help.
I did a stupid and updated on the live website originally, I have daily backups and am considering rolling back, but I would like to avoid if it at all possible because I did a lot of other stuff yesterday, too. Going to try the patch as it reportedly still applies to 8.7 and see if that makes it any better.
Edit:
Didn't appear to help.
Comment #8
bojanz commentedI am not sure that issue is up to date, because relationships do work, I was able to create a product view, add a variation relationship, add a filter (on a "size" attribute), add a field (the SKU). The only thing I'm missing is the "delta" thingie.
Comment #9
Gode.Agarunov commented@bojanz
Glad that you were able to reproduce the issue, and it's not just me or quirk of my configuration/install.
If there's anything else I can do to help please let me know, I'm going to hold off on rolling back to a backup as the issue is cosmetic in nature and we'll deal with having 15 of every product for now, and hopefully it gets sorted soon, as the variation delta is the only way I know of (and I believe is referenced in the documentation) to trim product views with a variation relationship. I suppose in the worst case I could remove the relationship for now, but then I can't pull in the prices/images that are on the variation entity.
Just wanted to say thank you for all the help, this is the 4th or 5th issue I've had to create in the span of this project and you've always responded and helped quickly even though you have no obligation to do so, and I really appreciate that.
Comment #10
Gode.Agarunov commentedI've done a bit more investigating, it seems that in practice the only time a delta option appears under filter, is also when the add relationship screen shows the relationship as "X referenced from field_X", if I add such a relationship, I can filter by delta. IIRC the variation relationship used to be displayed as "Product Variation referenced from field_variation_id" or something similar, while after the latest update, the relationship is just displayed as "Product Variation" (I'm assuming all of this applies to store as well, but the likelihood of someone needing to trim on store delta is much smaller).
In the mean time, I believe I can fix it by adding a bool field to variations called first variation, and then going through all the products and setting the first variation to "true", and then adding a filter in views for first variation = true. I'm not exactly thrilled about doing so though, as we have hundreds of products and a dozen views, but as of right now that's the simplest way. Perhaps I can just create the field and then write a hook to set the first variation to true when views loads the variations, so that I don't have to edit every product or write a script to do it for me. Otherwise I'm drawing a blank.
Comment #11
Gode.Agarunov commentedHave some more info from playing around:
I created module_field_views_data_alter() and spent more time looking at kint than I would have preferred to in an entire life time (I ended up going directly to the views module and throwing a bunch of kints in there too, but the field doesn't come up), pretty much every field came up, but none of the fields that are defined by basefielddefinition, things like commerce product body, taxonomy, etc. all came up though.
I did some more googling, and I'm pretty sure that this is the issue right here:
Allow @FieldType to customize views data
I haven't really looked through the thread, but I noticed several patches that I will look through and attempt to try, will report if I have any luck.
Comment #12
andyd328I had a similar this problem on a view in the new -dev
Notice: Undefined index: base in Drupal\views\Plugin\views\query\QueryPluginBase->getEntityTableInfo() (line 292 of [..]/web/core/modules/views/src/Plugin/views/query/QueryPluginBase.php)The view in question is a catalog using db search api that had two broken relationships:
Please let me know if a paste of the view yaml would help.
It was fixed in my case by removing the
(Variations: Product variation) Product: Productrelationship and then adding it again.Comment #13
bojanz commented@Gode.Agarunov
ETA for a fix is monday, I was able to track down the problem.
@AndyD328
Please do post your view, I guess our update function doesn't yet cover all cases.
Comment #14
Gode.Agarunov commented@bojanz
That's great, thanks!
As far as search view, I had the same problem with my search API based view, where I had to delete the relationship and recreate it, because the fields related to the relationship had broken. Interestingly, in the search view the relationship was listed as "product variation referenced from product variation" instead of just "product variation".
I believe you could reproduce the problem by making a view around "index X" instead of "products", but if you can't reproduce it, it may because the fields were indexed and the index was created before the update. Perhaps create the index and the view before running the latest dev update, and then run the update and you should definitely be able to reproduce it then. I have unfortunately fixed the search view already so I can't give you the yaml now, but if both Andy and I had the same problem I assume it should be pretty easy to reproduce.
Comment #15
lisastreeter commentedI have a patch that incorporates work done in the Commerce Reports module to fix views integration there. Unfortunately, I don't think it's completely working here. In particular, starting at line 585 of commerce.views.inc, the "delta" column for variations should get exposed as a filter option. That's not happening and I think that's what @Gode.Agarunov needs to get his view working again. I'll try to work on this some more tomorrow, but just wanted to get this posted as a start for now.
Comment #16
andyd328Thanks @bojanz & @lisastreeter. Failed View below
=======
Comment #17
Gode.Agarunov commented@lisastreeter
thanks for the help, I had tried to do something very similar to what is being done in the patch to trace it down, I didn't go nearly as far because in my own module, views wouldn't call the hook because the entity didn't belong to my module (apparently, this is something I read while researching so don't quote me on it, but when it calls the hook alter it only does it for the module the entity belongs to, which doesn't make much sense reading it back), I tried it inside the commerce_views_data_alter() and just put a kint on $data and pretty much every single field in the system came up except variation and store, so in my experience it seems like it's not even calling views_data_alter() with the product variation entity data. Not a clue as to why.
I made a bool on the variations and filtered the views by that, it's actually not the worst thing because it allows us to feature multiple variations out of the same product in the catalog as desired, so it's not critical it gets fixed anytime soon for me or anything, but I do believe it is important to fix before the dev branch gets merged in, as it can't be just me using deltas to filter variation views.
Comment #18
bojanz commentedThe fix took longer than expected cause I ran into all kinds of Views bugs.
Opened #3097582: [meta] Rework the Commerce base field views integration to track the whole effort. Re-added the delta field in #3097586: Multivalue base fields are missing the "delta" views field.
@Gode.Agarunov
Please test the next -dev and confirm that the delta field now works as previously.
If you encounter any problems, post them to #3097586: Multivalue base fields are missing the "delta" views field.
I am going to keep this issue open for investigating upgrade path issues (based on the view in #16).
Comment #19
Gode.Agarunov commented@bojanz latest dev brought the delta filter back, everything works as expected, thanks!
Comment #20
bojanz commentedI found what the problem is with the view in #16.
Our update function tries to fix all views, even Search API ones, even though the Search API ones don't need fixing, so they get broken in process. The solution is to make the update functions more conservative.
Comment #21
bojanz commentedHere's a proposal.
Comment #23
bojanz commentedComment #24
andyd328Thanks @bojanz, I just tested it, and by the time I'd put in the patch in composer and pulled down the latest dev you'd already committed it and it didn't apply!
Happy to confirm that the view in #16 works. Thank you for your time & effort.
Comment #26
drupalfan2 commentedI have a similar problem, but I am not sure if it is the same:
Missing/broken relationship handler in commerce_cart_form after upgrading to Drupal 9
https://www.drupal.org/project/commerce/issues/3258214
How can I solve it?