Latest News: (loading..)

equilla

Members
  • Content count

    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

  1. 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 Harold, yes, I can confirm that the problems were limited to the Administration tool - I didn't have any issues like this with the Catalog frontend. Regards, Mark
  15. Hi All, just got my first look at the 3.0 Alpha 3 version today, and had one major issue which I thought worth mentioning. Apologies if this has been covered before - I did search the forums and couldn't find any reference to this problem though. Anyway, in admin/includes/application_top.php the following is used in a couple of places: basename($_SERVER['SCRIPT_FILENAME']); to get the name of the script currently executing. Unfortunately, this returns 'php.exe' on the setup I have on my laptop (Apache2, MySQL 4.0.12, Php 4.3.2). The above code is used to: 1. Redirect to login.php if not logged in 2. Include the required language file for the page being viwed This means that I couldn't log in to admin to start with (infinitely loops through redirects to login.php) and also that I have lots of errors on the pages due to undefined constants (as the required language file doesn't get included). On my install I'm going to have to adjust these lines to get admin working as it should be I think. I don't know if this is going to be a general problem - probably it's because of the way I've got php installed on my laptop, which I use for all my code development work, but just thought I'd mention it in case anyone else has problems in this area. Cheers, Mark