🇺🇸United States @xaqrox

xaqrox → made their first commit to this issue’s fork.

#32 updated for 1.17/current 1.x

I tested this on simplytest.me: I added the share block to the block layout, made a change to the global config. Reloaded the page, my change was not reflected. Cleared the cache and reloaded, change was reflected. I did not expect the code added in https://www.drupal.org/project/addtoany/issues/3212302 🐛 Block Display is random for anonymous Fixed to fix this, because it doesn't account for the dependency on the global config.

reroll for 9.5.9

My bad! Here's the interdiff.

Was using the previous patch on a project that included blocks with paragraphs, and we had a similar problem again: cloned blocks were referencing the same paragraphs as their source nodes. Editing paragraphs seemed to work since the actual field refers to revisions, but if you deleted one of the blocks the paragraph would be deleted as well. Here's a patch that includes cloning the paragraphs of the cloned blocks (and some slightly opinionated refactoring of the cloneParagraphs function).

A couple notes on this and other topics —

1. This dependency is probably needed in more places, but I'm not sure what is the most Drupaly way to add a cache dependency to a theme hook everywhere. template_preprocess_HOOK()? That would make the merge request obsolete.
2. In looking thru this, I started to feel like addtoany_create_data() and addtoany_create_entity_data() should be moved into a service and decomposed into functions for each of the variables. Don't have a *great* reason for that, just a code smell instinct.
3. If there was a template_preprocess_HOOK() implementation, that is where the defaults from the settings could be filled in. For example, the extra field would likely always provide URL and title, but if the user doesn't specify icon size, then it could get filled in from the default config. The block could provide icon size and custom_html, and if URL/title was not provided, they could get filled in from the current route in the hook. In the process, if there is a need to hit the default config, that is when the cache dependency could be added. (It may also be that there are settings that will always be needed to build the markup, in which case the dependency should be added in every case.)

xaqrox → created an issue.

Yep, the patches were just for convenience.