Skip to main content

WordPress configuration

The site URL constants​

wp-config.php defines the two WordPress URL constants. Because constants override the values stored in the database, this is the single most important configuration on the site, and it is the reason Settings > General shows the URL fields greyed out. That is expected behavior, not a fault.

The block currently reads:

if ( defined( 'WP_CLI' ) ) {
        $_SERVER['HTTP_HOST'] = '127.0.0.1';
}

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
        $_SERVER['HTTPS'] = 'on';
}

define( 'WP_HOME', 'https://nutritionistpro.com' );
define( 'WP_SITEURL', 'https://nutritionistpro.com' );
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
/* That's all, stop editing! Happy publishing. */

The HTTP_X_FORWARDED_PROTO guard makes WordPress's is_ssl() return true when Cloudflare forwards a request that arrived over HTTPS. Without it, WordPress judges the scheme from what Apache received rather than what the browser sent. With HTTPS URLs hardcoded and Apache seeing HTTP, canonical redirects can bounce between the two schemes and loop. This guard is what prevents that.

A Bitnami stack upgrade can revert this file

Bitnami ships wp-config.php with dynamic constants derived from the request host and hardcoded to http://. An upgrade may restore that version and silently reintroduce every symptom below. Recheck these constants after any stack upgrade.

The Bitnami default that must not come back:

define( 'WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/' );
define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/' );

What the Bitnami default broke​

Deriving the URL from $_SERVER['HTTP_HOST'] and forcing http caused three separate problems, all fixed on 26 July 2026:

  • Yoast emitted http:// in the robots.txt Sitemap: line and in the sitemap index's <loc> entries. Individual page URLs were correct https://, because those come from stored permalinks, which is why the inconsistency looked so odd.
  • The site served itself under the raw EC2 hostname. Anything reaching the origin by its EC2 address got a fully rendered copy of the site under that hostname, a live duplicate-content risk. It now redirects to the canonical domain.
  • WordPress could not detect HTTPS behind Cloudflare, since nothing translated the proxy's forwarded scheme.

There is a related trap in the WP_CLI block above. It sets HTTP_HOST to 127.0.0.1 for command-line runs, so under the old dynamic constants any WP-CLI command that regenerated a sitemap could poison the cache with a localhost URL. With the URLs hardcoded, that block can no longer affect output. Leave it in place; it is harmless now.

Changing the constants​

Follow the backup, validate, restart sequence in SSH access. After restarting, flush the Yoast sitemap cache, or the sitemap index will keep serving the old values even though the sub-sitemaps regenerate correctly:

sudo wp --path=/opt/bitnami/wordpress transient delete --all

The wp-admin equivalent is Yoast SEO > Settings > Site features: toggle XML sitemaps off, save, then on again and save.

Verification​

Run these from a local machine rather than the server, so the request goes through Cloudflare the way a real visitor's would:

curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}\n" https://nutritionistpro.com/
curl -s https://nutritionistpro.com/robots.txt | grep Sitemap
curl -s https://nutritionistpro.com/sitemap_index.xml | grep -o '<loc>[^<]*'
curl -s https://nutritionistpro.com/wp-json/ | python3 -c "import sys,json;d=json.load(sys.stdin);print('url :',d['url']);print('home:',d['home'])"

Expected results:

  • The homepage returns 200 with no redirect target. A 301 or 302 pointing back at https://nutritionistpro.com/ means a redirect loop, so roll back and check the Cloudflare SSL/TLS encryption mode.
  • The Sitemap: line reads https://nutritionistpro.com/sitemap_index.xml.
  • Every <loc> in the sitemap index is https://nutritionistpro.com/....
  • wp-json reports url and home both as https://nutritionistpro.com. These correspond to siteurl and home and must match.

Also confirm https://nutritionistpro.com/wp-login.php still loads and accepts a login, since the admin is where a scheme mismatch shows up first.

Turning off the video sidebar on a page​

The site uses the Divi theme, which shows a right-hand video sidebar on pages by default. To remove it from a single page, edit that page in wp-admin and scroll to the bottom of the edit screen, below the Meta boxes, to the Divi page settings panel. The page layout setting there controls the sidebar; set it to the no-sidebar option and update the page.

Do not open the Divi Builder

This is done from the standard WordPress page edit screen. There is no need to launch the Divi Builder, and doing so is slower and riskier for what is a single setting. Just edit the page and scroll to the bottom.

Cloudflare SSL/TLS mode​

The encryption mode under SSL/TLS > Overview must be Full (strict). If it is set to Flexible, Cloudflare sends plain HTTP to Lightsail, and hardcoded HTTPS URLs can produce an infinite redirect. The HTTP_X_FORWARDED_PROTO guard defends against this, but Full (strict) is the correct setting regardless. See Cloudflare for the full SSL configuration.