We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 6726
    • 7,075 Posts
    I noticed there were some important changes config.inc.php from 0.9.5 to 0.9.6

    One of those changes is from

    if($base_path==""||$base_url=="") {
    $a = explode("/manager",str_replace("\\","/",dirname($_SERVER["PHP_SELF"])));
    


    to

    	
    if(empty($base_path)||empty($base_url)||$_REQUEST['base_path']||$_REQUEST['base_url']) {
    $a = explode("/manager",str_replace("\\","/",dirname($_SERVER['SCRIPT_NAME'])));


    I am trying to get a grasp of what this means, especially since I have experienced strange problems with the filemanager since upgrading two live sites from 0.9.5 to 0.9.6 RC2... Maybe there is no connection but since I am investigating those issues I thought I’d ask about those.

    Also some constant have been added, my understanding is, to solve some issue with base_url and such :

         
            if (!defined('MODX_BASE_PATH')) define('MODX_BASE_PATH', $base_path);
            if (!defined('MODX_BASE_URL')) define('MODX_BASE_URL', $base_url);
            if (!defined('MODX_SITE_URL')) define('MODX_SITE_URL', $site_url);
            if (!defined('MODX_MANAGER_PATH')) define('MODX_MANAGER_PATH', $base_path.'manager/');
            if (!defined('MODX_MANAGER_URL')) define('MODX_MANAGER_URL', $site_url.'manager/');
    
      .: COO - Commerce Guys - Community Driven Innovation :.


      MODx est l'outil id
      • 22303 MODX Staff
      • 10,725 Posts
      David, I’m a little confused about the first part of your post, because the code is different from the current RC2 config.inc.php, which has a completely new algorithm for automatic path calculations. Should look like this now, though we are still refining it to handle more situations. This new approach reportedly isn’t working with Apache ~user URLs in several cases, whereas the old method did. However, this new method should work in cases where the old one was failing previously.

      <?php
      	// automatically assign base_path and base_url
      	if(empty($base_path)||empty($base_url)||$_REQUEST['base_path']||$_REQUEST['base_url']) {
          
              // assign base_path
              $base_path = realpath(dirname(__FILE__).DIRECTORY_SEPARATOR.'..'.DIRECTORY_SEPARATOR.'..').DIRECTORY_SEPARATOR;
              $base_path = str_replace('\\','/',$base_path);
              if($base_path{strlen($base_path)-1}!='/') $base_path.= '/';
      
                      // strip appended paths
              $base_url = !empty($_SERVER['PHP_SELF']) ? $_SERVER['PHP_SELF'] : $_SERVER['REQUEST_URI'];
              $base_url = str_replace('\\','/',$base_url);
              $truncate = strpos($base_url, !empty($_SERVER['SCRIPT_FILENAME']) ? basename($_SERVER['SCRIPT_FILENAME']) : '.php');
              if($truncate!==false) $base_url = substr($base_url, 0, $truncate);
                  
              // walk trough url until we reach our base directory
              $base_url_tokens = explode('/', $base_url);
              while(count($base_url_tokens)>0) { 
                $base_url = implode('/', $base_url_tokens);
                if(preg_match('/'.preg_quote($base_url, '/').'[\/|]$/', $base_path)) break;
                array_pop($base_url_tokens);
              }
              
              if($base_url{strlen($base_url)-1}!='/') $base_url.= '/';
              
              // assign site_url
      		$site_url = ((isset($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS'])=='on') || $_SERVER['SERVER_PORT']==$https_port)? 'https://' : 'http://';
      		$site_url .= $_SERVER['HTTP_HOST'];
      		if($_SERVER['SERVER_PORT']!=80) $site_url = str_replace(':'.$_SERVER['SERVER_PORT'],'',$site_url); // remove port from HTTP_HOST 
      		$site_url .= ($_SERVER['SERVER_PORT']==80 || (isset($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS'])=='on') || $_SERVER['SERVER_PORT']==$https_port)? '':':'.$_SERVER['SERVER_PORT'];
      		$site_url .= $base_url;
      	}
      

        • 6726
        • 7,075 Posts
        Interresting... I have noticed that my config.inc.php didn’t get upgraded properly when I upgraded from 0.9.5 to RC2, thus I checked with the clean RC2 install I had handy, and copy-pasted the code from the internal RC2 into my config.inc.php file, but as it happens it was the RC2 internal testing build, not the latest RC2.

        This might explain my issues !
        I’ll make sure things are corrected and report thanks Jason for the quick reply grin
          .: COO - Commerce Guys - Community Driven Innovation :.


          MODx est l&#39;outil id
          • 6726
          • 7,075 Posts
          Hmmm, I downloaded RC2 again from the download page, did a fresh install and the config.inc.php had the right code.
          I am beginning to wonder if I didn’t screw up when installing those RC2 with the wrong files (from internal RC2...).

          I’ll re-upgrade and report, I probably was the cause of trouble all along rolleyes
          Sorry !
            .: COO - Commerce Guys - Community Driven Innovation :.


            MODx est l&#39;outil id
            • 6726
            • 7,075 Posts
            I upgraded and sure there is a problem with the new config file and my sever running Apache 1.3.37... nothing works anymore undecided
            Path are all wrecked. Server root is confused with the site root, CSS as MODx document do not work...

            I didn’t get it when you talked about ~user urls... I use those on my dedicated box on pre-prod websites such as the ones being upgraded... now I guess I have to revert to old file...
              .: COO - Commerce Guys - Community Driven Innovation :.


              MODx est l&#39;outil id
              • 22303 MODX Staff
              • 10,725 Posts
              @David, can you share your $_SERVER vars from phpinfo? And if possible, a sample VirtualHost config from Apache, if applicable?
                • 6726
                • 7,075 Posts
                Of course I can share those smiley

                SERVER VARS : see zipped html export of phpinfo() from my server, with server vars of one of the website I experienced problem with the new config file.
                VirtualHost config : we’re talking about httpd.conf file are we ? Here it is, renamed it and saved as a txt file.

                FYI in the meantime I reverted to the old 0.9.5 config file and it works OK.

                While I am here, I experience some ugly encoding issues with a Latin1 encoded website.

                After upgrade, all accented character were badly encoded. Switched manager language to utf-8 and then content displayed OK but language strings for manager had accents replaced by question marks. I tried several things, but what finally worked was removing $database_connection_charset = ’utf8’; from the config file... I did not experiment such issue with another website (same process) which content had been encoded as utf-8 from the start. If DB encoding is different from modx_charset things do not go smooth tongue



                  .: COO - Commerce Guys - Community Driven Innovation :.


                  MODx est l&#39;outil id
                  • 22303 MODX Staff
                  • 10,725 Posts
                  Quote from: davidm at Apr 18, 2007, 10:35 PM

                  Of course I can share those smiley

                  SERVER VARS : see zipped html export of phpinfo() from my server, with server vars of one of the website I experienced problem with the new config file.
                  VirtualHost config : we’re talking about httpd.conf file are we ? Here it is, renamed it and saved as a txt file.

                  FYI in the meantime I reverted to the old 0.9.5 config file and it works OK.
                  I’ll take a look and see what I can do to resolve this...

                  Quote from: davidm at Apr 18, 2007, 10:35 PM

                  While I am here, I experience some ugly encoding issues with a Latin1 encoded website.

                  After upgrade, all accented character were badly encoded. Switched manager language to utf-8 and then content displayed OK but language strings for manager had accents replaced by question marks. I tried several things, but what finally worked was removing $database_connection_charset = ’utf8’; from the config file... I did not experiment such issue with another website (same process) which content had been encoded as utf-8 from the start. If DB encoding is different from modx_charset things do not go smooth tongue
                  I take it your db is using a latin1 encoding then? Did you set the encoding to latin1 when running an advanced upgrade? Or did you just run the standard? If so, try running the advanced (have your db credentials handy), and change the connection charset to latin1 (and the appropriate collation, e.g. latin1_swedish_ci) instead of utf8... (or just edit the connection_charset variable in your new config.inc.php to be latin1, which may be easier for you)

                  I’m working on this part of the upgrade to improve the auto-detection of this...
                    • 6726
                    • 7,075 Posts
                    Quote from: OpenGeek at Apr 18, 2007, 10:57 PM
                    I’ll take a look and see what I can do to resolve this...

                    Thanks Jason smiley

                    Quote from: OpenGeek
                    I take it your db is using a latin1 encoding then?

                    Actually the modx_charset is Latin1, but phpMyAdmin home page gives me the following encoding settings :

                    MySQL charset: UTF-8 Unicode (utf8)
                    MySQL connection collation : utf-8_unicode_ci

                    but if I look at all DB structures I have (not only MODx installs but all systems) I have a latin1_swedish_ci value for collation...
                    what does it mean ?

                    I am kind of lost with the MySQL encoding issues I admit...

                    Quote from: OpenGeek
                    Did you set the encoding to latin1 when running an advanced upgrade? Or did you just run the standard?
                    If so, try running the advanced (have your db credentials handy), and change the connection charset to latin1 (and the appropriate collation, e.g. latin1_swedish_ci) instead of utf8... (or just edit the connection_charset variable in your new config.inc.php to be latin1, which may be easier for you) I’m working on this part of the upgrade to improve the auto-detection of this...

                    No I did not, since phpMyAdmin displayed utf-8 as the default encoding... I did both standard and advanced upgrades (in this case, chose utf-8)
                    But all my DBs display latin1_swedish_ci value for collation huh

                    Maybe I should try to do what you say, but for the record my other MODx installs (with a utf-8 modx_charset) were fine with the utf-8 setting for database connection...

                    I don’t really fully understand what are the interactions between site encoding and DB encoding.
                    I know some Latin1 to utf-8 encoding utilities exist, but it’s a risky process...

                    I hope it’s clear... if you need, I’ll hand you an admin access to MySQL on my box. Anything to help !

                    Thanks smiley
                      .: COO - Commerce Guys - Community Driven Innovation :.


                      MODx est l&#39;outil id
                      • 25663 MODX Staff
                      • 12,272 Posts
                      David re-run the advanced installer and match the characterset/collation values of the actual data store. It will be just fine.
                        Ryan Thrash, MODX Co-Founder
                        Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me