4 Replies Latest reply on Mar 17, 2009 10:18 AM by Albert S.

    Testing server works, Site doesn't

    Level 1
      I've looked all over the web and Dreamweaver help to try and solve this one.

      I set up my MAMP server, setup the site, built the php pages for form entry, connected successfully to the database, entered new records, edited records, and all that using the testing server.

      I then went to the PHP admin page for my DNS provider and added the same database that I was using on the testing server, verified that everything was there, and uploaded the site.

      Nothing works. If I go to the form page I get nothing but a blank page. There isn't even any source code. I can see that the page is there in my ftp client or in the Dreamweaver remote view but nothing shows up on any browser that I try.

      I'm assuming that I'm not connecting to the database. I've come to the conclusion that I should edit the connections page and have entered the user name and password required to administer my databases on the DNS server. Interestingly enough, this seems to make no difference to the testing server. I've also edited the path to what I believe is the proper one for my DNS provider, but I still am having no success.

      This shouldn't be that hard, and there should be at least some kind of a tutorial somewhere on how to move your Dreamweaver PHP site to your actual server.

      Thanks for your help.

      Rick
        • 1. Re: Testing server works, Site doesn't
          HauteJordo
          Not to sound dense, but did you copy the includes folder to the remote server?
          • 2. Re: Testing server works, Site doesn't
            Albert S. Level 3
            Hi Rick,

            Please refer to the DNS server as a remote server since a DNS server is a different server, or you can refer to them as a LIVE server and TEST server. I would agree with Mark on this one, did you upload the includes folder? When you upload to a LIVE server the LIVE server typically does not show errors which is why your getting a blank page.

            Also make sure that common classes, tNG classes and dispatcher are being found by the page.

            // Load the common classes
            require_once('includes/common/KT_common.php');

            // Load the tNG classes
            require_once('includes/tng/tNG.inc.php');

            // Make a transaction dispatcher instance
            $tNGs = new tNG_dispatcher("");
            • 3. Re: Testing server works, Site doesn't
              Level 1
              I finally figured this one out. Turns that My DNS provider has a goofy non standard link to the databases and only one password for all the database files. They also don't allow any upper case letters in the database name. Once I figured that out (which was not evident from the PHP admin panel on the live server) and redid the database wo uppercase letters everything was fine. It only took an hour on the phone with tech support to discover these quirks.

              Now everything is working. I appreciate the suggestions re: live server / testing server.

              This brings up a security question though. The UN and PW for the database is now stored in a simple PHP file in the connections directory. Seems like anyone with a little hacking skills could find them and foul up the entire database.

              Thanks again for your help.
              • 4. Re: Testing server works, Site doesn't
                Albert S. Level 3
                Hi Rick,

                One thing you can do is most webservers have the public area where your pages are and a private area where your mail is stored. The file structure may look something like this:

                /account/

                /account/mail/ <-- mail

                /account/www/ <-- public

                You could add the connections folder to this area.

                /account/

                /account/connections/ <-- db connection not public.

                /account/mail/ <-- mail

                /account/www/ <-- public

                Keeping the connections page behind the public side.

                You can also secure the connections folder with an .htaccess file.

                /account/www/connections/ <-- connections with .htaccess file blocking public access.

                The .htaccess file would contain something like: Example only.

                AuthType Basic
                AuthName "Connections"
                AuthUserFile "/home/accountname/.htpasswds/www/passwd"
                require valid-user

                Then you can add some xtra things to block bad browsers that might allow for that information to be accessed.

                AuthType Basic
                AuthName "Connections"
                AuthUserFile "/home/accountname/.htpasswds/www/passwd"
                require valid-user

                IndexIgnore *

                # Define BAD Browsers that don't get access
                #
                BrowserMatch ^Wget b_a_d1
                BrowserMatch ^EmailSiphon b_a_d2
                BrowserMatch ^WebStripper b_a_d3
                BrowserMatch ^Rumours-Agent b_a_d4
                BrowserMatch ^Teleport b_a_d5

                # Die bad browser, DIE!
                #
                deny from env=b_a_d1
                deny from env=b_a_d2
                deny from env=b_a_d3
                deny from env=b_a_d4
                deny from env=b_a_d5