Jump to content

Archived

This topic is now archived and is closed to further replies.

Placebo-

_GET issue, ? vs /

Recommended Posts

On my website I used to access the Oscommerce products in this way:

WEBSITTE.COM/catalog/product_info.php/products_id/269

 

Now that the PHP is upgraded I see that catalog/product_info.php/products_id/269 is no longer working. I have some PHP knowledges and I know that the correct URL should be: catalog/product_info?products_id=269

 

How can I make the PHP able to read the links in the format I had before?

Share this post


Link to post
Share on other sites

Before you had SE friendly URLs turned on. The parameter is still treated as a GET by PHP, so I don't see why you are having problems. You could try turning this option back on in your Admin. Or turn it off if you prefer the ? syntax

SE Friendly URLs is buggy, anyway and should really be off.

Share this post


Link to post
Share on other sites

It's not treated as a GET parameter...it's treated as a path. The code in application_top.php converts it into the cooresponding GET variables.

 

I would recommend doing some debugging. echo the PATH_INFO variable [getenv('PATH_INFO')] to see what the issue is. You don't want to just turn the option off as all your pages indexed by search engines will lose seniority and you'll have to start all over. It could be 3-6 months before your store recovers in the search engine placement results from that mistake...

 

Bobby

Share this post


Link to post
Share on other sites
It's not treated as a GET parameter...it's treated as a path.  The code in application_top.php converts it into the cooresponding GET variables.

 

I would recommend doing some debugging.  echo the PATH_INFO variable [getenv('PATH_INFO')] to see what the issue is.  You don't want to just turn the option off as all your pages indexed by search engines will lose seniority and you'll have to start all over.  It could be 3-6 months before your store recovers in the search engine placement results from that mistake...

 

Bobby

 

Thank you for your kind reply!

 

Chemo, my PATH_INFO is not being displayed at all. I am using PHP 4.3.8.

 

I use the code:

echo "PATHINFO".getenv("PATH_INFO");

echo getenv ("REMOTE_ADDR");

 

and I get the REMOTE_ADDR, but I don't get PATH_INFO

 

Any ideas?

Share this post


Link to post
Share on other sites

I found this comment at PHP.NET

rob at webdimension dot co dot uk

04-Oct-2004 05:56

Apache Upgrade from 1.3 to 2.0

The handling of PATH_INFO (trailing path information after the true filename) has changed for some modules. Modules that were previously implemented as a handler but are now implemented as a filter may no longer accept requests with PATH_INFO

 

Use:

$path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};

 

Even with the above code I don't get the PATH_INFO :(

Share this post


Link to post
Share on other sites

I've seen this type of error on PHP installs that are running in CGI mode (versus SAPI). You may need to use $_SERVER['REQUEST_URI'] and then remove the file basename. Then you can use a function like this:

  function parse_path($path_info){ // used only for old SEF URLs
	 $tmp = explode('/', $path_info); // explode the path  
	 if ( sizeof($tmp) > 2 ){ // there is more than 1 parameter to parse
   // initialize the container array
   $container = array();    
   // loop through the array
   for ($i=0, $n=sizeof($tmp); $i<$n; $i++) {
  	 $container[] = $tmp[$i] . '=' . $tmp[$i+1]; 
  	 $i++; // net result of this is to increase $i by 2 every loop...keep things even
   }
   // implode the pieces into a final parameter string to be used in the tep_href_link()
   return implode('&', $container); 	 
	 } else { // there is only 1 parameter to parse
   return implode('=', $tmp);
	 }    
 } # end function parse_path

The trick is to find out what will echo the correct URI then extract just the parameter portion of the string...then send it through the function.

 

Bobby

Share this post


Link to post
Share on other sites

It's not treated as a GET parameter...it's treated as a path

 

When I said:

The parameter is still treated as a GET by PHP

I implied (and I thought this was pretty obvious):

The parameter is still treated as a GET by the PHP code in OSC.

 

Better?

Share this post


Link to post
Share on other sites
When I said:

The parameter is still treated as a GET by PHP

I implied (and I thought this was pretty obvious):

The parameter is still treated as a GET by the PHP code in OSC.

 

Better?

It was not obvious or I would not have corrected your statement.

 

Further, the advise you give the member is borderline reckless since they would lose all page seniority and have to start from scratch with SERPs...a nice way to wreck an online business for a few months.

 

Argueing over code semantics is a petty issue...however, it is very relevant in this case since the methods used to debug will depend on how the SERVER is interpreting the path. Forget the PHP code in application_top...if the SERVER is not interpreting it as a path then the code is broken. So, to fix the issue the member must first determine how the obtain the virtual path from the URI (most likely $_SERVER['REQUEST_URI']) and use that as the parameter to parse into GET variables.

 

Bobby

Share this post


Link to post
Share on other sites

Gentelman,

Thank you for ur help. I have tried to generate from 'REQUEST_URI' a $PATH_INFO but it seems the code is not recognizing product_info/var/value/var/value as an URL. If I echo-ed the $_GET[$var] in that function they appear, but the browser still gets a Page Cannot be found.

 

At this situation I decided to disable SE Friendly URL. I am going for the old version, and maybe in one of these days I will install a newer version of the program and will follow the advices of Chemo for a better Ranking in the Search Engines.

 

Thank you for ur time again!

Share this post


Link to post
Share on other sites

×