[mrrobot47]

Pairs with EasyEngine/site-command#521 and should ship in the same release.

Problem

WordPress is installed with https:// URLs (wp core install --url=https://<site>) before the certificate step. When that step can't issue the certificate, site-command#521 keeps the site on plain HTTP, but WordPress kept home/siteurl on https. Visitors and wp-admin were redirected to HTTPS, which isn't served for the site. The same happens while a manual DNS-01 challenge (no Cloudflare API key) waits for ee site ssl-verify.

Changes

• After www_ssl_wrapper() in the create flow (run_ssl_step()), if WordPress was installed with https URLs but the site isn't served over HTTPS (site-command cleared site_ssl, or a Let's Encrypt certificate is still pending), the URLs are switched back to http with wp search-replace https://<site> http://<site> --precise (--network for multisite). A fresh install needs no DB backup. --skip-install sites are skipped.
• update --ssl=le still switches the URLs to https when it issues the certificate. While a manual DNS-01 challenge is pending it leaves them on http, and the new site_scheme_changed() override switches them once site-command turns HTTPS on (standalone ssl-verify, or a renewal or alias update that issues the first certificate). It does nothing on a site without WordPress installed.
• The backup and search-replace of update_ssl() move to replace_url_scheme(), with the same output. A failed search-replace now warns and names the command to run, instead of reporting success.
• With an older site-command (no pending state), only the failed create is handled; function_exists() guards the new helper.

Testing

• Unit tests (PHP 7.4 and 8.5, throwaway containers, with site-command#521): failed create and pending challenge switch the URLs to http without a backup, multisite uses --network; nothing is switched for an issued certificate, self-signed SSL, a site installed on http or --skip-install; update --ssl=le switches to https with a backup, and not while pending; site_scheme_changed('https') switches with a backup and skips a site without WordPress installed; a failed search-replace warns. 11 of the 12 new tests fail on develop; the rest of the suite is unchanged.
• Behat on a hosted runner with Pebble (Let's Encrypt's test server), together with site-command#521:
  • WordPress create whose www validation fails: served over HTTP, home/siteurl are http and the site answers 200 over HTTP; after update --ssl=le the certificate covers www, home/siteurl are https, http redirects to https;
  • manual DNS-01 WordPress create: served over HTTP with http URLs, update --ssl=le points to ssl-verify; after the TXT records are published, ssl-verify turns HTTPS on, adds the HTTPS www redirect and switches the URLs to https;
  • this repo's Behat suite passes, including the normal Let's Encrypt create (https URLs, verified HTTPS).

[Copilot]

🟡 Changes recommended

The new scheme-change hook leaves subdomain multisite URLs on HTTP when subsites are created before certificate verification.

1 open issue

• Rewrite pending HTTPS URLs for network subsites · New

What changed in this PR

Keeps WordPress URLs aligned with the site's HTTP or HTTPS state, complementing EasyEngine/site-command#521 when certificate issuance fails or remains pending.

Changes:

• Restores HTTP URLs after creation when HTTPS is unavailable.
• Adds a scheme-change hook to update URLs when certificate verification enables HTTPS.
• Centralizes URL replacement and backup handling, and warns when replacement fails.

File	Description
src/​WordPress.php	Coordinates WordPress URL schemes with certificate state and shares backup and replacement logic.

_{Review effort: Balanced}