>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3613875. --> Reported by: [abhishek-anand](https://www.drupal.org/user/468982) Related to !2 >>> <h3>Problem/Motivation</h3> <p>The module cannot be installed on Drupal 9, 10 or 11.<br> <code>purge_cache_warmer.info.yml</code> still carries the <code>core: 8.x</code><br> key that was removed in Drupal 9, and it has no<br> <code>core_version_requirement</code>.</p> <p>The failure is not limited to this module. Because the info file cannot be<br> parsed, the whole extension scan fails, so nothing at all can be installed<br> while this module is present in the codebase:</p> <pre><pre>$ drush en purge purge_queuer_url -y<br>In InfoParserDynamic.php line 55:<br>&nbsp; The 'core_version_requirement' key must be present in<br>&nbsp; .../purge_cache_warmer/purge_cache_warmer.info.yml</pre></pre><p>Both dependencies are alive and already support Drupal 11:</p> <ul> <li><code>purge</code> 8.x-3.7,<br> <code>core_version_requirement: ^9.5 || ^10 || ^11</code></li> <li><code>purge_queuer_url</code> 8.x-1.2,<br> <code>core_version_requirement: ^10 || ^11</code></li> </ul> <p>Reviewing <code>CacheWarmer.php</code> while making it installable turned up<br> defects that are worth fixing in the same pass.</p> <ol> <li><strong>A connection failure kills the whole queue run.</strong> The<br> plugin catches <code>RequestException</code>, but Guzzle's<br> <code>ConnectException</code> is a <em>sibling</em> of it, not a subclass.<br> Both extend <code>TransferException</code>. A DNS failure, refused<br> connection or TLS handshake error therefore escapes<br> <code>invalidate()</code> and terminates queue processing for every<br> remaining item.</li> <li><strong>A purged 404 is requeued forever.</strong> Guzzle's<br> <code>http_errors</code> is on by default, so a 404 becomes an exception,<br> is caught, and is marked <code>FAILED</code>. Warming the URL of a deleted<br> node can never succeed, so it is retried indefinitely.</li> <li><strong>TLS certificate verification is disabled</strong> via<br> <code>['verify' =&amp;gt; FALSE]</code>.</li> <li><strong>The logger is called with the exception text as the message<br> template</strong>, so any <code>@</code> or <code>%</code> in an exception<br> message is treated as a placeholder token.</li> <li><strong>No request timeout</strong>, so one hung origin request stalls<br> queue processing.</li> <li><strong><code>getIdealConditionsLimit()</code> is inherited as<br> 100.</strong> Every warm is a full uncached render on the origin, so<br> offering 100 at once is a self inflicted load spike.</li> <li>An invalidation of an unsupported type would leave its state unset, which<br> raises <code>BadPluginBehaviorException</code>.</li> </ol> <p>There are also no tests and no <code>.gitlab-ci.yml</code>.</p> <h3>Proposed resolution</h3> <ul> <li>Set <code>core_version_requirement: ^11</code>, drop the<br> <code>core: 8.x</code> key, and namespace the dependencies as<br> <code>purge:purge</code> and<br> <code>purge_queuer_url:purge_queuer_url</code>.</li> <li>Add a real <code>composer.json</code> with a <code>require</code> section,<br> license, homepage and support links.</li> <li>Catch <code>\Exception</code> around the whole per URL operation so one<br> bad URL can never abandon the rest of the batch.</li> <li>Set <code>http_errors</code> to FALSE and decide the state from the<br> status code. Any answer from the origin means the page was rendered again<br> and the caches in front of it hold a fresh copy, including 404s. Retry only<br> where the origin declined to render: 5xx, plus 408, 425 and 429. A final<br> 1xx is not a rendered representation, so it is also retried.</li> <li>Verify TLS certificates.</li> <li>Do not follow redirects. The invalidated URL is the one that needs<br> warming, and the redirect response is itself what the cache should hold.<br> This also stops one invalidation from turning into six requests.</li> <li>Set a 6 second request timeout and a 2 second connect timeout. Purge<br> rejects a time hint above 10.0 and sizes queue leases from it, so both<br> timeouts together have to stay under that ceiling. This matches the<br> constraint that <code>purge_purger_http</code> enforces in its own<br> configuration form.</li> <li>Log through a message template with placeholders.</li> <li>Lower <code>getIdealConditionsLimit()</code> to 10.</li> <li>Add kernel test coverage with a mocked HTTP client.</li> <li>Add a <code>.gitlab-ci.yml</code> and a <code>phpcs.xml.dist</code> that<br> enables <code>DrupalPractice</code>.</li> <li>Rewrite <code>README.md</code> to the current template.</li> </ul> <p>Purge 3.7 still discovers purgers by annotation. It ships no attribute<br> class, and <code>Plugin/Purge/Purger/PluginManager.php</code> passes the<br> annotation class where Drupal 11 expects an attribute class, relying on core's<br> backward compatibility branch. So <code>@PurgePurger</code> is kept rather than<br> converted to a PHP attribute. Converting it would break discovery.</p> <h3>Remaining tasks</h3> <ul> <li>Review.</li> <li>Decide whether to restrict which origins may be warmed, see below.</li> </ul> <h3>User interface changes</h3> <p>None.</p> <h3>API changes</h3> <p><code>CacheWarmer::invalidate()</code> gains a <code>void</code> return<br> type. <code>routeTypeToMethod()</code> is removed because it only returned what<br> <code>PurgerBase</code> already returns.</p> <h3>Data model changes</h3> <p>None.</p> <h3>Related issues</h3> <p>This supersedes or resolves:</p> <ul> <li>#3390937 Need this module compatible for Drupal 10, reported by<br> sairamraavi, who also opened MR !1. That MR is not usable as is: it adds<br> <code>core_version_requirement</code> while leaving the<br> <code>core: 8.x</code> key in place, which Drupal rejects, and its<br> <code>.gitlab-ci.yml</code> is the stock GitLab sample template rather than<br> the Drupal Association includes. The report was correct though, and<br> predates this issue.</li> <li>#3073090 Dependency namespacing in .info.yml file, reported by<br> alonaoneill.</li> <li>#2874040 Correct url for purge_queuer_url module in description, reported<br> by nketchum, fixed as part of the README rewrite.</li> <li>#3141449 Automated Drupal Rector fixes, an obsolete bot issue from<br> 2020.</li> </ul> <p>Not addressed here, and left open:</p> <ul> <li>#2845068 Support For Multiple Balancers. That needs an API change in<br> Purge itself and deserves its own issue.</li> </ul> <h3>Follow up: which origins may be warmed</h3> <p><code>purge_queuer_url</code> builds registry URLs from the inbound HTTP<br> Host header unless <code>host_override</code> is configured, and Symfony only<br> validates that header when <code>trusted_host_patterns</code> is set, which is<br> not the default. On a site without <code>trusted_host_patterns</code>, an<br> attacker who can get a cacheable response registered under a hostname they<br> control can later have this module issue a GET to an address of their<br> choosing.</p> <p>Not following redirects removes the easiest escalation. A full fix belongs<br> with the queuer, or in a follow up that lets a site declare which origins may<br> be warmed. Sites should set <code>trusted_host_patterns</code>, and<br> <code>host_override</code> in the queuer, in the meantime.</p>