Account Address Book Floating Boxes

Inspired by Amaz0n account address book page, I decided to give it a try with my ZC store account address book. It worked out grate. This is a much more clean updated page and changing default address is a one click event. I also redid all my account pages, but this was the most requested part.

All addresses are contained in fieldsets with links to edit, delete and make primary within each container. The add address container with just the add button lets the user know they have space for more.  Once all addresses are full, the add box is not displayed.

Containers stack when the screen width changes making it responsive all on its own.  No need for additional css or scripting.

You can download the full package with instructions from our store free download page.

How to use honey pots in Zen Cart Forms.

Some ideas on coding spam traps in Zen Cart forms.

I get that not everyone is able to code or come up with something that works with your site layout. We can only help so far and then it becomes a job… If you can not figure something out, don’t be afraid to ask how much or hire someone.

This is for folks that want to learn or do it them self and not a drop and run set of code.

I’ll concentrate on the ‘Contact Us’ form, but this can and should be used on any from. The words ‘CHANGE_THIS’ means just that! Change the word to something that makes sense to the form its in. The idea of a good honey pot is that theres no noticeable difference between it and the rest of the form.

The three type of honey pots I’ll use are:

1) hidden input, radio, and textarea form field traps.
2) visible questions.
3) confirmation of information.

1) hidden input, radio, and textarea form field traps.

Step 1. Setup the ZC template pages.
The contact us page has four parts,
1) the template page YOUR_TEMPLATE/template/tpl_contact_us_default.php,
2) the header page modules/pages/contact_us/header_php.php,
3) the language page languages/english/YOUR_TEMPLATE/contact_us.php,
4) the css page YOUR_TEMPLATE/css/contact_us.css.

Two things that affects all ZC, the template override pages and the non-override pages. The three pages here, template, language, and css should be in your template override folder and only affect your template. The header page does not have a override and will affect all templates!

I use a common css file for all my css for the template I’m using and not the contact_us one.

Step 2. Using the hidden field.
No matter what you do, you can’t prevent users from having full access to every bit of data on your website. Additionally, there’s no way to disable the ability of any user to simply “view source” or “view page info” for your site. You CAN make it super-confusing to read it… Simple input fields are easy to understand, complex checkbox or radio fields can confuse anyone. Input or textarea fields are normally empty, but what if that wasn’t true! Check boxes can be checked or not, 50% chance of getting that right.. Two radio’s connected, click one or the other, but both can be unselected or false at startup!! Text areas, what system wouldn’t pass up a chance to advertise in that! Option fields, pick any one and your wrong! In short, any form field can be used to trap a bot hidden or not!

This is a normal email field for my site:

<div class="js-float-label-wrapper">
<label for="email-address"><?php echo ENTRY_EMAIL; ?></label>
<?php echo zen_draw_input_field('email', ($email_address), ' id="email" spellcheck="false" title="Please enter a E-Mail address (" pattern="^(([-\w\d]+)(\.[-\w\d]+)*@([-\w\d]+)(\.[-\w\d]+)*(\.([a-zA-Z]{2,5}|[\d]{1,3})){1,2})$" required="required" aria-required="true"', 'email'); ?>

This would be my spam catch:

<div class="js-float-label-wrapper email-pot">
<label for="email-us"></label>
<?php echo zen_draw_input_field('CHANGE_THIS', '', ' id="email-us" title="do not fill in!" placeholder="do not fill in!" autocomplete="off"', ‘email’); ?>

Do you see the difference? I use a script to float labels, if I used a label for this field, the default would not be empty, but the label! So testing for the label would be correct and not empty. Basically, the reverse of normal honey pots. Normal behavior is that this field would be empty. To test, one would comment out the css hide and fill in the line during form submit.

Based on the hidden idea, the radio field would be like this:

<div class="js-float-label-wrapper email-pot">
<p>To prevent Spam we ask if you are a human or a computer. If for some reassign you are reading this line.<b>Do not Answer!</b></p>
<?php echo zen_draw_radio_field('user', 'H1', false, 'id="user-1"') . '<span class="input-group-addon"><i class="fa fa-male fa-2x"></i></span>' . zen_draw_radio_field('user', 'C2', false, 'id="user-2"') . '<span class="input-group-addon"><i class="fa fa-laptop fa-2x"></i></span>'; ?>

