Documentation Index

About Visitor Code

Visitors

We have a way of registering users without user registration which we are calling Visitor Code.

Visitor code is enabled only during set-up (it used to be by configuration setting and the code will go back to that the next version). When disabled the visitor code is still included, just all of it's functions do nothing.

This code will look strange or even dumb to people, and I admit that it does not bring much of a benefit to the code, however, that is because the code is not fully implemented. This is just the first step. Visitor control of many things will be added — it will just be done in a way different than what people geerally think of User Registration.

This first step is an API 300 lines long; an Admin interface 300 lines long (including the HTML); and database code of only 60 lines and 6 SQL query strings.

Preamble

The term "Visitor" is used instead of "User" with regard to comment submissions because there is no "User Registration" just to submit a comment — we do not want to require anything like "User Registration" just to allow a visitor to submit a comment.

Preventing comment spam is, of course, the main reason websites force casual visitors to become registered users in order to submit comments. But there are simple ways to prevent comment spam (see file ERROR).

(There are, of course, other reasons for requiring users to register, but there is no need to discuss them here. We simply choose to do things this way.)

Implementation

Our visitor handling code will not be obvious, trust us on that. But we do what we do because, as we said, we do not want to impose any user registration or even any required data on visitors, yet, we want to give visitors the option of being "remembered" and to provide a way to allow a visitor to have exclusivity of his or her chosen user name. And later, customization of what the site looks like and how it operates.

There are two visitor checkpoints: 1) displaying the comment form, and 2) parsing a comment submission.

We use what we call a name/code pair — which is not unlike a username and password, just that there is no registration process. The comment form simply has an extra text input for a code.

There are two states for the form display:

    state one => no cookie
    state two => cookie set

The form inputs are set accordingly:

    state one => inputs for name and code displayed
    state two => input for name = name stored in cookie, code = hidden

A first time visitor would see the two inputs, of course.

Parsing a submitted comment is:

    state one => name entered
    state two => name and code entered
    state three => name entered and cookie is set

(The case of a code entered but not a name is ignored.)

The acceptance of the comment is:

    state one => name is not in the visitor database
    state two => name is not in the visitor database
    state two => name and code are in the visitor database and correct
    state three => name matches cookie

State one does not save the name in the visitor database. The first case of state two saves the name/code pair in the visitor database. For state three the cookie is the name encrypted, but it is tested just in case the form name input had been modified.

Here is the important part: The first case of state two is the new user registration.

If a repeat visitor does not enable cookies she will have to enter the code for each comment.

Comment rejection is when a name is entered which is in the database but the code is not entered, the code is wrong or the cookie is wrong.

Each name/code pair value must be non-blank. (The name is restricted to alpha-numeric, spaces and periods and 32 characters; the code is only limited to 32 characters.) Each name stored must be unique, of course. (The character set is UFT8 and a collation of UTF8_BIN.)