Thanks Scott! Correct, I did not try the https://drupal.stackexchange.com/a/179811 as I didn't want to add to my own confusion lol. Thanks for the clarifications! I'm almost done manually re-adding my filters & they're working as expected. Thanks again for your help.
Thank you for the quick reply!
I don't think it's #2 because mine fits what I see in the module & test submodule code, for example (looks the same before and after this module):
field_topics_target_id_reference:
id: field_topics_target_id_reference
table: node__field_topics
field: field_topics_target_id_reference
relationship: none
group_type: group
admin_label: ''
plugin_id: entity_reference
operator: or
value: { }
group: 1
exposed: true
expose:
operator_id: field_topics_target_id_reference_op
Looks like this module attempts to remove the '_reference' but that didn't happen for me. I wasn't sure if this line was a factor:
if (
$filter['plugin_id'] !== 'entity_reference'
Either way, I am able to delete the broken exposed filters and add them again, and they work as expected.
Question:
I am able to add the filters by adding 'field_name' but NOT the 'Related field_name..' as illustrated in the change record at
https://www.drupal.org/node/3403710 →
Is that expected? Maybe because this module successfully opted me in?
Thanks again, appreciate all your efforts
en-cc-org → created an issue.
Our site is also frozen at 10.2.7, but (not realizing patch #453 would work), I applied this patch https://www.drupal.org/files/issues/2024-04-17/3347343-comment156-10.2.x... → As mentioned, this patch required me to rebuild my views to use the new "field_name as a reference filter". All is stable for now. Thankful to those continuing to find solutions as we are very dependent on this feature.
Hello, thanks for the patch, it had been working fine with mailchimp 2.2.2 (core 10.2.2)
But, patch failed to re-apply when upgrading to 2.2.3 (and core to 10.2.7 if that makes any difference).
Other, unrelated patches re-applied OK. Wondering if it needs a re-roll?
Thanks
This patch has been essential for us, thank you. Are there remaining obstacles (test failures?) to getting this into a ds release? Thanks again.
en-cc-org → changed the visibility of the branch 10.2.x to hidden.
en-cc-org → changed the visibility of the branch 10.2.x to active.
I ended up creating a browser automation script to do the initial sync. I used UIPath but I'm sure anything that can use a browser to programmatically load a user in edit mode & save will work. I had to babysit it as it ran through thousands of users, sometimes timing/erroring out, but better than hours and hours of manual work (or incorrect data).
A heads up to anyone using composer on Windows, where as you know quotes can be problematic. After issuing the composer config command as outlined above, check your composer.json extra section. In my case, it looked like this, which passed validation but silently caused the vefl exception to be ignored:
BAD:
"drupal-lenient": {
"allowed-list": "[drupal/vefl]"
}
GOOD:
"drupal-lenient": {
"allowed-list": ["drupal/vefl"]
}
Same issue; mailchimp 2.2.2 on Drupal 9.5.10. Summary of my test findings:
The mailchimp subscription field stays NULL unless/until the user is manually opened for edit and saved (with or without any changes made to the user). Manually opening a user for edit pulls in the data from Mailchimp; for example you'll see the checkbox is automatically selected and interest groups populated IF the user's email exists in Mailchimp AND is a subscriber. If the user's email doesn't exist in Mailchimp OR exists there but is not subscribed, the checkbox will not be selected. Manually saving that user populates the field in the database, after which the user's profile will display either Subscribed or Not Subscribed (instead of being NULL). AFTER this manual open/save, the module is THEN able to update subscription status when any further changes are made on either side. How to avoid manually opening/saving thousands of users? Neither VBO nor Feeds is able to initially bulk populate the NULL mailchimp subscription field.
Searching the issue queue, found an old/D7 script, so I updated it for D9.
1. Load the user via \Drupal::entityTypeManager()->getStorage('user')->load($i); or \Drupal\user\Entity\User::load($i);
2. Make any change (for example, add a role)
3. Save the user via save();
The script updates & saves the user BUT the mailchimp subscription field is NOT updated.
What does the manual open/save do that allows it to initially access Mailchimp data, and how can I incorporate programmatically?
#7 bless you hockey2112, would never have thought to look there!
Same issue, local Windows with Pantheon, upgrading from 3.11 to 4.1.6. #26 💬 Class 'Drupal\simple_sitemap\Queue\SimpleSitemapQueue' not found Fixed worked like a charm for me, thanks @Sutharsan and all who contributed above.