Undefined Index: Telephone

[Webskipper]

Where is debug guide located?

I'm having a repeat errors with v1.57C since server got upgraded to PHP 7.4.20. I'm tackling this one first as it is most prevalent. A telephone number is in MyStore.

Admin Panel:
Currently viewing the most recent 1 of 1 log files with these (myDEBUG-|AIM_Debug_|SIM_Debug_|FirstData_Debug_|Paypal|paypal|ipn_|zcInstall|notifier|us ps|SHIP_usps).* prefixes and not matching these .

PHP Notice: Undefined index: telephone in /includes/modules/pages/contact_us/header_php.php on line 24

File is exactly the original 157C.

Line 24 is: $telephone = zen_db_prepare_input($_POST['telephone']);

I'm not asking you to solve this for me, please teach me how to solve it. There are similar errors that are triggered by other pages.

Thank you in advance.

[mc12345678]

So the fact that the message states: undefined index, this means or relates to a variable that is being used as an array and that it is that variable which has a "problem" where it is used.

Based on the line provided, this means that the "problem" is in the use of $_POST['telephone'].

So one asks, but what is the problem? Seems like it is reasonable to use.

Well, further the message: undefined index means that if the variable is in fact an array, that the particular array element is not defined (in php that is that it is not set or that the array key does not exist)... I just used two different "english" ways to "discuss" php evaluation functions. 1) isset($x['key1']), 2) array_key_exists('key2', $y)

So the thing is, before attempting to use an undefined index, need to either test if it is undefined or ensure that it is defined (likely through test and assignment).

There are a number of ways to work around this particular issue then. Selection of the desired method somewhat depends on what all is going on in the software and how many times some sort of "special" action needs to be taken.

If not mistaken for this "variable" ($telephone) it is defined this one time and the posted data is not needed any further.
So... I would consider performing a simple test as part of the assignment to $telephone. This is instead of ensuring that $_POST['telephone'] is assigned a value so that any use of that array index would exist.

So, in this case there is a little bit of a "complicated" action taken on the posted variable. Because of that, I would probably test for the array key (index) and if it is as desired then assign $telephone to that "complex" action, otherwise I would set it to some acceptable "empty" value. It could be an empty string, it could be null, it could be a zero (0), but I would determine what value based on how $telephone is used. Even in the "test" I described, one could use the tertiary conditional ( (test ? True-action : False-action) ) Or could use a basic if/else type structure or... as preferred for if/else assign the empty value, test if there is a value to be assigned and then instead assign the non-empty value expected...

But... all of that above also depends on why in the world this variable is being set when there is no data posted for the variable. Is this occurring when the page is first loaded? Is this occurring because the field is not being displayed on the form and when the form is being submitted? Could that line be put inside some other "tested" area so that the assignment is only made/tried when it is confirmed that posted data should be present? Did something before this line unset the variable causing this problem?

These questions are just to suggest ways that could have led to this line being an issue and maybe some sort of solution direction...

What I did in order to learn about php troubleshooting was to search the base of those error messages using my favorite search engine. Its not zen cart specific, its php... I then looked at several different common occurrences and potential solutions. I also on occasion (call me weird if you like) will just read code to see how something works, why it is written that way, look at possible problems or ways to cause one, and then look for commonalities of how the teams has suggested to address those issues...

Just some ideas and considerations. Hopefully helps in your venture of learning. Also consider using the developers tool kit to help find things within the code, the database, etc...

[torvista]

The previous post is as always, very informative, but a bit dense for me.

These "errors" will spring up when your hosting upgrades your php: as php evolves it gets more strict and complains about code trying to process things that do not exist, as in this case.

Hence new "errors" appear suddenly when you have made no changes to the code. If it's a problem to fix in the moment, you can always revert to the previous version of php temporarily.

A lot of work has gone into 157 and onwards to trap these things before php points them out and to be honest there should not be any now.

When I come across these things, the first thing I do is look at the same file in the Zencart Github and see if it has already been trapped in the next version, and copy that code.

Generally, you can just prevent the reason for the warning with
$telephone = empty($_POST['telephone']) ? '' : zen_db_prepare_input($_POST['telephone']);
which just checks if the parameter exists, and if not, create it with an empty string.

But, a conscientious user would go a bit futher back and see why this variable was not set by the form in the first place:
includes\templates\YOUR_TEMPLATE\templates\tpl_contact_us_default.php

as maybe you have found a hole that needs plugging.

But no, testing this form with no data in the telephone fieldshows it is passed as an empty string:




So, why does it not exist when the parameters are processed by the header?

Does YOUR contact_us have a telephone field?

Maybe a spambot is using the contact form link?

This is why having a vanilla copy of ZC on the same server is useful to see if you can manually trigger the same error and look at the parameters passed by the form to check this parameter does exist.

If the errors continue and you cannot cause them manually, look at the ip that triggers the error, is it always the same one? If so, block it.

[carlwhat]

The previous post is as always, very informative, but a bit dense for me.

i agree; but rarely, if ever, is the information wrong.

If the errors continue and you cannot cause them manually, look at the ip that triggers the error, is it always the same one? If so, block it.

and what if that same IP address is the source of your largest order? you still want to block it?

being able to reproduce an error at will is the first step to solving said error. if your skills at reproducing that error are not good, try harder.

in answer to your first question, where is the debug guide located? try here:

https://www.php.net/

reading debug logs can get tricky and one needs to understand them. said problem deals with arrays. you can read about arrays here:

https://www.php.net/manual/en/language.types.array.php
https://www.w3schools.com/php/php_arrays.asp

i applaud the learning process.

best.

[Webskipper]

Thanks for all the info.

It's triggering the debug when using the contact us form.

Different IP addresses. Perhaps the extra contact form traffic is from visitors eagerly anticipating the product releases next month.

All along I thought it was getting triggered by not having a phone listed or the way it was listed. Maybe I figure poked an asterisk in there at one point.

Still werking on this.

[Webskipper]

Just delete the define line for telephone?

v157c download. /includes/languages/english/contact_us.php

define('ENTRY_NAME', 'Full Name:');
define('ENTRY_EMAIL', 'Email Address:');
define('ENTRY_TELEPHONE', 'Telephone Number:');
define('ENTRY_ENQUIRY', 'Message:');