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 file is /var/www/wp-config.php on the current instance (see SSH access). The block installed on 2026-10-21 reads:

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' );

The same file also carries define( 'WP_CACHE', true ); (required by WP Rocket), define( 'WP_MEMORY_LIMIT', '256M' );, and the eight authentication salts copied from the old instance, all placed just above the /* That's all, stop editing! */ line. WP_AUTO_UPDATE_CORE is set to minor, as it was on the old instance.

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 fresh instance ships without this block

Both the retired Bitnami image and the current Lightsail-packaged image ship wp-config.php with dynamic constants derived from the request host and hardcoded to http:// (the Lightsail image's file was replaced by hand on 2026-10-21, with the original kept as /var/www/wp-config.php.bak). Any rebuild, restore from an image, or stack upgrade that touches this file silently reintroduces every symptom below. Recheck these constants after any such change.

The image default that must not come back:

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

What the image default broke​

Deriving the URL from $_SERVER['HTTP_HOST'] and forcing http caused three separate problems, all fixed on 26 July 2026 on the old instance (and avoided on the new one by installing the block before the content was imported):

  • 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.

The old Bitnami file also had a block that set HTTP_HOST to 127.0.0.1 for WP-CLI runs, so under the dynamic constants any WP-CLI command that regenerated a sitemap could poison the cache with a localhost URL. With the URLs hardcoded that cannot happen, and the new file has no such block.

Changing the constants​

Follow the backup, validate sequence in SSH access (no restart is needed on the current instance). Afterwards, flush the Yoast sitemap cache, or the sitemap index will keep serving the old values even though the sub-sitemaps regenerate correctly:

sudo -u www-data wp --path=/var/www/html 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.

Editing the scrolling sale announcement banner​

The scrolling announcement banner is a section at the top of the Global Header in Divi → Theme Builder. It is not managed by a separate announcement plugin or a WPCode snippet.

  1. In wp-admin, open Divi → Theme Builder and edit the Global Header.
  2. Select the announcement section at the top of the page, above the logo and navigation, then choose Settings to edit it. There is no need to switch to Wireframe View.
  3. Edit the announcement in the text module's Content → Body field. Review the sale wording, coupon code, expiry date, and link before publishing; the existing banner may contain an old promotion.
  4. Save the editor changes, then save the changes in Theme Builder. Check the public site to confirm the announcement displays correctly.

Making the banner visible​

The banner's section, containing row, and text module must all be enabled. For each, open Settings → Advanced → Visibility and leave all three Disable on checkboxes (Phone, Tablet, and Desktop) empty.

Start with the blue section gear, then repeat with the green row gear and Text Settings. A disabled section, row, or module can hide the announcement even when it appears in the builder preview.

Checked means hidden, not visible. Checking all three boxes disables the element on every device. To turn the entire banner off again, check all three boxes on its containing section.

Changing the banner colours​

  • Background: Open the blue section gear → Content → Background and choose a colour or enter its hex code. If the visible background does not change, check the row and text module's Background settings for a colour covering the section background.
  • Text: Open Text Settings → Design → Text → Text Color.
  • Suggested nectarine colour: #E6A13A is an approximate visual match for the warm golden-orange flesh in the nectarine reference image. Pair it with dark text, such as #222222, for readability.

Save the header changes, then click Save Changes in Theme Builder. Check the public site outside the editor, including on mobile. If it still shows the old banner, clear WP Rocket's cache and refresh.

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 the origin, whose port-80 virtual host answers with a redirect to https, 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.