Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Pedros

Members
  • Posts

    42
  • Joined

  • Last visited

  • Days Won

    1

Pedros last won the day on November 24 2019

Pedros had the most liked content!

Profile Information

  • Real Name
    Piotr
  • Gender
    Male
  • Location
    Poland

Recent Profile Visitors

2,116 profile views

Pedros's Achievements

  1. 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. @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. @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. @Jack_mcs I see. Could you just explain how you carried out the testing?
  5. @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. @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. 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. 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. Confirmed, works like a charm now. Thanks a lot, @ecartz !!! 👍
  10. @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. @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. 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. @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. @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.
×
×
  • Create New...