#!/bin/bash

# shellcheck disable=SC1090,SC1091

set -o errexit
set -o nounset
set -o pipefail
# set -o xtrace # Uncomment this line for debugging purpose

# Load WordPress environment
. /opt/bitnami/scripts/wordpress-env.sh

# Load WP-CLI environment for 'wp_execute' (after 'wordpress-env.sh' so that MODULE is not set to a wrong value)
. /opt/bitnami/scripts/wp-cli-env.sh

# Load PHP environment for 'wp_execute' (after 'wordpress-env.sh' so that MODULE is not set to a wrong value)
. /opt/bitnami/scripts/php-env.sh

# Load libraries
. /opt/bitnami/scripts/liblog.sh
. /opt/bitnami/scripts/libwordpress.sh
. /opt/bitnami/scripts/libwebserver.sh
. /opt/bitnami/scripts/libvalidations.sh

# Load web server environment (after WordPress environment file so MODULE is not set to a wrong value)
. "/opt/bitnami/scripts/$(web_server_type)-env.sh"

########################
# Converts the WordPress application host to a domain (that can use subdomains), if it isn't one already
# Note that WordPress Multisite is configured by default to use the subdomain mode, and IP addresses don't support subdomains
# As a fallback, we will rely on the nip.io service
# Examples:
#   wordpress_hostname_to_fqdn mydomain.com -> mydomain.com
#   wordpress_hostname_to_fqdn 11.22.33.44 -> 11.22.33.44.nip.io
#   wordpress_hostname_to_fqdn ec2-11-22-33-44.amazonaws.com -> 11.22.33.44.nip.io
# Globals:
#   None
# Arguments:
#   $1 - application hostname
# Returns:
#   Application domain to use (with subdomain support)
#########################
wordpress_convert_hostname_to_domain() {
    local host="${1:?missing host}"
    local -r octet_regexp="(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])"
    local -r aws_host_regexp="^ec2-(${octet_regexp}-${octet_regexp}-${octet_regexp}-${octet_regexp})\.amazonaws.com$"
    if validate_ipv4 "$host"; then
        echo "${host}.nip.io"
    elif [[ "$host" =~ $aws_host_regexp ]]; then
        echo "${BASH_REMATCH[1]//-/.}.nip.io"
    else
        echo "$host"
    fi
}

# Unfortunately wp-cli does not provide a way to set all options one-by-one, specifically values in wp_blog and wp_site
# So we need to rely on the search-replace functionality instead
# The good thing is that any link in posts, uploads, etc., will be updated to the proper value

WORDPRESS_NEW_SERVER_HOST="$(wordpress_convert_hostname_to_domain "${1:?missing host}")"

# Get current server host from the database
# It is not a good idea to rely on the configuration file, since the real source of truth is the DB
# Additionally, if a wrong hostname is specified in the config file (not matching with what is in the DB), the site will not work
info "Retrieving current WordPress multisite hostname/domain"
WORDPRESS_CURRENT_SERVER_HOST="$(wp_execute_print_output db query 'SELECT domain FROM wp_site WHERE id=1' --skip-column-names --silent)"
if [[ -z "$WORDPRESS_CURRENT_SERVER_HOST" ]]; then
    WORDPRESS_CURRENT_SERVER_HOST="$(wordpress_conf_get DOMAIN_CURRENT_SITE)"
fi

info "Updating hostname/domain for WordPress Multisite"
# For security purposes, the configuration file is not writable by the web server at runtime
chmod g+w "$(readlink -f "$WORDPRESS_CONF_FILE")"
# Set the new domain, first in the database and then in the configuration file
# Note: Using an empty --url to avoid any failure if the current URL is not properly configured
wp_execute --url=http: search-replace "$WORDPRESS_CURRENT_SERVER_HOST" "$WORDPRESS_NEW_SERVER_HOST"
wordpress_conf_set "DOMAIN_CURRENT_SITE" "$WORDPRESS_NEW_SERVER_HOST"
# Restore wp-config.php permissions
chmod g-w "$(readlink -f "$WORDPRESS_CONF_FILE")"

# Reload PHP-FPM configuration to ensure that the home page redirects to the new domain
/opt/bitnami/scripts/php/reload.sh