signalto / signalto_bridge

0.1.0 2026-09-16 05:25 UTC

Requires

• php: >=8.1
• drupal/core: ^10.3 || ^11

GPL-2.0-or-later

• SignalTo

Published on Packagist.org on 2026-09-16 05:25 UTC

README

Connects a Drupal 10.3+ / 11 site to SignalTo so that audit-driven fixes — robots.txt, llms.txt and other root files, redirects, response headers, and per-page body copy / meta tags / JSON-LD — can be previewed, applied, verified live and rolled back from SignalTo, with a Drupal revision for every content change.

Install (10 minutes)

composer require signalto/signalto_bridge
drush en signalto_bridge
drush signalto:pair <PAIRING-CODE> --uri=https://www.example.com

or enable the module on the Extend page and paste the pairing code at Configuration → Web services → SignalTo Content Bridge (/admin/config/services/signalto-bridge). The pairing code is shown in SignalTo when you link the site. The site is reported to SignalTo as https://<your host> — pair from the public hostname, or pass --uri/--site-url to drush.

What the module never does: write to the codebase or theme files, change a page's text format, publish content, or read unpublished/restricted content unless you enable "Allow SignalTo to read unpublished content" on the settings page.

robots.txt — one change per host

Drupal ships a physical robots.txt that composer copies into the docroot on every build, and the webserver answers it before Drupal runs. SignalTo reports this honestly as "robots.txt is shadowed" until it is out of the way:

• Apache (.htaccess) — exclude the file from scaffolding and remove it:

  "extra": { "drupal-scaffold": { "file-mapping": { "[web-root]/robots.txt": false } } }

  then rm web/robots.txt (adjust for your web root) and deploy. Drupal's .htaccess passes the missing file through to index.php.
• nginx — the standard Drupal recipe has an exact-match block that never falls through to Drupal. Replace it (or add try_files):

  location = /robots.txt { allow all; log_not_found off; access_log off; try_files $uri @rewrite; }

  where @rewrite is your index.php fallback location.
• Pantheon — the platform serves its own robots.txt on *.pantheonsite.io; your site's robots.txt is served only on the Live environment of a paid plan with a custom domain. Managed robots.txt works there; elsewhere SignalTo reports it as platform-managed.
• Acquia — non-production environments serve robots_block.txt; manage robots.txt on production only.

llms.txt and the other root files need no change on Apache. If you run the contrib fast_404 module, its default extension regex swallows .txt before Drupal boots — add llms.txt|llms-full.txt|ai.txt|security.txt|humans.txt to $settings['fast404_whitelist'] (or exclude .txt from fast404_exts).

Caching and CDNs

Managed robots/root files and redirects are served with Cache-Control: public, max-age=60 outside Drupal's page cache. Page changes (body, meta, JSON-LD) invalidate the node's cache tags; if your host CDN is wired to Drupal cache tags (Pantheon Advanced Page Cache, Acquia Purge) it purges immediately, otherwise SignalTo waits for the CDN's TTL before verifying. Acquia's Varnish holds 301 and 404 responses for at least 15 minutes regardless of headers.

Behind a proxy or CDN

Drupal only trusts X-Forwarded-Proto when $settings['reverse_proxy'] is set. The module never relies on the request scheme: pairing always reports https://, and redirect targets are built from the paired site URL.

Updates

The module is installed from Packagist (composer update signalto/signalto_bridge). Drupal's Update Status page lists it as "not supported / no available releases" until it is published on drupal.org — that is expected.

Removing

drush signalto:disconnect (or the Disconnect button) removes the pairing, the key and every managed item. drush pmu signalto_bridge does the same and removes the module. The site returns to exactly what it served before.