0.9.6 upgrade problems encountered

Yeah that issue was resolved before 0.9.6 final was released. Sounds like it may be more of a server configuration problem.

What can I look for with the server config that would help isolate or resolve this issue with AjaxSearch? The specs are below in my signature line for the server this is running on, and it is on Network Solutions.

There is a place in the AjaxSearch snippet where you can set the path for the include files it uses:

If you just hard-code the path in there AjaxSearch should work.

Your server may just be misconfigured and not returning the right values for the automatic path script to work with, but if you hard-code them you should be able to work around this.

I already tried that one, and the same results happened...that is what is so strange, as I thought it would have picked up on it readily and resolved the issues.

The part that makes me think it is something deeper is this:

main(/data/12/1/136/35/1136687/user/1207121/htdocs///assets/snippetsassets/snippets/AjaxSearch/AjaxSearch.php) [function.main]: failed to open stream: No such file or directory in /data/12/1/136/35/1136687/user/1207121/htdocs/index-ajax.php on line 29

Warning: main() [function.include]: Failed opening ’/data/12/1/136/35/1136687/user/1207121/htdocs///assets/snippetsassets/snippets/AjaxSearch/AjaxSearch.php’ for inclusion (include_path=’.:/usr/services/vux/lib/php’) in /data/12/1/136/35/1136687/user/1207121/htdocs/index-ajax.php on line 29

The bold parts of the error message are what have me puzzled as to why it isn’t recognizing the base url of the site and why it is plugging in the assets/snippets/ portion twice... really strange and I can’t pinpoint where it is getting triggered from...

The base path constant is still not getting set right, so take another look at your hard-coding in config.inc.php. In the main AjaxSearch snippt file you’ll see that there are some includes that reference this constant. I would comment out the autodetect routine in config.inc.php entirely, since it might be changing the values that you hard-coded above it.

The lines in AjaxSearch are like so:


So in this case it’s the constant MODX_BASE_PATH that’s not right (and that will likely cause you problems elsewhere as well).

So, to try to fix the Ajaxsearch part, should I hard code the portion in that snippet to avoid potential issues with other snippets or comment out the portion in the config.inc file? I don’t want to have to rewrite a bunch of scripts for other snippets that I might use if all are based on the "base_url" or other portions of the config.inc file...

I would think that if the MODX_BASE_PATH constant isn’t being set properly that it’s a significant issue that you should fix at the source rather than just patch the path in the AjaxSearch snippet, so I would make sure that it’s set correctly in config.inc.php myself.

I commented (removed completely) the portion in the config.inc file that sets the base path, base url and site url and it is still throwing the same error with the Ajax Search snippet. In the gallery section however, on the first page of the gallery, it shows up fine, but if you click to go to a specific gallery, the url produced is: www.unionky911.orghttp//www.unionky911.org/gallery/article-1169662511.html

This is so weird that I am not sure what else to try or where else the problem might be...

What is your base href set as? It appears to be set using some kind of relative URL...

Nevermind -- this is odd indeed, but that specific URL problem appears to be Ditto related; perhaps something in the Ditto templates? Or some other option on Ditto...

Here is my current info for all things great and small:

MODx 0.9.6 rev:2767
Server API = CGI/FastCGI
PHP ver. 4.4.7
mySQL Client API version = 4.1.21

from my config.inc.php file, these values are hard coded in:

$base_url=’http://www.unionky911.org/’;
$base_path=’/data/12/1/136/35/1136687/user/1207121/htdocs/’;
$site_url=’http://www.unionky911.org/’;

and this portion of code is completely removed from the config.inc.php file:

// automatically assign base_path and base_url
if(empty($base_path)||empty($base_url)||$_REQUEST[’base_path’]||$_REQUEST[’base_url’]) {
$sapi= ’undefined’;
if (!strstr($_SERVER[’PHP_SELF’], $_SERVER[’SCRIPT_NAME’]) && ($sapi= @ php_sapi_name()) == ’cgi’) {
$script_name= $_SERVER[’PHP_SELF’];
} else {
$script_name= $_SERVER[’SCRIPT_NAME’];
}
$a= explode("/manager", str_replace("\\", "/", dirname($script_name)));
if (count($a) > 1)
array_pop($a);
$url= implode("manager", $a);
reset($a);
$a= explode("manager", str_replace("\\", "/", dirname(__FILE__)));
if (count($a) > 1)
array_pop($a);
$pth= implode("manager", $a);
unset ($a);
$base_url= $url . (substr($url, -1) != "/" ? "/" : "");
$base_path= $pth . (substr($pth, -1) != "/" && substr($pth, -1) != "\\" ? "/" : "");
// 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;
}

My .htaccess file is:


RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA,NC]

#BrowserMatch "MSIE" brokenvary=1
#BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
#BrowserMatch "Opera" !brokenvary
#SetEnvIf brokenvary 1 force-no-vary

#php_flag register_globals Off