Okay. So I see all those pages loading and I am not seeing any 404s. The bigger issue is why is there an extra directory in URL, or specifically, why can the install be found at both the base URL and the URL with an extra directory. Is that right?
If so, I am guessing this has to do with the host’s web service configuration.
Background Info of the Usual Problem and How We Get There
In webhosting, we have our web service (usually Apache, but also possibly Nginx or LiteSpeed.) There is the virtualhost’s (Apache), or server block’s (Nginx), domain (ServerName in Apache, server_name in Nginx) and its document root (DocumentRoot in Apache, and root in Nginx). These can also be accompanied by various aliases.
Our web service receives a request through the Domain Name Service (DNS) which sends a request to our server for a specific URL’s resource. That URL, through DNS, is configured to a specific IP Address and Domain Name. When the server receives the request at the specific IP Address, it checks to make sure that it has a configuration for the requested domain name, otherwise it serves the default resource, or if it is Apache, the first resource it has available which is read and thus served linearly in the Apache configuration.
Once the request has its matching resource, the configuration of the virtualhost/server block is read to find the particular resource, and thus we see our response.
From what I can tell, your issue would normally be due to one of two things.
- The Grav install is installed in a subdirectory of the document’s root directory.
- The server’s root directory is misconfigured and does not match the intended directory.
Other thoughts
Grav doesn’t set a home or siteurl configuration like WordPress does, it is serving its URL based on the requesting URL, so I don’t believe this would have to do with a Grav option somehow pulling in the base document root. (This is evidenced by when you move a development Grav site to its official location and have no need to change its URL within Grav.)
That being said, such oddities would normally not produce an issue where it is available at both directories, one or the other. One thought would be a symlink from the subdirectory to the parent, thus mimicking the contents of the directory. Apache could traverse such a symlink and load the content twice, effectively.
It could be an alias which is including the subdirectory as well a la https://httpd.apache.org/docs/2.4/urlmapping.html#outside
That should normally give us one of two possibilities for a solution.
If our issue is the first proposed above, we simply need to move our install up a directory.
If the issue is the second, we need to edit our virtualhost/server block to have the corresponding document root.
That being said as the likely issue, to make sure I am understanding you and we are clear, neither of these two are the solution we are looking for, correct? The site is being served from both home and the subdirectory by the same installation? (i.e. the install exists within the subdirectory /public_html/compassionateselfcare but not in /public_html/.)
I have an idea of a third option, but I want to make sure that is the case. To help me make a better guess and possibly determine a solution, more information is always handy when working with servers (as they are basically a bunch of configuration options).
Are you utilizing cPanel with subdomains or parked domains being utilized? And if so, is the main domain or account level domain compassionateselfcare.org.uk? When you say it is mapped, how is it mapped?
/public_html/compassionateselfcare exists as a directory on the server, right?
Also, is it possible to get your site’s—seeing as you are on Apache based on the .htaccess file you mentioned—VirtualHost config? You can sanitize it of anything that would be insecure. Are you able to get the “main .htaccess file” where the domain’s are mapped? This is mostly for information gathering.
Your site’s .htaccess is the default for Grav, correct? Or what custom changes, if any, have been made?