<h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>On Drupal <strong>11.4+</strong>, HTML responses may include <code>page_top</code> and <code>page_bottom</code> in <code>#attached</code>. Core documents these keys in <code>Drupal\Core\Render\HtmlResponseAttachmentsProcessor::processAttachments()</code> as allowed attachment types alongside <code>library</code>, <code>drupalSettings</code>, etc.</p> <p><strong>Attach Inline</strong> replaces the <code>html_response.attachments_processor</code> service with <code>Drupal\attachinline\Render\HtmlResponseAttachmentsProcessor</code>. That subclass validates <code>#attached</code> keys against a whitelist that matches an older core list and <strong>does not</strong> include <code>page_top</code> or <code>page_bottom</code>. When those keys are present, the processor throws:</p> <pre>LogicException: You are not allowed to use page_top in #attached.</pre> <p>This is not limited to a single feature: any code path that bubbles <code>page_top</code> into attachments can trigger it. Examples include <strong>node preview</strong> and core patterns such as the block layout backlink (<code>#attached['page_top']</code> in <code>Drupal\block\Controller\BlockController</code>).</p> <p><strong>Environment (example):</strong></p> <ul> <li>Drupal core: 11.4.x</li> <li>attachinline: 8.x-1.9</li> <li>PHP: 8.3</li> </ul> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Enable <code>attachinline</code> (and a project that depends on it, if applicable).</li> <li>Edit an existing node and use <strong>Preview</strong> (full view mode), or visit a route that attaches markup under <code>page_top</code>.</li> <li>Load the preview URL (e.g. <code>/node/preview/{uuid}/full</code>).</li> <li>Observe a fatal <code>LogicException</code> in <code>HtmlResponseAttachmentsProcessor->processAttachments()</code> (attachinline), line ~52.</li> </ol> <p><strong>Minimal programmatic check</strong> (with attachinline enabled): build an <code>HtmlResponse</code> whose attachments include <code>page_top</code>; processing via <code>html_response.attachments_processor</code> throws the same exception. Core’s processor accepts the same attachments.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Add <code>page_top</code> and <code>page_bottom</code> to the allowed-key list in <code>Drupal\attachinline\Render\HtmlResponseAttachmentsProcessor::processAttachments()</code>, matching core’s whitelist for Drupal 11.4+.</p> <p><strong>Why a new patch / MR (not an existing queue fix):</strong></p> <ul> <li>We hit this on production-like sites after upgrading to <strong>Drupal 11.4</strong>; attachinline <strong>1.8</strong> still uses the pre-11.4 attachment whitelist.</li> <li>Issue queue search for <code>page_top</code> on this project did not surface a merged fix for 1.9 at the time of reporting.</li> <li>The fix is intentionally <strong>minimal</strong>: two whitelist entries, no API or UI change—parity with core so inline asset handling continues to work on affected pages.</li> <li>Until this lands in an official release, sites are forced to carry a local Composer patch; contributing upstream removes that burden.</li> </ul> <p><strong>Files changed:</strong></p> <ul> <li><code>src/Render/HtmlResponseAttachmentsProcessor.php</code> — extend allowed <code>#attached</code> types with <code>page_top</code> and <code>page_bottom</code>.</li> </ul> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>[ ] Confirm reproduction on 11.4.x + attachinline 1.9</li> <li>[ ] Apply patch / merge MR</li> <li>[ ] Tag release or note in release notes for 11.4 compatibility</li> <li>[ ] (Optional) Add kernel/functional coverage if maintainers want a regression test</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>None.</p> <h3 id="summary-api-changes">API changes</h3> <p>None. Aligns attachinline behavior with core’s documented <code>#attached</code> keys.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None.</p>