I have two content types: Product Pages and Application Pages. Long story short, a "product" can depend on an application but NOT vice-versa and I'm trying to use CER to display this type of dependency. The problem is that CER is allowing products to be required by apps. It's populating my "field_product_required_by" with Application Pages when in the configuration, I've indicated for CER NOT to create corresponding references to application pages from product pages in the required by field.
These are the field names:
Remember: product pages can DEPEND ON applications but product pages CANNOT be required by applications.
Here's the CER configuration for the "field_product_required_by" field (i.e. - admin/config/system/cer):
With the above list, only options 1 and 2 are checked. But when I go to admin/config/system/cer/update and update the nodes, the "field_product_required_by" field is populated with application node reference values. This should not be happening.
I would appreciate any insight or suggestions about how to fix this.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | cer-batch-1945864-5.patch | 7.39 KB | phenaproxima |
Comments
Comment #1
wolf_22 commentedThe problem appears to be with how the batch processing works.
I did a test... I first batch-processed the nodes 10 at a time (versus the 50 default). This time, the dependencies appeared to be correctly set on the product page because I didn't see it get required by an app. However, when I went over to the corresponding app page that the original product page depended on, I noticed that the app didn't show the corresponding reference to the product in the required by field. So I went back to admin/config/system/cer/update and adjusted the threshhold to 20 for all nodes. Ran it. And then voila, it updated the app that previously did not show the CER to the product in the required by field.
I think there's something wrong with how the batch processing is working in this module on the admin/config/system/cer/update page. It seems to hit-and-miss...
Comment #2
phenaproximaI've encountered this problem too! Unfortunately I have not had a chance yet to really delve into the batch update code and get my head around it, but this is certainly a serious issue that needs to be addressed.
Comment #3
phenaproximaAssigning to myself and marking as a major issue.
Comment #4
wolf_22 commentedThanks, phenaproxima.
The module is truly awesome, but this issue--whatever it is--is making it very problematic. I think it has a lot to do with how the corresponding references are being stored / processed from the CER table. (I know that's really general, but for whatever it's worth...)
Comment #5
phenaproximaI have taken a stab at fixing this. Patch attached.
The long story
In looking at the batch update code, I noticed that it was doing some weird logic in order to divide the update job into chunks of a certain size. This seemed kinda pointless to me, since the whole point of the Batch API is to divide a resource-intensive task into manageable chunks. Although I'm still not sure how it would cause references to end up in the wrong fields, I decided to take a flaily approach by simplifying the batch update code so that it simply calls the cer_update function on every entity of the given type, one at a time, and let Batch API handle the logistics. To this end, I removed the limit field from the batch update form, as well as the entire
cer_batch_update_existing_entitiesfunction. The batch job is now kicked off in the form's submit handler.I tried this on the site where I was experiencing the problem before, and it seems to have updated all corresponding references flawlessly. So basically, this is a case of "I'm not 100% sure why this fixed it, but it seems to have fixed it." Please give this a try and let me know what your mileage is!
P.S. If I was totally off the mark with my assessment of this problem, let me know!!
Comment #6
phenaproximaMarking this issue for review.
Comment #7
wolf_22 commentedI just applied that that patch and so far, so good.
I didn't notice any lost data, inconsistencies, etc. I'll continue to test where appropriate because I still have a lot more content to test it out with. :.)
I'll post back if I find anything weird.
Comment #8
phenaproximaHi Wolf22,
I think I have honestly figured this out now. Are you finding that, for the most part, the fields which tend to get incorrect values during batch updates are the ones which use Views to select referenceable entities? 'Cause that's what was happening for me. I have found the cause of this, although I don't yet have a patch (it's in the works, but it involves massive streamlining of cer.crud.inc).
For me anyway, this had nothing to do with the batch handling code - although that, too, was overly complex and needed to be simplified. It has to do with the fact that although CER can watch Views-powered entity reference fields, it doesn't actually validate that an entity-to-entity reference is possible.
This isn't an issue when editing corresponding entities in the UI because Entity Reference is validating each individual reference, as it should. But, in batch update mode, CER is operating on the field values directly and doesn't bother to consult Entity Reference to make sure that it can, in fact, create a corresponding reference between two entities. So it can, and does, end up making invalid references. The solution (and this is what the patch will implement) is to validate the corresponding references through Entity Reference before actually saving any changes.
Comment #9
phenaproximaRe-tagging this issue.
Comment #10
wolf_22 commentedphenaproxima, I am using a view to display the fields but not to select their reference values.
Comment #11
phenaproximaThis should now be fixed in the 2.x branch. I had to fix this issue for my day job and tested it out on a client site, and it worked perfectly for me. That patch, in turn, was folded into the big refactoring that forms the basis of 2.x. Please check out a copy of 2.x and see if that fixes this problem for you too...
Comment #12
chertzog7.x-1.x is deprecated.