How to program required and optional input fields for account / address information?

[gernot]

Hi,
ZC 1.5.6c, PHP 7.3.10, responsive classic template.
I wonder what things to watch out for when adding fields, or changing fields between optional and required. Seems there are quite a few gotchas, the most common one is that field values do not show up in an address edit screen despite the data being in the database (customers or address_book table).

Here is a list of points I hope are sufficient to get the right logic:

• use of "required" parameter in HTML input field to make browser see field as required.
• adding of ENTRY_REQUIRED_SYMBOL to right of input field for visual aid to user.
• making sure initial SELECT in the module contains the field so that existing value in database can be used to populate form.
• at some point possibly updating the _SESSION variable where the field is used (e.g., customer first or last name).
• possibly having Jscript check_form or check_form_optional function logic in the relevant page.
• in the form setting type to "string" or "stringIgnoreNull" (seems inconsistent to me, not sure exactly how this is important, I understand it relates to security).

I hope by closely following the above points for each field of interest, and tracking the module, page, template and possible Jscript code will help to get the expected result.

At the moment I am having trouble with telephone number editing for additional addresses (existing field), plus the editing for kana fields for Japanese names (new fields), all of which I have managed to make required, but whose data base inserted values do not appear when I try to re-edit them.

[mc12345678]

Use of existing examples that behave as desired for new fields is always a great way to expand on design.

First I want to speak briefly about the SESSION aspect, note that a logged in user will have the customers_id stored to the session. That information alone should be enough to pull any basic information about the user. So generally speaking storing the customer's name in the session should only be necessary (if only briefly) when transitioning/redirecting from one page to the next where POST data can not also be passed along. In a way, it can become a security issue and a waste of resources. The program manages a database, why store a value that can be looked up from the database with a known piece of information? Let me also say, I understand that this is not expected to be done for all cases, just wanted to express concern about over use of session variables.

So some other things of consideration: use of $_POST data to determine/collect the information to be stored to or retrieved from the database.
If a field should have a minimum and/or maximum number of characters.


For the fields that have been added but appear hard to get back, may I suggest searching the code (either catalog side or admin respectfully) for the database table that contains that additional data? Remember to use the format such as: TABLE_PRODUCTS
There may be "helper" functions that are pulling information that is currently being seen as well as specific queries on the page that is being used.

As to the string/stringIgnoreNull issue: at one point in development history, the ZC team came to realize as did much of the programming world, that if a person or business had a name (middle, last or otherwise) that was just "Null", like Mr. or Mrs. Null, then databases would have an issue because entry of that name field would cause the database to treat that entry as if the field had no information. So... the work around was to create a new handler (stringIgnoreNull) that would allow the word null to exist as a word and not revert to an empty field. In so doing, the string handler was modified such that if the word null or maybe it was NULL was anywhere in the submitted text that the entire field would become an empty field known as null. As said, there was a point in time where this feature was added. Depending on how far back you are considering supporting, you may need to adjust for the ability to use stringIgnoreNull.

Just some other thoughts on the topic(s).

[gernot]

Hi mc12345678, thanks for your thoughts.

Use of existing examples that behave as desired for new fields is always a great way to expand on design.

Good advice as always, I've tried that, and tried on that basis to set up the checklist to figure out what I might have missed.

First I want to speak briefly about the SESSION aspect, note that a logged in user will have the customers_id stored to the session. That information alone should be enough to pull any basic information about the user. So generally speaking storing the customer's name in the session should only be necessary (if only briefly) when transitioning/redirecting from one page to the next where POST data can not also be passed along. In a way, it can become a security issue and a waste of resources. The program manages a database, why store a value that can be looked up from the database with a known piece of information? Let me also say, I understand that this is not expected to be done for all cases, just wanted to express concern about over use of session variables.

So some other things of consideration: use of $_POST data to determine/collect the information to be stored to or retrieved from the database.
If a field should have a minimum and/or maximum number of characters.

Thanks for that insight. So in general, not needed, and to be avoided if possible. I took my queue from includes/modules/pages/account_edit/header_php.php where the session variables for first and last names are updated:

$db->perform(TABLE_ADDRESS_BOOK, $sql_data_array, 'update', $where_clause);
    
    $zco_notifier->notify('NOTIFY_HEADER_ACCOUNT_EDIT_UPDATES_COMPLETE');
    
    // reset the session variables
    $_SESSION['customer_first_name'] = $firstname;
    $_SESSION['customer_last_name'] = $lastname; 

For the fields that have been added but appear hard to get back, may I suggest searching the code (either catalog side or admin respectfully) for the database table that contains that additional data? Remember to use the format such as: TABLE_PRODUCTS
There may be "helper" functions that are pulling information that is currently being seen as well as specific queries on the page that is being used.

Good point, I have been scanning code following the program logic as best I can, but yes, I should check if I have missed some logic branches and the associated database select and/or update statements. Should not forget this in future.

As to the string/stringIgnoreNull issue: at one point in development history, the ZC team came to realize as did much of the programming world, that if a person or business had a name (middle, last or otherwise) that was just "Null", like Mr. or Mrs. Null, then databases would have an issue because entry of that name field would cause the database to treat that entry as if the field had no information. So... the work around was to create a new handler (stringIgnoreNull) that would allow the word null to exist as a word and not revert to an empty field. In so doing, the string handler was modified such that if the word null or maybe it was NULL was anywhere in the submitted text that the entire field would become an empty field known as null. As said, there was a point in time where this feature was added. Depending on how far back you are considering supporting, you may need to adjust for the ability to use stringIgnoreNull.

Much appreciated. So it has no direct bearing on the required or optional status of a field, but directly to do with the value input when there is an input value.

I still haven't found my solution yet to retrieving updated furigana name and telephone numbers, but I will be checking possibly missed database queries from now. I'll update when I do solve the issue to make it easier for others to follow a similar procedure in future.

[gernot]

Good news is I had managed to get everything to appear correctly in the edit_account screen, but had confused that one with the address_book_details screen on occasion when tracing the program logic.
I will update the steps in a day or two once this is sorted out and re-checked.