Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

equilla

Pioneers
  • Posts

    343
  • Joined

  • Last visited

  • Days Won

    1

equilla last won the day on March 25 2012

equilla had the most liked content!

About equilla

  • Birthday 06/23/1969

Profile Information

equilla's Achievements

  1. equilla

    3D Secure

    Hi, just wondering if anyone can tell me if anyone has tackled the issue of integration of Paypal WPP with 3D Secure (https://www.paypal-business.co.uk/3dsecure.asp) as yet? And yes, I've just noticed this post has come up in the wrong place... perhaps one of the admins can move if for me...? Many thanks, Mark
  2. Hi all, not withstanding any other issues there may be with this contribution, I had a quick look at the Update Cart issue tonight and have found that the following works for me. If you change this in checkout.php: if (tep_not_null($_GET)){ foreach($_GET as $var => $val){ $_GET[$var] = utf8_decode($val); } } to this: if (tep_not_null($_GET)){ foreach($_GET as $var => $val){ if (($var != 'qty') && ($var != 'id')) $_GET[$var] = utf8_decode($val); } } then I found the update cart button now works. The utf8_decode on $_GET was screwing up the arrays sent in the AJAX request.
  3. Hi Seb, If you have a look in catalog/admin/supertracker.php, you will find the line of code that limits the length of the URL shown (or anything else in the table for that matter); it's this one: if (strlen($tracker[$r]) > 50) $tracker[$r] = substr($tracker[$r],0,50); What this does is to limit all strings to 50 characters in length. If you remove this line, it will show the whole thing. URLs can get very long, which is why this was introduced, in order to avoid having a table that stretched way off screen. Regards, Mark
  4. Hi Remy, wow, that errors been in there a long time, so I'm surprised nobody picked it up before. Those files should indeed be going under catalog/admin.
  5. Hi Again, the 2 most obvious causes are that either this line : require(DIR_WS_CLASSES . 'supertracker.php'); is missing from application_top.php (it should be directly above this line): $tracker = new supertracker; which must be your line 513. or, the supertracker.php file is missing from your shop/includes/classes folder. I would usually expect other error messages about not being able to find the supertracker class file though, so it is possible that there is a problem with the class file itself. If the above things I have mentioned are definitely in place, try re-uploading the supertracker class file and see if that solves the problem. Regards, Mark
  6. Hi Dave, yes, the Supertracker is meant to store this information. It does this by splitting the captured referral URL into 2 parts a)The main part of the URL which gives an indication of the site from which the hit came (e.g. http://www.google.com and b) The GET parameters (e.g. q=what%20I%20am%20searching%20for%20&someotherparameter=true&etcetc). By looking at the b) part stored in the database, supertracker is able to filter out the bits in the parameter string which represent what was searched for. Each search engine is different (they may use q=, query=, p=, etc) so multiple filter patterns are used - it's not 100% foolproof, but can easily be extended for other search engines if you find one that doesn't get picked up in Supertracker today. Hope this helps, Mark
  7. Hi, ah yes, it seems we have a configuration control problem here. The supertracker class was rewritten in one of the earlier versions and no longer needed the sesskey field in the database, so it was removed. Unfortunately, the security update posted by createvideo was based on an earlier version of supertracker, and so is trying to use this field. As a temporary fix you could add the sesskey field to the database, but I think we need to organise a new release that fixes this issue properly. Mark
  8. Hi Barbara. this represents what I call "Direct Access" - in other words people who either typed in the URL for your site, or used a browser bookmark to get to it. Also, anyone using a browser or proxy that withholds their browser referrer information would fall into this category. Regards, Mark
  9. Hi createvideo, can you just confirm which version of Supertracker you found this issue with? Reason I ask is that code to mitigate the risk of SQL injection was introduced in version 3.1a - the parameters that get used in db transactions are treated immediately before the queries. Certainly, on my installs I haven't been able to pull off your suggested method of attacking through this script. Many thanks, Mark
  10. Sorry, no. The code as it is at the moment doesn't allow for blocks of IP address, but there's no reason why the code couldn't be amended to provide for this. Regards, Mark
  11. Hi, yes, you just need to find this line in /catalog/includes/classes/supertracker.php: $excluded_ips = ''; and edit it to put your IP address between the quotes. You can add more than one IP here by separating them with commas. Mark
  12. Hi, the problem comes because you've redefined the array in that second statement, so it overwrites the first definition of $ppc. You need to combine the definition of the 2 campaigns into one array statement like this: $ppc = array ('googlead' => array ('title' => 'Google Adwords', 'keywords' => 'rcb:radio control boats'), 'goshopping' => array ('title' => 'GoShopping.com', 'keywords' => 'mstruck:mstruck')); Hopefully I've got that right - not quite awake yet.... Cheers, Mark
  13. Hi, just an observation, but you've got a missing "&" in the URL you posted. It should read: http://mysite.com/index.php?cPath=27&r...o_control_boats (& added before ref=). the result of your URL would be that cPath equals '27ref=googlead' and the ref parameter would not be set. Regards, Mark
  14. Hi Steven, that query is built in index.php - because it is built in "chunks" depending on various things like whether a manufacturer filter is in use, which columns are shown in the results, etc, is probably why your search for it failed. The query is used to find how many products are to be listed in the results for the category that was clicked. I it's unlikely to be connected with Infobox Skin Manager and given that the result of the query (p.products_id is unknown) is just silly there's something fundamental going wrong here. I've seen something similar before, just once, and if I recall correctly it was due to a corrupt table in the database - have you tried reparing the products database table? It could be that something happened to it when you were migrating your data. Regards, Mark
  15. Ralph, you are right - making this field on of the text type fields should prevent data from being overwritten. The reason for the choice of varchar(255) was basically one of naivety when the contribution was first written. Since I had noticed the the issue you highlight, but hadn't had opportunity to post a correction due to the pressure of work. Manually changing the type of this field should have no side-effects though. Regards, Mark
×
×
  • Create New...