Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

walmslei

Pioneers
  • Posts

    17
  • Joined

  • Last visited

Profile Information

  • Real Name
    ian walmsley

walmslei's Achievements

  1. Right, we got to the bottom of this - Thanks to Rob for his help through the day and this evening! It transpires that we had no default language set in osCommerce, English was the only language present in the admin panel but it wasn't followed by (default) on the list of languages. As the contribution (and osCommerce) rely heavily on the language for the URL formation it would appear the lack of a default returns a null string - which leads the tep_href_link function to return a null result also (hence a 404 error). So, the solution in this case was just go to languages in the admin panel, click english, details, set as default and okay it. The USU5 contribution now works exactly as intended without any modifications. As we installed (this copy) of osCommerce via the Plesk Application Manager (in Plesk 11), I'll do a default install tomorrow to see if this is the default setting. -If- it is, I'll repost and update accordingly, as clearly it could have implications for this and other contributions which rely on the osC language framework.
  2. The output file doesn't show any errors directly - I cranked up error reporting in Apache, and took them from the error_log via SSH instead which will hopefully show the same results. PHP Notice: Undefined variable: padding in /pathtofile/httpdocs/includes/modules/boxes/bm_categories.php on line 40 {this repeats about ten times) then Undefined index: @@@lang@@ in /pathtofile/httpdocs/includes/classes/language.php on line 77 then File does not exist: /pathtofile/httpdocs/fancybox Thats all.
  3. Okay, this may be getting somewhere nearer the mark - The first three lines show a request made by browsing the site: product_info.php osCsid=n88c0nv37k820m8o8d19fulak0&products_id=1 http://www.xyz.co.uk/pleatco-pww50-spa-filter-p-1.html The next FIVE lines show a request made from an external server header checker - It appears to be having a second go at it, despite, but isn't dragging anything out on tep_href_link( Usu_Main::i()->getVar( 'filename' ), Usu_Main::i()->getVar( 'request_querystring' ) ) on the second pass (its a null line) product_info.php products_id=1 http://www.xyz.co.uk/pleatco-pww50-spa-filter-p-1.html product_info.php products_id=1
  4. Request Original:/pleatco-pma30-2002-p-32.html Request New: REDIRECT_PP_CUSTOM_PHP_INI - /var/www/vhosts/xyz.co.uk/etc/php.ini REDIRECT_STATUS - 200 PP_CUSTOM_PHP_INI - /var/www/vhosts/xyz.co.uk/etc/php.ini HTTP_HOST - www.xyz.co.uk HTTP_CONNECTION - Close PATH - /sbin:/usr/sbin:/bin:/usr/bin SERVER_SIGNATURE - SERVER_SOFTWARE - Apache SERVER_NAME - www.xyz.co.uk SERVER_ADDR - 192.168.10.25 SERVER_PORT - 80 REMOTE_ADDR - 194.146.226.133 DOCUMENT_ROOT - /var/www/vhosts/xyz.co.uk/httpdocs SERVER_ADMIN - .co.uk"]abc@@abc.co.uk SCRIPT_FILENAME - /var/www/vhosts/xyz.co.uk/httpdocs/product_info.php REMOTE_PORT - 53180 REDIRECT_URL - /pleatco-pma30-2002-p-32.html GATEWAY_INTERFACE - CGI/1.1 SERVER_PROTOCOL - HTTP/1.0 REQUEST_METHOD - GET QUERY_STRING - REQUEST_URI - /pleatco-pma30-2002-p-32.html SCRIPT_NAME - /product_info.php PHP_SELF - /product_info.php REQUEST_TIME - 1344951486
  5. Okay, From an internal source, calling a regular rewritten URL we get the following (I shifted the logging out of the if statements so we log on every page, not just if the condition is true). Request Original:/pleatco-pma30-2002-p-32.html Request New:/pleatco-pma30-2002-p-32.html If we call a page via a browser using the standard osCommerce URL (product_info.php..) then the URL rewrites automatically in the browser and the log file contains: Request Original:/product_info.php?products_id=32 Request New:/pleatco-pma30-2002-p-32.html Request Original:/pleatco-pma30-2002-p-32.html Request New:/pleatco-pma30-2002-p-32.html Note one page request gives two calls to the validator, presumably as intended - I assume its recursive in that it keeps calling the URL to make sure it has a positive match. Now, this is where it gets odd. If we call www.xyz.co.uk/pleatco-pma30-2002-p-32.html from a validator or server header checker we get the following: Request Original:/pleatco-pma30-2002-p-32.html Request New: Note that Request New is NULL I tried (probably a little too hopefully), to wrap the $this-> calls to the 404 and the 301 with IF statements to check for NULL, and of course, it returns a perfect 200, but the problem is if you call products_info.php from an external source (not the rewritten URL) then you don't get a 301, you get a 200, which will means Google is gonna pick it up as a dupe.
  6. Okay, before each of those calls to $this-> which are remarked out above, I put the following: For the 404: $myFile = "log.txt"; $fh = fopen($myFile, 'a') or die("can't open file"); fwrite($fh, "Request404:".remove_session_id( htmlspecialchars_decode( Usu_Main::i()->getVar( 'original_request_uri' ) ) )."\n"); fclose($fh); And for the redirect: $myFile = "log.txt"; $fh = fopen($myFile, 'a') or die("can't open file"); fwrite($fh, "Request301:".remove_session_id( htmlspecialchars_decode( Usu_Main::i()->getVar( 'original_request_uri' ) ) )."\n"); fclose($fh); My log.txt file then contained the following entries: Request404:/xyz-p-32.html Request301:/xyz-p-32.html However, there is an interesting point to note here - It only appends to the file log.txt when it is called from an external source - If you open this in a browser and jump around the site, the log file doesn't grow BUT if you access it via an external source (i.e. any one of the hundreds of server header checkers) then the log file -does- grow.
  7. Hi Thanks for the reply. Looking at it with fresher eyes this morning, hacking 'validator.php' and taking the following block of code: if ( false !== Usu_Main::i()->getVar( 'page_not_found' ) ) { // $this->pageNotFound(); } // If the incoming uri and the newly created uri do not match then we need to 301 redirect to the new. if ( Usu_Main::i()->getVar( 'request_compare_in' ) != Usu_Main::i()->getVar( 'request_compare_new' ) ) { // $this->redirect( $new_url ); } I know its fairly obvious (as I've rem'd out the calls to the 404 and 301), but the URLs keep working as they were yesterday and the invalid server headers are now gone. So, the header is definitely coming from USU5, but its not immediately obvious what its not liking. I'll put some logging into those procedures, see if I can't draw something out of it - If I do I'll post it up later this afternoon as this one had me pulling my hair out yesterday.
  8. Great contribution, installed on OSC2.3.1, vanilla install on a RHEL box (running Plesk 11) - The pages all seem to load as you'd expect, URLs all rewrite perfectly and navigation doesn't seem to have any issues. However, checking the server headers I am getting 404's being returned. Disabling USU in the admin panel turns these back to 200's and re-enabling gives the 404. Note the pages still load fine in a browser, but its the headers that are bouncing, which is giving sitemap errors and such with Google (the rich snippets tool will not pickup the pages either, although it picks up the snippets when you paste in the HTML). We are intending to use this mainly for aesthetic reasons (i.e. the URL looks more relevant on display to the user rather than being genuinely much better for SEO gaming purposes). Any ideas where to start? I've spent an hour or two looking over the configs and everything -seems- to be fine.
  9. In terms of fixing the MySQL 4.1 issue (our host changed last Friday and knackered us up), I think the problem lies in the BETWEEN statement... Our file is now working perfectly well with the query changed as follows: $orders_query = tep_db_query("select o.orders_id, h.comments,MIN(h.date_added) from " . TABLE_ORDERS . " o, " . TABLE_ORDERS_STATUS_HISTORY . " h where o.date_purchased >= '" . tep_db_input($startdate) . "' and o.date_purchased <= '" . tep_db_input($enddate) . "' and h.orders_id = o.orders_id" . $pull_w_status . $get_customer_comments . ' group by o.orders_id'); Hope it helps anyone else who is stuck.
  10. Hi Everyone Someone tried to call the URL below this morning (about 6am UK time). The file, HKZ.TXT contains the following coding: Anyone have any ideas on what they were trying to achieve? My understanding is that the osWrapper function cannot call an external site, as it does not exist within the 'wrapped' folder (my tests indicate an error message every time I have tried). Comments appreciated!
×
×
  • Create New...