Undefined Index: Telephone

[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:');

[Webskipper]

I simply disabled the line:
/**
$telephone = zen_db_prepare_input($_POST['telephone']);
*/

This was also used to disable the other undefined line triggering errors:
/includes/modules/pages/pop-up-image/header-php.php line 28

/**
$products_values_query = $db->bindVars($products_values_query, 'roductsID', $_GET['pID'], 'integer');
*/

Both of these lines are looking for an integer.

[carlwhat]

I simply disabled the line:
/**https://www.php.net/manual/en/migrat...w-features.php
$telephone = zen_db_prepare_input($_POST['telephone']);
*/

This was also used to disable the other undefined line triggering errors:
/includes/modules/pages/pop-up-image/header-php.php line 28

/**
$products_values_query = $db->bindVars($products_values_query, 'roductsID', $_GET['pID'], 'integer');
*/

Both of these lines are looking for an integer.

on your OP, you were asking to be taught how to solve your problem, not to solve it...

i would not recommend your solutions.

assuming you are running php 7.0 or newer i would solve your problems as so:

$telephone = zen_db_prepare_input($_POST['telephone']  ?? '');

$products_values_query = $db->bindVars($products_values_query, ':productsID', ($_GET['pID'] ?? ''), 'integer'); 

you can read about the new coalesce functions here:

https://www.php.net/manual/en/migrat...w-features.php

if you are not running > php 7.0; then my solution would be to upgrade your server/zen-cart version so that you are.

best.

[mc12345678]

I simply disabled the line:
/**
$telephone = zen_db_prepare_input($_POST['telephone']);
*/

This was also used to disable the other undefined line triggering errors:
/includes/modules/pages/pop-up-image/header-php.php line 28

/**
$products_values_query = $db->bindVars($products_values_query, 'roductsID', $_GET['pID'], 'integer');
*/

Both of these lines are looking for an integer.

Not sure how came to think that both of the lines were looking for an integer, the first item is a telephone number, telephone numbers don't tend to be integers especially if/when there is any additional text separating country, city, or other aspects of the number, e.g. (), -, spaces...

As to the last item, that is not related to the contact_us page and if it is something in the contact_us page, then there is a different issue. That it is related to the popup page seems to indicate that well, need to know what product is involved and if that line is omitted, the page may not provide popup/product info.

While I'm not entirely sure that the coelesce operator wound "defeat" the issues that occur in attempting to use a non-set variable within a complex function, I would agree that more should be done as the second code segment is expected to do work on a query. Presumably that query doesn't work without that code substitution. Commenting it out causes an even larger problem than a nuisance warning log, now a page won't load...