Mysterious Link Between Staging and Production - Field Label Changes Synchronize!

šŸ‘Øā€šŸ’» Development Help
2

Maybe itā€™s just a DNS issue, and youā€™re hitting the same IP address from both namesā€¦

3

I am aware that both domains point to the same IP address, but they are set up in separate spaces on the server. Each domain has its own directory and separate database, and Iā€™ve ensured that the config.php files in each environment reflect these separations correctly.

4

Iā€™m sorry, maybe Iā€™m just being dumb, but i that case I donā€™t understand how the web server directs each request to its own space?

Do you use a subfolder on the URL?

5

Apache would detect the hostname in the requested URL and go to the matching directory, itā€™s called an Apache ā€œVirtual Hostā€.

6

Thanks Chris. I never did virtual hosts based on domain name, only based on subfolders or port numbers. But I guess it makes sense.

So the issue here would be to double-check that configuration, right? A web server issue, not a SuiteCRM issueā€¦

7

Thanks, yes, Apache domain based VirtualHost-ing is how companies host many websites and other web services on one public IP address shared by all.

  1. If you truly have separate hosting accounts, separate databases, then itā€™s possible the previous domain name production.domain.tld hostname was copied in cached files from the production serverā€™s Suite cache to the staging serverā€™s Suite cache. To clear the cache on staging serverā€™s Suite 7, go to Admin / Admin Tools / Repair / Quick Repair and Rebuild. Please post back with your results.

  2. Double check your production and staging are not accidentally the same. If you can, share the Directory name, from the Apache VirtualHost configuration for each virtual server, here, they should be different directories. If you can, upload a small text file file to the Suite base directory of staging, it should not appear in the Suite base directory of production. Post back your results here.

8

I reconsidered this. Please open the .htaccess files which you copied over from the previous server. Copy paste them in your reply here to be sure. Do they contain the productions.mydomain.tld hostnames? You must change them to staging.mydomain.tld !

9

We are on a nginex server with directadmin. Each domain is configured to point to its own separate directory on the server.

10

Thank you for your response.

Regarding point one, I have performed the ā€œQuick Repair and Rebuildā€ several times on both environments (production and staging). For added assurance, I also cleared the cache manually by deleting the contents of the cache folders via FTP on both environments, followed by running the ā€œQuick Repair and Rebuildā€ again (both production and staging).

Regarding the server setup: it is a single multi-user/customerserver. Production and staging have two different accounts created via DirectAdmin, as if they were two separate customer of the same hosting provider. Each installation has its own base directory in public_html. If I upload a file to one siteā€™s directory, it does not appear in the otherā€™s directory. As proof of this, the two config.php files are different.

Any further insights or suggestions would be greatly appreciated.

Best regards,

11

I have already checked this as well: there are no references to the domain or local paths in the .htaccess files. Since they are in separate environments, both installations point to their respective roots, not to any subdirectories.

Itā€™s crazy, but Iā€™m even considering something that the browser might be caching locally on my computer. To rule this out, I have conducted tests using two different browsers in guest mode (without previous cache).

12

Try running the backup copy on your localhost (laptop or desktop) by restoring it on your local machine. Does it exhibit the same mysterious link to production?

13

I donā€™t know if this will work or not.

Got to admin ā†’ System Settings ā†’ Developer Mode:

Check if it is checked or not.

14

I checked and it is not checked.

15

Itā€™s the last test I have left to do. Iā€™ll let you know how it goes.

16

Could you share links & screenshots to show us?

17

Iā€™m sorry, but I cannot share a link because the CRM contains private customer data. I can show you screenshots. What specifically would be helpful for you to see?

18

Maybe this is related:

19

Hi Welcome to the forums,

The problem you are facing is rather strange, I canā€™t think of how the two could or are interplaying.
what web server are you using for fcgi? Iā€™m guessing from reading the thread youā€™re using Apache.

One suggestion I can think of is to change the theme colour on one of the instances
(Iā€™m not sure if 7.10 has the SuiteP theme, however a quick change to CSS regardless will also do),
You can then rule out any problems with DNS or vhost routing by expecting a certain UI colour.

The nature of your issue would suggest a problem with something in front of SuiteCRM in your setup rather than SuiteCRM itself, I would double check your vhost setup.

20

Thank you for your responses. It is indeed absurd. I am thinking of server-side issues. I already set different colors via CSS for staging a while ago to avoid confusion during testing. The configurations are definitely different; I have checked the config files and separate databases multiple times. If I create new fields, for example, I donā€™t find them duplicated on the other installation. The problem seems to be only with the labels of the fields that exist on both installations. My concern is that there may be other changes or settings that propagate between the two installations that I havenā€™t noticed yet.

As for the server, it is an Apache with Nginx in proxy, managed with DirectAdmin.

Here is an excerpt of the important parts from the end of the test site:
ā€˜site_urlā€™ => ā€˜https://test.domain.cloudā€™,
ā€˜host_nameā€™ => ā€˜test.domain.cloudā€™,
ā€˜db_host_nameā€™ => ā€˜localhostā€™,
ā€˜db_host_instanceā€™ => ā€˜ā€™,
ā€˜db_user_nameā€™ => ā€˜test_',
ā€˜db_passwordā€™ => 'H6*******************ā€™,
ā€˜db_nameā€™ => ā€˜test*****ā€™,

And here are the corresponding parts from the production site:
ā€˜site_urlā€™ => ā€˜https://prod.domain.cloudā€™,
ā€˜host_nameā€™ => ā€˜prod.domain.cloudā€™,
ā€˜db_host_nameā€™ => ā€˜localhostā€™,
ā€˜db_host_instanceā€™ => ā€˜ā€™,
ā€˜db_user_nameā€™ => ā€˜prod_',
ā€˜db_passwordā€™ => 'k8*******************ā€™,
ā€˜db_nameā€™ => ā€˜prod*****ā€™,

Here is the screenshot of the two installations:

suitecrm
suitecrm1849Ɨ1080 126 KB

21

Iā€™ve checked some documentation for DirectAdmin which maybe able to help

Apologies if you already know the following information.
although it is ideal to configure everything within the user interface of your control panel.
I would check the contents inside the following directory on your server:

/usr/local/directadmin/data/users/[USERNAME]

In here you will find all the configuration files for your user and there will be individual configuration files for your separate domains within the ā€˜domainsā€™ folder within this directory.

I would double check the server name and the root in the server blocks for NGINXā€™s config which should look like

server {
  listen 80;
  listen [::]:80

  server_name [example.com](http://example.com/) [www.example.com](http://www.example.com/);
  root /var/www/[example.com](http://example.com/);
}

and make sure they match the domain names and the locations the SuiteCRM PHP files are stored.
There will be similar configuration for Apache, server_name is ServerAlias and root is DocumentRoot in Apache
All the information regarding configuration file locations for directadmin can be found from this page: