>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3619006. --> Reported by: [introfini](https://www.drupal.org/user/42293) Related to !11 >>> <h3>Problem/Motivation</h3> <p>The admin form presents <code>api.synchronize_user</code> as the switch for user synchronisation, but nothing at runtime ever reads it. The two hooks call <code>UserSynchronizer::push()</code> unconditionally:</p> <pre><pre>function advanced_mautic_integration_user_update(EntityInterface $entity) {<br>&nbsp; try {<br>&nbsp;&nbsp;&nbsp; $user_synchronizer = \Drupal::service('advanced_mautic_integration.user_synchronizer');<br>&nbsp;&nbsp;&nbsp; assert($entity instanceof UserInterface);<br>&nbsp;&nbsp;&nbsp; $user_synchronizer-&gt;push($entity);<br>&nbsp; }<br>&nbsp; catch (\Exception $e) {<br>&nbsp;&nbsp;&nbsp; \Drupal::logger('advanced_mautic_integration')-&gt;error($e-&gt;getMessage());<br>&nbsp; }<br>}<br><br>function advanced_mautic_integration_user_insert(EntityInterface $entity) {<br>&nbsp; advanced_mautic_integration_user_update($entity);<br>}</pre></pre><p>Grepping the project for the key finds it only inside <code>MauticAdminSettingsForm</code>: the checkbox default, two <code>#states</code> conditions, one validation rule and the save. No other file consults it.</p> <p>So unticking "Synchronize users" changes what the form looks like and nothing else. The operator has no way to tell from the site that the setting is inert.</p> <h3>What it costs</h3> <p><code>push()</code> resolves the contact before deciding whether it has anything to write:</p> <pre><pre>public function push(UserInterface $user): void {<br>&nbsp; $lead_id = $this-&amp;gt;getLeadIdForUser($user);<br>&nbsp; if ($lead_data = $this-&amp;gt;convertUserToLead($user)) {<br>&nbsp;&nbsp;&nbsp; // create or edit<br>&nbsp; }<br>}</pre></pre><p><code>getLeadIdForUser()</code> falls through to <code>getLeadByParameter($user-&amp;gt;getEmail())</code>, which is a remote call. Every user save therefore costs a synchronous HTTP round trip to Mautic, from inside whatever database transaction the caller had open, and it happens even when <code>api.user_lead_mapping</code> is empty and there is provably nothing to write.</p> <p>Two situations where this is more than wasted time:</p> <ul> <li><strong>Bulk work.</strong> An import, a migration or a repair script pays one Mautic round trip per user, inside its transaction.</li> <li><strong>A filled mapping on a site that believes the feature is off.</strong> There <code>push()</code> does not just look up, it creates a contact for an address Mautic has not seen. That is a surprising way to discover the setting does nothing.</li> </ul> <h3>Proposed resolution</h3> <p>Consult the setting before doing any work:</p> <pre><pre>function advanced_mautic_integration_user_update(EntityInterface $entity) {<br>&nbsp; if (!\Drupal::config('advanced_mautic_integration.settings')-&amp;gt;get('api.synchronize_user')) {<br>&nbsp;&nbsp;&nbsp; return;<br>&nbsp; }<br>&nbsp; // ... as today<br>}</pre></pre><p>Worth settling in review: whether the guard belongs in the hooks or at the top of <code>UserSynchronizer::push()</code>. Guarding the hooks leaves <code>push()</code> as an explicit escape hatch for a caller that deliberately wants to push one user; guarding <code>push()</code> makes the promise unconditional but takes that option away. The first seems the better split, but either is an improvement on today.</p> <p>Separately, and worth doing even with the guard in place: <code>push()</code> could build <code>$lead_data</code> first and return early when it is empty, so that a site with no mapping never issues the lookup at all. The current order means the expensive half runs to support a decision the cheap half could have made.</p> <h3>Workaround, for anyone who lands here first</h3> <p>A site module can drop the implementations without patching the project, which survives <code>composer update</code>:</p> <pre><pre>function mymodule_module_implements_alter(array &amp;amp;$implementations, string $hook): void {<br>&nbsp; if ($hook === 'user_insert' || $hook === 'user_update') {<br>&nbsp;&nbsp;&nbsp; unset($implementations['advanced_mautic_integration']);<br>&nbsp; }<br>}</pre></pre><h3>Remaining tasks</h3> <ul> <li>Agree where the guard belongs</li> <li>Patch, and check behaviour with the setting both on and off</li> </ul> <h3>User interface changes</h3> <p>None. The existing checkbox starts doing what it already says.</p> <h3>API changes</h3> <p>None, if the guard goes in the hooks.</p>