balwuw

Hi @bcworkz,

Since you advised against (or hinted that you are not using) the Bitnami Config Tool (bnconfig), I’m pleaed to report that Bitnami themselves don’t emit a full-blown recommendation any longer, and really welcome the use of alternative solutions such as the script attached below (previous version posted on the Bitnami Support forum).

The topic of this thread as well as of “https://community.bitnami.com/t/local-wordpress-set-relative-uris-through-configuration/85649”>the other one over there were due to me mistakenly not fully reverting the changes made by the tool, but only to the extent shown in Move WordPress To A Different URL Path On The Same Domain With Apache in the Bitnami documentation. It was neither a WordPress issue nor a Bnconfig issue.

By contrast this is for me a path to fully understand how easy it is to move WordPress around without touching any of its files and folders beside editing three configuration files, and without dumping and restoring its database, provided that access is granted to the server configuration. That isn’t the case of shared hosting, i.e. for most live websites (including mine). But here on the localhost forum, pointing this out seems useful.

About absolute URLs, I much appreciate the linking facility in WordPress and am using the search function occasionally. Mostly however a fragment identifier is needed in addition, so that I’m just copy-pasting the address bar content.

The actual concern is when coding headers and footers, and using code snippets in posts for emoji. Hopefully we then can use absolute file paths as relative URLs. I didn’t get accustomed to the idea that every internal link should be internet-absolute instead of just root-absolute, i.e. internet-relative.

Anyway, here is a script that does the job both ways and is open-source so you may wish to check it out:

#!/bin/bash
# 2020-10-15T1343+0200
# confscript.sh
# Configure Bitnami WordPress base URL and corner logo display on Linux.
#
# This is designed to be run in the installation directory of a Bitnami WordPress stack:
#    cd <installation directory>
#    chmod +x confscript.sh
#    ./confscript.sh
#
# Supported actions:
# * Reconfigure the base URL of WordPress in a self-contained Bitnami WordPress stack;
# * Disable and re-enable the Bitnami corner logo in Bitnami WordPress.
#
# Bitnami documentation:
# <https://docs.bitnami.com/installer/faq/linux-faq/configuration/understand-bnconfig/>
# <https://docs.bitnami.com/general/administration/use-url-subpath/>
#
# Bitnami support forum:
# <https://community.bitnami.com/t/local-wordpress-set-relative-urls-through-configuration/85649>
#
# Copyright waiver: This is in the public domain.
#
# To address permission issues, set $sudo as "sudo" and follow instructions in:
# <https://community.bitnami.com/t/execution-by-root-not-allowed/4711/6>
sudo=""
helpsection() {
  case $1 in
    appurl)
      echo -e "\n --appurl <directory name>                   Change the directory in the WordPress URL."
      echo -e "\n --appurl /                                  Reconfigure the WordPress base URL to root."
    ;;
    cornerlogo)
      echo -e "\n --cornerlogo 0                              Disable the display of the Bitnami corner logo."
      echo -e "\n --cornerlogo 1                              Re-enable the display of the Bitnami corner logo.\n"
    ;;
    browsercache)
      echo -e "\n    To make it work accordingly in your browser, its cache"
      echo -e "    may need to be emptied of \"Cached images and files\".\n"
    ;;
  esac
}
if [[ "$1" = "--appurl" ]]; then
  dir=$2
  if [[ "$dir" = "" ]]; then
    helpsection appurl; echo
  else
    if [[ "${dir::1}" != "/" ]]; then
      dir="/$dir"
    fi
    # wp-config.php
    $sudo sed -i -e "s|define('WP_SITEURL.\+|define('WP_SITEURL', 'https://' . \$_SERVER['HTTP_HOST'] . '$dir');|" "apps/wordpress/htdocs/wp-config.php"
    $sudo sed -i -e "s|define('WP_HOME.\+|define('WP_HOME', 'https://' . \$_SERVER['HTTP_HOST'] . '$dir');|" "apps/wordpress/htdocs/wp-config.php"
		if [[ "$dir" = "/" ]]; then
	    if grep -q "# App url moved to root" "apps/wordpress/conf/httpd-prefix.conf"; then
	      echo -e "\n    The WordPress base URL has already been reconfigured to root.\n"
	    else
	      # httpd-prefix.conf
	      $sudo sed -i '1s|^|# App url moved to root\nDocumentRoot "/opt/wordpress-5.5.1-1/apps/wordpress/htdocs"\n|' "apps/wordpress/conf/httpd-prefix.conf"
	      $sudo sed -i -e 's|#*Alias|#Alias|g' "apps/wordpress/conf/httpd-prefix.conf"
	      # httpd-app.conf
	      $sudo sed -i -e 's|#*RewriteBase|#RewriteBase|' "apps/wordpress/conf/httpd-app.conf"
	      $sudo sed -i -e 's|RewriteRule \. /.\+/index.php|RewriteRule . index.php|' "apps/wordpress/conf/httpd-app.conf"
	      echo -e "\n    The WordPress URL has been reconfigured to root.\n"
	    fi
	  else
	    if grep -q "# App url moved to root" "apps/wordpress/conf/httpd-prefix.conf"; then
	      # httpd-prefix.conf
	      $sudo sed -i '/# App url moved to root/d' "apps/wordpress/conf/httpd-prefix.conf"
	      $sudo sed -i '/DocumentRoot/d' "apps/wordpress/conf/httpd-prefix.conf"
	      # httpd-app.conf
	      $sudo sed -i -e "s|RewriteRule \. index.php|RewriteRule . $dir/index.php|" "apps/wordpress/conf/httpd-app.conf"
	    else
	      # httpd-app.conf
	      $sudo sed -i -e "s|RewriteRule \. /.\+/index.php|RewriteRule . $dir/index.php|" "apps/wordpress/conf/httpd-app.conf"
	    fi
	    # httpd-prefix.conf
	    $sudo sed -i -e "s|#*Alias /.\+/ \"|Alias $dir/ \"|" "apps/wordpress/conf/httpd-prefix.conf"
	    $sudo sed -i -e "s|#*Alias /.\+[^/] \"|Alias $dir \"|" "apps/wordpress/conf/httpd-prefix.conf"
	    # httpd-app.conf
	    $sudo sed -i -e "s|#*RewriteBase .\+|RewriteBase $dir/|" "apps/wordpress/conf/httpd-app.conf"
	    echo -e "\n    The directory $dir has been configured as the base URL."
	  fi
	fi
  echo -e "\n    The Apache server will be restarting.\n"
  # "Execution by root not allowed"
  $sudo ./ctlscript.sh restart apache
  helpsection browsercache
