We are transitioning over to a new forum platform. Please post new issues there. Existing threads will be dealt with here unless you choose to move them over. Visit the new forum

Forum

Thread tagged as: Problem, Error, Installation

Temporary testing site calling different root path

I realize this isn't strictly a Perch issue but I'm curious how other dev/designers work with this problem. We are unable to see the site that we are staging on remote server because the $_SERVER['DOCUMENT_ROOT'] call is wrong. We received this reply from our hosting server. We are staging a site rebuild in a temporary location as the url is active:

The reason this isn't working is that your use of $_SERVER['DOCUMENT_ROOT'] is pulling the server's actual document_root which is /var/www/html/ since you are using the temp url to view the site and not the domain. If for instance view it via the hosts file or at https://hosts.cx/ Just input the domain and server ip 69.90.163.90 then generate a url to test at.

> To use the temp url you'd need to define it first and use it instead of Document_root. Changing the first lines of:

 <?php include($_SERVER['DOCUMENT_ROOT'] . '/perch/runtime.php'); ?> 

======

> to

 <?php include('/home/first746/public_html/perch/runtime.php'); ?> 

====== I ran the hosts.cx request and the url is below. But it still rejects calls to db

[http://gi6jz.hosts.cx/]

Any suggestions/help with this would be very welcome. I'm really hoping I don't have to hard-code a new directory path onto current site but maybe that is my only solution. I'm not a php developer. A designer only.

ruth tait

ruth tait 0 points

  • 11 months ago

Hi Ruth

I guess this preview site is routing you through another server, and because you are using the generic IP address of localhost for the DB server, it's not finding the database server on that IP address. Try using the direct IP address they've given you for the DB instead.

As a side note on hosting and subdomains, if you create a subdomain such as staging.domain etc, it really needs to live on its own, rather than a subfolder of the main site's domain. Perch won't work properly in a subfolder, which is looks like what this host is doing with subdomains. My main host is exactly the same.

With my host I would set up a brand new website instance and use the subdomain name as the main domain name. Then the hosting package will have its own root and you'll be good to go.

Hope this helps,

Jon

With help from host, we 'solved' the root issue and database connection issue. But there is no doubt the site is not behaving as per expectation. In response to your comment:

As a side note on hosting and subdomains, if you create a subdomain such as staging.domain etc, it really needs to live on its own, rather than a subfolder of the main site's domain. Perch won't work properly in a subfolder, which is looks like what this host is doing with subdomains. My main host is exactly the same.

We are staging on a brand new hosting server using a temporary domain as the domain url is currently operational. The staging site is at the public.html root. So, that should place Perch at root. But links to internal pages are doing strange things: tripling up nav links and breadcrumb links which are all phantom links, i.e. don't work. At some level we/Perch have lost a fundamental connection to the site navigation.

Can’t you turn off the site preview and use htaccess and htpasswd to make the site temporarily private instead?

https://wiki.apache.org/httpd/PasswordBasicAuth

Most hosts have a gui to do this in their control panels.

1 points

You could try adding the path prefix to every page in the perch3_pages table with a SQL command like this:

UPDATE `perch3_pages` SET pagePath = CONCAT("/prefix", pagePath);

To undo that you would run:

UPDATE `perch3_pages` SET pagePath = TRIM(LEADING "/prefix" FROM pagePath);

No guarantees that it'll work – just an idea (back up your database if you're feeling queasy)! It would probably be a good idea to look at your database to see what it actually says in the pagePath column before you run anything.

For me it looks like this (using a graphical MySQL client):

screenshot

Update: I did some testing and it seems you may also need to update the regionPage column of the perch3_content_regions table. The commands for that would be the same as above, with the table and column names correctly substituted.


By the way, this is (as far as I can tell) the same as changing the path in the 'Location' tab for each page through the control panel, just faster if you have a lot of pages.