We have a growing number of users flowing in through social_auth (hundreds of thousands) and the issue of duplicate users has grown since originally reporting the issue.
We observed that the absence of the index cited in #5 🐛 Users with duplicate emails being allowed Active was slowing down the experience overall. Adding the index seems to speed things up substantially.
I suspect that there is still more to do to eliminate the root cause of the originally reported issue, but theoretically, speeding up queries for provider_user_id might help reduce the occurrence of the duplicates. I found that I could still reproduce the issue with the index in play, but it was much harder to replicate.
Any thoughts on this @wells?
I'll chime in on this as well. It would be highly desirable not to require these dependencies.
matt_paz → created an issue.
Might this be a duplicate of 🐛 FilterHtml data loss when iframe and/or textarea is allowed Active ? I noticed both Adrianm6254 and jesss have an iframe reference in their respective configs.
We observed similar issues. In addition to what others have done, I checked a healthy sample of the IPs. AFAICT, many were from bots like others observe. Several seemed to be from mobile ISPs. I saw others observe several mobile user agents were involved too. I wondered if some mobile ISPs are doing their own caching/reverse proxying in an attempt to improve perf in a way that might be contributing to this issue.
Just a quick update on this. In the year since we originally investigated the issue, there percentage of impacted users continues to be low, but on on one of our sites, it has grown to 800 cases. One user had five different variants. In one of these cases, there there were four variants, each with a different provider_user_id all created within several milliseconds of one another.
Impacts appear to be nominal, but I remain stumped on the underlying conditions that would result in what we're observing.
I guess I thought of it as a bug, but perhaps it should be reframed as a feature request.
This is because GPT's main learning source were contents of high quality links on Reddit website.
Also not sure that it exactly true (needs citations), but I grok the sentiment.
I'm not sure exactly what are you proposing here?
I wonder if the original issue here might need to be reframed a bit. Possibly as an exploration for how the Drupal Association might leverage AI/ML (using ChatGPT or other sources) to provide additional, drupal specific tooling (in this case, documentation, or in the case of https://www.drupal.org/project/ideas/issues/3336313 📌 Use ChatGPT for solving Drupal issues to increase rate of development Active , maybe ChatGPT plugins, or maybe some Drupal version specific versions of Co-Pilot style add-ons) that could help reduce the so-called learning cliff with Drupal and improve adoption and D/X overall?
The space is moving so fast, it is hard to determine what the right entry point might be, but I wouldn't want to damper interest/enthusiasm. Just maybe pair it with some pragmatism about scope and precision for where to start -- and what the trajectory might look like?
Definitely lots of potential here!
One drupalist shared info about project called https://astro.build/ for website building.
Said, Drupalist here chiming in with more info on this.
Here's a link to the original thread on slack:
https://drupal.slack.com/archives/C04NCQGGX0E/p1679583124916809
Subsequent to this, I noticed some additional chatter on Astro's Discord by Fred K. Schott (one of the maintainers).
https://discord.com/channels/830184174198718474/872579324446928896/10899...
Excerpting from the thread above he went on to note:
haha I'd actually trust something like https://www.kapa.ai/ more than Houston AI at this point!
Houston AI was a fun experiment at a time when no one was doing AI docs, but I think has suffered from lack of ownership / love and support since its launch
Definitely something to ponder should efforts from this issue take root.
Confirmed (for a site that did not have shurly.settings shurly_base configured).
Deprecation warnings ceased.
Thanks `No Sssweat` -- the updated MR LGTM! Will test next week and circle back.
matt_paz → created an issue.
matt_paz → created an issue.
I've been testing this a bit and it is looking good so far.
Other "User interface changes" that might be interesting to consider could include giving the user (in the preview) a hint that visibility conditions have been applied. I'm not quite sure what that would look like, but thought it might be worth passing along.