elif [[ "$1" = "--cornerlogo" ]]; then
	if grep -q "# App url moved to root" "apps/wordpress/conf/httpd-prefix.conf"; then
	  if [[ "$2" = "0" ]]; then
	    if test -f "apps/bitnami/banner/disable-banner"; then
	      echo -e "\n    The Bitnami corner logo is disabled.\n"
	    else
	      $sudo echo > "apps/bitnami/banner/disable-banner"
	      echo -e "\n    The Bitnami corner logo has been disabled.\n"
	    fi
	  elif [[ "$2" = "1" ]]; then
	    if test -f "apps/bitnami/banner/disable-banner"; then
	      $sudo rm "apps/bitnami/banner/disable-banner"
	      echo -e "\n    The Bitnami corner logo has been re-enabled.\n"
	    else
	      echo -e "\n    The Bitnami corner logo is enabled.\n"
	    fi
	  else
	    helpsection cornerlogo; echo
	  fi
	else
		echo -e "\n    The Bitnami corner logo only appears when"
		echo -e "    the WordPress URL is reconfigured as root.\n"
	fi
else
  helpsection appurl
  helpsection cornerlogo; echo
fi

Thank you. Indeed being able to move WordPress manually is more secure and versatile. Although involving many steps, it isn’t bound to the limitations of the cited migration plugin, that drew also serious criticism. The method using the migration plugin is hailed by YouTube commenters as simple, efficient and time saving — surely for small websites. I think it’s in the straight line of what WordPress is designed to achieve: automation, and that AIO WP Migration is a good fit when looking for an easy method to widely recommend for starting up projects.

However, when automation goes at the expense of reversibility and flexibility, I’ll be going to discourage using it. But this is an issue that already has ways to work around it by using .htaccess if the Apache server shipped with the stack is to be used for other projects as well.

The Bitnami concept is extremely valuable as it helps spreading communication tools, and I think it deserves full support from WordPress.

