Jump to content

Pedros

Members
  • Content count

    42
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Pedros

  1. Pedros

    HoneyPot Captcha

    OK, this explains some behaviour. I thought that setting "Verify Postal Code" to "Blank" only allows empty post code field in the registration field. If it allows any code, how is it different from "Ignore"? If it's not any different, why not just remove it (together with "Both")? Anyway, as I said before, I have this add-on installed and set to "Numbers" in my live shop and it works like a charm, letting virtually no spammer pass, which makes it one of the most useful contributions ever created for osCommerce. Thanks!
  2. Pedros

    HoneyPot Captcha

    @Jack_mcs Thanks for the suggestion. I have just tested this modified code but it only seems to have solved part of the issue. I set the "Verify Postal Code" to "Both" and it didn't allow me to pass with "asdfg" in the "Post Code" field of the registration form, which is the expected behaviour, I suppose. It doesn't seem to check the country-code array, though, as I was still able to create an account with an invalid postal code, i.e. entering "45jkj45" for Spain (ES) that only allows 5-digit all-number codes. It gets blocked with the "Verify Postal Code" set to "Numbers" but not with "Both". Also, setting the "Verify Postal Code" to "Blank" hasn't changed its behaviour and still lets a user create an account no matter what they enter in the Post Code field of the registration form, be it letters, numbers or a combination of both.
  3. Pedros

    HoneyPot Captcha

    @Jack_mcs Yep, the "Numbers" setting works perfectly. I never said it didn't. What seems not to work are the other two settings, i.e. "Blank" and "Both". Can you test these with an all-letter postal code?
  4. Pedros

    HoneyPot Captcha

    @Jack_mcs I see. Could you just explain how you carried out the testing?
  5. Pedros

    HoneyPot Captcha

    @Jack_mcs These two settings do not work in my live 1.0.5.0 shop nor in my test 1.0.5.0 on a local LAMP server. As both these shops have some add-ons installed, I have just set up a third, fresh 1.0.5.0 installation but it still doesn't work so I don't think it's a setup thing as I have made no changes in the default installations. I set the "Verify Postal Code" to "Blank" but it doesn't block creating a new customer account with "asdfg" inserted in the "Post Code" field of the registration form. Then I set the "Verify Postal Code" to "Both" and I am still able to create a new account with "asdfg" in the "Post Code" field. Maybe this IS the expected behaviour? If so, how is it different from "Ignore"? If not, what is their expected behaviour? How did you test these setting in your 1.0.5.0 test installation? btw. I have this add-on installed in my live shop anyway (with the "Verify Postal Code" set to "Numbers") and it does an incredible job as only 2 (two) emails with URL's managed to pass through during a week, and 137 attempts to send a message or create an account were blocked (mainly due to filling out the hidden field which was the original idea of the Honey Pot trap). This is simply amazing!
  6. Pedros

    HoneyPot Captcha

    @Jack_mcs This situation occurs both in my live site and also in the test installation (both are 1.0.5.0) on my local LAMP server so the problem rather seems to be in the application. Have you checked the scenarios that I described in your installations? I mean first setting the "Verify Postal Code" to "Blank" or "Both" and then creating an account with "asdfg" introduced in the "Post Code" field? Was it blocked then?
  7. Pedros

    HoneyPot Captcha

    I've checked with a country from the list (Spain - ES) and also with a country outside it (Somalia). In both cases I was able to create an account with "asdfg" as the Postal Code when the "Verify Postal Code" was set first to "Blank" and then to "Both". This is why I said that these two settings have no effect whatsoever, i.e. they just don't seem to do anything. The only setting for this option that's actually operative is "Numbers".
  8. Pedros

    HoneyPot Captcha

    One more thing needs sorting out. If I set the "Verify Postal Code" to "Blank" or "Both", it doesn't seem to have any effect whatsoever. I mean that I can perfectly register an account even though I introduce letters, numbers or their combination in the Post Code field of the Create Account registering form.
  9. Pedros

    HoneyPot Captcha

    Confirmed, works like a charm now. Thanks a lot, @ecartz !!! 👍
  10. Pedros

    HoneyPot Captcha

    @Jack_mcs I have just replaced the code as you suggested and it only seems to address one of the issues I mentioned. It allows to create an account for a customer from a country that doesn't have states (zones) defined in the database only if the "Verify State and Country match" option is set to "False". If I set it to "True", there is no way for a customer from eg. Denmark to create an account, no matter what they put in the State field in the create_account form. You can easily see this issue yourself trying to create an account with eg. Denmark as the country (or any other country without any zones defined). You will see the "Account could not be created" message and a new "Denied due to a country - state mismatch." entry will appear in the HoneyPot_log. I think that one more IF statement is needed in the CheckCountryState function that will check if a given country actually has any zones defined in the database and will deactivate the function if it does not. Can you make it?
  11. Pedros

    HoneyPot Captcha

    @Jack_mcs Thanks a lot for such a quick reply and the solution! I see that my suspicion that an IF statement will sort it out was a good guess. I should definitely learn some php...
  12. Pedros

    HoneyPot Captcha

    Well, actually it seems that the country-state setting of this add-on gets lost when it has to deal with the countries that do not have any states defined in the database. It works correctly if the chosen country has some states defined in the zones table but makes it impossible to create an account if the user chooses a country that doesn't have any state defined, like eg. Belgium or Denmark. In such a case it shows the "The account could not be created. Please contact us for assistance." message on the screen and registers "Denied due to a country - state mismatch.This IP has x violations." in the HoneyPot_log. The weird thing is that it does this even when the "Verify State and Country match" option in Modules -> Header Tags -> Honey Pot is set to "False", making the whole add-on virtually unusable for those who sell in and to these countries, as users from these countries will never be able to create an account. Sure thing, even though I'm one of such shop-owners, I'm not going to give up on installing this add-on in my live shop as I consider it to be one of the best add-ons that have ever been created for osCommerce. I respect and appreciate the tremendous amount of time and knowledge put into this project, with Jack_mcs being so helpful at the same time. Big thanks to Jack_mcs for this and many other great add-ons that he has already created and will hopefully keep on creating. I am no programmer but I somehow managed to find a temporary "solution" that seems to completely deactivate the country-state check, letting me use this add-on in my shop and letting my customers create accounts no matter what country they are from. In /includes/functions/honeypot.php, for function CheckCountryState I changed: return (tep_db_num_rows($db_query) ? false : true); to: return (tep_db_num_rows($db_query) ? false : false); that can also simply be: return false; Another option that seems to work is commenting out the whole contents of this function. Of course this is just a temporary workaround as I suppose the query should be wrapped in some kind of an IF statement checking in the database if a given country has any states (zones) defined and deactivating the check completely if it doesn't. Still, as I said, I'm no programmer so the proper (and professional) solution may as well be completely different. I'm looking forward to Jack_mcs introducing it so that the "Verify State and Country match" option works 100% as supposed without any issues.
  13. I think that being able for the customer to see their shopping cart after they have added a product is a really useful feature so I decided to try this add-on. Still, I cannot get it working on my Phoenix 1.0.4.0 installations. I have even just set up a fresh installation to eliminate any possible conflicts with other add-ons but it's still a no-go. Checked on Firefox and Chrome (also freshly installed). I have changed nothing in the out-of-the-box installation. I only set "Display Cart After Adding Product" to "false" after I had installed this add-on. Still no modal popping up. The "Display Cart After Adding Product" in the Admin Tool / Configuration / My Store/ is also set to "false" (by default). I have also tried to un-comment the jquery call in the hook and then reinstalling the add-on but it's still not working. What am I doing wrong?
  14. Pedros

    Category Images

    @Jack_mcs Thank you! Sure thing you'll need to verify the code changes again as the ones that I have introduced, even though seeming to work, may as well be incomplete or incorrect from a programmer's point of view. BTW I'm just wondering if the tep_get_path could provide the solution for the other issue...
  15. Pedros

    Category Images

    @Jack_mcs What I can confirm is that, when using this add-on, the breadcrumbs path is no longer broken or incomplete when it comes to showing sub-categories, which before changing the code simply disappeared from the breadcrumbs path. There is another issue with the breadcrumbs path and multi-category products, which then has nothing to do with your add-on, and which is unfortunately still not fixed.
  16. Pedros

    Category Images

    @Jack_mcs The change of code that you suggested didn't work as expected but it showed me the path, so to say . I have replaced all the three occurrences of: 'cPath=' . (int)$categories['categories_id'] with: tep_get_path((int)$categories['categories_id']) ...and now your extension works just perfectly. 👍 I am no programmer so I have no idea if this code is valid; the only thing I know is that it does work. Still, if you think it should be corrected or modified, just let me know, please. As for now, I can finally activate the index_nested and index_products parts knowing that they will show both the complete and correct breadcrumbs path and the second-level of sub-categories in the left menu box. Once again, thanks a lot for the extension itself and for the directions of how to fix it! BTW Do you think that I should also replace the code from your original suggestion? I don't really know the role of this "if" condition in which this part of the code is, and as I said I am no programmer so I can't tell if it can be important in some circumstances.
  17. Pedros

    Category Images

    @Jack_mcs It depends on the point of view. Phoenix apparently requires the long version of the links to display the correct path in the breadcrumbs bar. If you want to make your extension work with it correctly, then such long links should be used. It's that extensions are supposed to work with the main software that they are created for and not the other way round. Also, I believe that replacing the short links with their long equivalents will not be a big deal for you, will it? Once they are replaced, your extension will work just perfectly as it is supposed to, as I cannot find any other flaws in it. I'm no programmer but I'm sure that for you it is a piece of cake and you will be able to release a fully functional and much needed add-on.
  18. Pedros

    Category Images

    I have recently installed this extension on my fresh OSCOM Phoenix and I must say that I find really nice and useful. Thanks a lot!!! 👍👍👍 Unfortunately, I have come across one small issue in it. The extension works perfectly for categories (i.e. in index) but it gets "lost" when it comes to sub-categories (i.e. in index_nested). Having investigated this issue a bit, I discovered that the links that this extension creates for sub-categories lack the part that points at categories. What I mean is that normally the links to categories have such a form: [...]/index.php?cPath=24 but sub-category links are somewhat different and look like this: [...]/index.php?cPath=24_28 Your extension creates them in their shortened form, like this: [...]/index.php?cPath=28 i.e. without the category part of the link. Such links actually do their job, i.e. they will take us to the sub-category we have chosen, but clicking on one of them breaks the path in the breadcrumbs bar (it shows "Catalog" and then the sub-category only, missing the category at all). At the same time, it also shuts the view of the subcategories (that I have activated) in the Categories menu on the left (i.e. only the first-level categories are shown). As I said before, I really like this extension (the same as many others that you have created) so I just thought that it might be something that you would want to fix in the next release. What do you say?
×