Both are set to false, if ether is set during submit, then its a bot.

Step 3. Hide the field.
Using contact_us.css or stylesheet.css add the email-pot class.

.email-pot {position:absolute; visibility:hidden; display:none;}

Step 4. Test for bot answers.
In this test we want the bot to think it succeeded in submitting and leave. So we need to use the success page and not an error message which is why adding comments for humans not to fill out if for some reason the css fails is just as impotent.

In modules/pages/contact_us/header_php.php when the form is submitted, it starts an action called SEND so we need to look for the beginning of the submit action then under it add our post lines.

if (isset($_GET['action']) && ($_GET['action'] == 'send')) {

$antiSpam = isset($_POST['CHANGE_THIS']) ? zen_db_prepare_input($_POST['CHANGE_THIS']) : '';
  $userspam = zen_db_prepare_input($_POST['user']);

You can omit which ever one your not using or do both.
The test can be after all others or before:

if (($antiSpam != '') || ($userspam != '')) {
zen_redirect(zen_href_link(FILENAME_CONTACT_US, 'action=success', 'SSL')); 

If ether are not empty, stop sending and get to the success page to fake out the bot.

2) visible questions.

CAPTCHA is basically a visible question a human would answer. The issues with any is how the user can interact with the question! CAPTCHA code can be internal (Your code on site) or external (third party code off site). With ZC plugins, you have both options. Personally, I would keep my customers on site and not allow for off site tracking or down servers. If captcha is done so the bots can not read the answer, then nether can humans and even worse if sight in-pared! Which is one reason for 508 complacency.

If not CAPTCHA then what? Well, build a better question and answer system! We have one hidden that use radio buttons, unhidden and test for the correct answer!!

The bot has a 50% chance of guessing right with radios and checkboxes!

Input field, 2+2= type the number 4! How about some other question like yellow+blue= type the word green!

What about sliders? The variables are grate, the answer can be any number, lets see the bots guess right here…

The harder one to code is the slider so I’ll cover it.

Step 1. Add the code for the slider at the bottom of the form.

<div class="slidecontainer">
<p>Are you Human? Slide to Human..</p>
  <?php echo zen_draw_input_field('iqTest', '', ' min="0" max="50" value="0" class="slider" id="id1"', 'range'); ?>
<br /><br />
<span>Value:</span> <span id="f" style="font-weight:bold;color:red"></span>

Step 2. Add css to format the slider.

/******** slider ********/
.slidecontainer {
    width: 100%; /* Width of the outside container */

/* The slider itself */
.slider {
    -webkit-appearance: none;
    width: 100%;
    height: 1px;
    border-radius: 5px;  
    background: #d3d3d3;  
    outline: none;
    opacity: 0.7;
    -webkit-transition: .2s;
    transition: opacity .2s;

.slider::-webkit-slider-thumb {
    -webkit-appearance: none;
    appearance: none;
    width: 25px;
    height: 25px;
    border-radius: 50%; 
    background: #cc0000;
    cursor: pointer;   

.slider::-moz-range-thumb {
    width: 25px;
    height: 25px;
    border-radius: 50%;
    background: #4CAF50;
    cursor: pointer;

Step 3. Add script to modules/pages/contact_us/jscript_main.php
The code is used to display feed-back to the user so they know when to stop or the question was answered. Some day the browsers will support this without script, a html5 issue!

Enter within the script tags are create another set.

$(document).ready(function () {
var slideCol = document.getElementById("id1");
var y = document.getElementById("f");
y.innerHTML = slideCol.value; // Display the default slider value

// Update the current slider value (each time you drag the slider handle)
 slideCol.oninput = function() {
    y.innerHTML = this.value;
    if (this.value >= 50) {
      y.innerHTML = 'Human';

Step 4. Set the trap. modules/pages/contact_us/header_php.php
Set the field get and check under the other spam tests.

  $humanTest = zen_db_prepare_input($_POST['iqTest']);
     if ($humanTest != '50') {
     $messageStack->add('contact', 'You don\'t seem to be Human yet!', 'error');
     $error = true; 

We don’t want to reload the page and delete all the user inputs here, they need to fix there answer and resubmit the form.

You can use any number, script can change any number to a word, the possibilities are limitless.

3) confirmation of information.

Simply, the user fills out the form. The submit button verifies the form and takes the user back to the page with all fields full. The page asks the user to verify the information before sending. Basically two clicks to send the page. Most bots will see the first send as finished and leave. The second click would be a human and final send.

Users normally don’t have a problem with verifying what they entered before sending.. Its like previewing before submitting to a forum!

In closing,  I see no reason to eye test customers with an off site CAPTCHA that may not work or be available to use.

Modifying the shopping cart Display

The basic Zen Cart shopping cart is simple, plan and not full of information.  For a on line shopping cart, it fails to give much inspiration to buy!  What it does is just lets your customers know the total amount  items add up to.  If you want to see shipping, theres another button to show, but doesn’t add up the totals!

So.. with ZC, if you think of something, it can be done.

Modifying the shopping cart required more code edits then I first thought and I’m still thinking of simplifying it more than maybe I’ll post the code. What I wanted to do, I seen on other big box stores. The cart showed the total of products, with shipping and tax based on a default zip code. Change the zip to your address and you could see what the shipping/tax for your area would be.

Sounds simple right, know before you add all your personal info and buy it all..

Zen Cart is based on the idea that customers need an account and are logged in to buy. In this day and age, for me I would leave.

I’ve setup my site so customers don’t need an account so why not have a cart to show more!

This turned out better than what I was looking for, not only can they select a location, but the selected shipping continues into the checkout process.

The process of making a better shopping cart..

  1. First, I don’t believe that a responsive design should require massive scripting to detect your device! With css and html I should be able to do it and yes you can. The cart is done in css and html5 only. each container is setup to stack or unstack according to screen size.
  2.  I used Shopping Cart Price Broken Down mod to make sense out of all the attributes in my products.
  3. Totals block I stacked the totals on top, then the estimated shipping form below it.
  4. Added a info box to take up empty space below the items which hides when the screen drops to a stacked view.

I think it came out grate and the estimated shipping is based on true shipping and not estimated at all..

Interested in the code, ask!

COWAA Login page reconfigured!

Check Out With Any Account COWAA has a register account part that only requires a good email, password and first name to create the start of a full account with us.

One thing that I noticed on other sites is how the log in form has changed. Amazon, Bestbuy and even Target. There neat to the point also have register account abilities..  I know I’ve heard the grumbles in the past about the ability to shorten account to register.  Which is why its part of COWAA in the first place.  I just didn’t like the cluttered arrangement of the login-create account-register account thing that the log in page turned into.

Looking at the page and thinking how can I clean it up! First, delete the things I don’t need.. I do not need the create account section.. I do not need the one click PayPal thing. I need to add the register page code to this log in form..

I use H5F in my forms across the site, but the new code is a pain and it just never was updated to meet the change in tech. The big box sites changed again and I like there design idea. How can I fix the design layout of my site?

I found a jQuery plugin for floating form labels FloatLabel.js which does the same as the big box stores. Making use of HTML5, script and CSS tricks, I was able to get what I wanted without the heavy weight of something like H5F to do validation at the user level of the form before its submitted. After all, I know the form input will be validated at the server level I really don’t need heavy validation out front.

With Float Label the label is in the form field which moves up and gets smaller once you start typing something in. It also makes use of a hind icon for required fields which changes as the form is validated using pattern matching. This is a very compact form making it grate for any screen.

The idea is to make it simple, intuitive and responsive to the user. At the same time, get ride of the old annoying form issues of the past. Double input of email and passwords!! Why!! If you type your email in wrong the first time, you well more than likely type in wrong the second time too. If you can see what you typed in the password field, why type it again! Security through obscurity is not security!

So now I have two forms, one for login using email and password. The other form I need first name, email and password. I think the welcome email sounds better with a name than a hay you!

On my site I use the remember me code and a password reset that requires a question and answer with your account. You may not have on your site unless you fond mine. This adds two more fields.

So, email, password unmasked with a hide button . Then a button to expand and hide things like the forgotten password link, change the title, show the first name field and password reset questions. Now its a register account form email, password, first name and password reset questions.

Front side is a set of script and pattern matching with bot blocking. Back side is the standard form validating and anti-robot checking.

Matching your template should be supper simple, the coded pages are just the login page. You must have COWAA installed and working before making this change. Not intended for less then ZC155e or for none COWAA installs. I’m working on matching it up to the default responsive template but its so difficult to work with it that’s changing it is a pain. One reassign why I would never use it, plus it doesn’t meet my needs.

Password Complexity in ZenCart

I had a web designer tell me we should not give feedback to a customer that didn’t type in the right format for a password!!  Other words, don’t tell them that they need at lest one number, one upper case, one lower case and one non-character for a correct password format!  He was thinking of not telling a would be hacker what to type in!!

Makes one wounder if they really understand what they’re doing when designing web sites or care.   Also one reason so many sites get hacked and so many programs get cracked!

Think about it as a customer!  Here you are about to sign up for another site you really don’t need just to spend your hard earned money. You enter all your info then have to create a password. After entering your password, maybe one you use all the time, after all, how many passwords can you remember?  The site rejects you saying your user name or password is incorrect!!   Well which is it? You type it in again because you can’t see the password you typed for it shows this stupid star thingy *****.    Again it rejects and so do you… moving on to a site that doesn’t test your skills at typing.

Lest that’s what I and others do when we get no usable feedback. We assume you don’t really want us to buy!

Now lets look at it from the cracker eyes.. Why would I want to waste my time cracking your password when I already have your email address!  Most sites have a very week password reset system or human support system. After all, why crack it when they well send you a new one?

So.. if there is human support and I call in saying, Hay I messed up and deleted my old email address before resetting my user accounts with different shops! Can I get you to email the changed password to this address so I can recover my account?

If the support says.. sure I can do that for you.. I’m in..
If the support says.. sorry, I can’t do that, but I well deactivate your old account so you can create a new one. I lost, move on.

So, usable feedback.. what is that after all..

Did you know that there is very few reasons to masked your password as you typed!! That’s the stars ** you see! If a peeper is standing by looking, there more then likely looking at your fingers not the screen. The masking only make one think there safe and forget about the key loggers or finger reading cameras!

So what is a web designer to do… Stay on top and remember the old days and create  some new tricks or code…

Start with a good safe and tested password reset system first! Then set up a good password system that’s user friendly. Add a hide/unhide button on the password field and make unhidden the default. Add a password creator button so to give hints at good passwords or make it easy for them. If they can see what they are typing, don’t make them retype it. I tend to copy and paste so why do the confirmation fields at all..

Give feedback as they type, week, strong.. you can even give feedback when they entered the right set of one number, one upper case, one lower case and one non-character… Don’t be a fool, this is not going to tell a hacker anything other than the time it would take to brute force a password crack. Most well leave some well try.. There are other ways to take care of this type of attack and ZC has it in place already. Unless some fool removed it when designing your web template!

So, masked passwords, confirmation fields, no feedback is old school and maybe old code.

So on to password resets.. there’s basically three types in use. Rating from weakest to strongest. There are hacks to all three!

1) Enter email address and if matched, send a new password to that address.
This is like sending mail without a address, just kind of hopping it makes it to the intended receive and then hopping they change the password to something else.

2) Enter email address and if matched, email a link with token that when used well take the user to a page where they can change there password.
This is not bad, used more often now and works, but the user may leave to answer the email, could lose there shopping cart items, not to good for a shopping site.

3) Enter email address and if matched, open a reset page where the user can enter a new password. This has to be active from account creation and I’ve seen this done in different levels. The user has to answer 1 to 4 questions provided during account creation, if right, the password is changed.
The customer never leaves your site, shopping cart is maintained and shopper continues after resetting password.

In my use of password resets, number three is the best if you never answer the questions truthfully!! When doing questions, I pick something easy to remember and makes no sense to any of the questions..

In short, as a coder, if I make it easy for you to create a password using feedback and such, then maybe you wouldn’t need to reset it later on!

This is why on my shop page passwords are not hidden, feedback is there. I like you to use harden passwords, but I don’t enforce it yet. I’ve codded all three resets, but use number three.

On top of it all, I’m not holding you to an account for checking out!!

We never store payment information.  The only thing we have is your email, phone and address and well protect it the best we can.

This is my opinion and not putting down a follow coder!   Some folks are not keeping up with the times or set in there ways.  I’ve been coding long before the Internet was released and was frustrated with hml before  html and PHP was created.  I’m still looking ahead, not back, having fun with CSS4.

password feedback
password feedback
Account Creation
Account Creation
password reset
password reset