Probably having WordPress in a subdirectory is not intuitive in the first place, since everything is designed for it to provide the home page. But it is indeed the best choice when it comes to packaging WordPress with everything needed in a self-contained stack.

As of absolute vs relative URIs, one reason why we need many root-relative URLs is emoji. We need to use the root directory to host a copy of the Twemoji set so we can work around the buggy emoji conversion script in WordPress by manually or semi-automatically replacing (perhaps an idea for a new plugin) emoji with e.g. <img class="emoji" alt="ℹ [i]" src="/svg/2139.svg" title="U+2139-Twemoji"> code, improving the usability of the website in the process by providing title and alt. The relative URLs used are root-relative, so from a file-system point of view they are absolute.

Still I see that on the internet, is only considered absolute a URI that starts with a protocol and an IP number or DNS address. One often-cited reason to make internal links absolute is unambiguity, but WordPress already addresses this issue through the canonical link meta tag.

If it were just about me, I wouldn’t mind, but it’s about setting up a unfailable method. I’m now facing the awkward choice between either directing to run a tool and edit the homepage menu item to begin with, or to add a given .htaccess into apache2/htdocs. Or the user will need to get accustomed to dealing with a broken website, except if he or she intends to move it online in a /wordpress/ subdirectory, which most people won’t be going to do.

I think there is now a bucket of methods to choose from depending on context. Hopefully everybody finds their best fit and will be able to minimize administration time so as to focus on content and on the vital issues we’re facing right now.

Best regards.

Sorry for duplicate posting in the meantime.

And sorry for asking this question here, after all.

There is still the same hassle: I should figure out a lean method to set up a WordPress site offline prior to migrating it online following Shubhang’s instructions on How to Install WordPress Locally on your PC (and practice making your website).

Yet since the Bitnami WordPress stack is shipped with WordPress configured to be at LOCALHOST/wordpress/, and the live website will typically be at root, Bitnami provides an easy way to reconfigure WordPress to be at root.

But the reason why that is important is only URL writing. With absolute URLs as you recommend, the All-in-One WP Migration plugin can easily be set to upgrade all manually inserted internal URLs while importing the site content in the hosted instance: LOCALHOST/wordpress becomes DOMAIN.TLD.

Using absolute URLs for internal links is advocated also by Ruth Burr Reedy in Should I Use Relative or Absolute URLs?.

But in practice, not using relative URLs for internal links seems like a huge waste of time and a counter-productive complication for site authors. Instead of focusing on content and getting the job done in order to be able to spend more time on things that really matter such as addressing the climate crisis, we would need to type each time https://localhost:8080/wordpress or https://subdomain.domain.tld before the actual page.

And then, each time a static site is migrated back to local for maintenance, and migrated online again, string replacement back and forth.

When you advise: “What a resource is relative to can change.” What changes do you have in mind? It seems like there are two sorts of relative URIs, one of which is absolute with respect to the site root. That is the only relative URL I’m advocating for use in WordPress posts and pages.

Now let’s consider another scenario. While WordPress was at /wordpress/, I manually added a directory https://localhost:8080/svg/ to display some wrapper pages showing SVG images. On the WordPress side, I got relative URLs to work by redirecting root to /wordpress in .htaccess when needed, as suggested in https://community.bitnami.com/t/local-wordpress-set-relative-uris-through-configuration/85649/1

Then I needed to test the bnconfig tool as reported in https://community.bitnami.com/t/local-wordpress-set-relative-uris-through-configuration/85649/5 and suddenly, WordPress started sticking with root, even when it was “reconfigured” back to a directory. From the moment on when bnconfig was run, WordPress started responding both at root and at the custom directory. Requests at LOCALHOST/ are redirected to LOCALHOST/yourdir/ for the homepage. And a request for LOCALHOST/svg/ is answered by WordPress sending its 404.

The easy fix for the images was to copy /svg/ to another, untweaked Bitnami application stack.

Turns out bnconfig edits more than httpd-prefix.conf, httpd-app.conf and wp-config.php, since a script meant to implement Move WordPress To A Different URL Path On The Same Domain With Apache from Bitnami Documentation, and to support reconfiguring to root as well, is unable to perform a move to root when run on a fresh install.

Hi @pizienolamitica,

Thank you for translating to Italian.

You may wish to add these rules to Custom CSS or a child theme’s style sheet:

#toc_container li a span {
	color:green;
}
#toc_container li a {
	color:orange;
}