Thanks, nuez → !
Just a quick addendum that I added a merge-request to this bug report that I *think* reproduces the 2.0.x patch I initially uploaded. My apologies if I didn't quite do this right....
kmitch → created an issue.
Thank you so much, @wouter-waeytens !!! We recently noticed that our fa-icon-picker widgets weren't working with entity fields, and I struggled for a lot longer than I'd like to admit to figure out why this was happening.
I have no idea how you figured out that BigPipe was the culprit, but am *very* happy that you did, and that I eventually stumbled across your bug report, and I can report that the patch works perfectly in our Drupal 10 installation.
A strange aside on this: while existing fontawesome-field entries won't show the icon-picker widget (due to the JS error described above), if your field is configured for unlimited values and you click on the "Add another item" button in the fontawesome-field, the icon-picker widget now works for all instances of the field (and no additional JS errors in the browser console). This is also true when you create a new entity (node, paragraph, etc.), as the JS error seems to be tied to rendering existing values rather than new values. However, this only applies to the current editing session, as you have to do this workaround all over again when you re-edit the entity.
Needless to say, this pseudo-workaround isn't popular with our users, so having a patch-fix in place is fantastic. Thanks for figuring this out!
A big thank you to everyone who's contributed to this issue! I (perhaps foolishly) upgraded directly from v1.22 to v2.0.0 and ran into a *lot* of search-api-integration issues with metatag fields, and this issue seemed to be the most current one to help me get back on track.
I'm not sure if this is still the right place to follow for official post-v2.0.0 search-api integration? Issue #3326104 seems to suggest that this current issue will be used to re-implement search-api integration in 2.x, but the recent patches and activity in this issue seem to be focused on the 1.x branch, and consequently the patches don't work as-is with the 2.x branch code. But perhaps that will be coming with future activity?
Regardless, for what it's worth I adapted the most recent patch from @benabird (metatag-n3315049-24.patch) to work with the 2.x branch. It seems to work as intended in a Drupal 9.5.10 (PHP 8.1.x) environment, but I suspect it has the same test failures that the #24 and previous patches triggered.
Fantastic! Thanks for all your help and quick work on this @japerry -- I really appreciate it!
Thanks again @japerry -- this is really helpful! And I appreciate the extensive explanation of the mechanics in the new gtag.js implementation. That makes perfect sense now why v2.x was only using one of our Drupal containers, since they had identical conditions. And it will be great to be able to have multiple GTM IDs cited in the <script> tag once that portion of the code is enhanced. Thank you!
Thanks too for dealing with what is likely an outlier for most sites. The main reason we have (and need) multiple GTM container IDs on each page in our site is because of a legacy arrangement with our site where an outside contractor is using their own GTM container to inject some marketing-related tags on select pages on our site, and we ended up wanting our own GTM container to not only fold in our Google Analytics tracking codes but also to add our own GTM tags to other pages on our site. It would probably have been best if we had worked with the contractor to share access to a single GTM container/account, but there seemed to be some contractual barriers to this, so we're stuck with needing to inject two different GTM container IDs on every page in our site. I'm just glad to know that we now have a path forward for this in the 2.x branch--thank you!
Thanks, @japerry -- I really appreciate your reply and the additional information. And I look forward to seeing the revised documentation and code, as well as trying out the ability to have multiple GTM IDs in a single Drupal container.
I wonder, though, if our local installation might have glitched when I updated from google_tag v1.6 to v2.0.1? The update/migration seemed to do exactly what you described: it converted our two GTM container IDs into two separate Drupal containers with the two different GTM IDs associated with the respective Drupal containers.
However, when I looked at the public-facing pages of the site, only one of the two GTM IDs was showing up in the <head> section as a GTM <script> entry. I could only get both GTM ID <script> entries to appear in the public-facing pages by downgrading back to v1.6.
Based on my reading of your reply, though, it sounds as if we should have seen both GTM ID <script> entries in public-facing pages in our two-Drupal-containers-with-one-GTM-ID-in-each-container scenario? In v2.0.1 I couldn't seem to get two GTM <script> entries on our public-facing pages no matter what combination of things I tried -- using the default migration setup (two Drupal containers with separate GTM IDs), starting fresh with two separate Drupal containers with two different GTM IDs, putting both GTM IDs in one Drupal container, etc. It sounds like that latter scenario (two GTM IDs in one Drupal container) isn't ready yet in 2.x, but it sounds like the first two approaches _should_ have worked, yet didn't, at least in our installation.
I'm not sure if the missing GTM <script> entry on our site is due to a coding issue, or a user-comprehension issue? Either way, though, I look forward to testing out the enhancements when they get rolled out.
Thanks again,
Ken
Thanks, @gisle and @vihshal.kadam -- I really appreciate your help! And sorry for the long delay in replying on this; I had assumed (wrongly) that I would automatically be notified by email when my issue was updated, but then discovered that I had to set this up on my drupal.org account.
Thanks again for your help un-spamming me!
kmitch → created an issue.