PHP question on /includes/templates/mytemplate/templates/tpl_product_info_display.php

[RodG]

You've used assignment operators (single equal sign) instead of equality operations (double equal sign):

The recommendation these days is to use a triple equals sign (===)

Cheers
RodG

[lat9]

The recommendation these days is to use a triple equals sign (===)

Cheers
RodG

Agreed, on new code; simply changing all == (equal to) to === (exactly equal to) in "legacy" code can have unwanted consequences.

[RodG]

Agreed, on new code; simply changing all == (equal to) to === (exactly equal to) in "legacy" code can have unwanted consequences.

Yes, I am aware that there is a subtle difference between == and ===

Just curious, it a known fact about 'unwanted consequences' , or is it the same disclaimer that I probably should have made on the basis that it probably hasn't been tested in every possible case?

Fact or not, I agree, it doesn't make sense take the risk of retroactively changing all legacy code due to the current recommendations.

I do like the idea of making PHP a little more strict though, and for new code, the === is less likely to have unwanted consequences than the ==, and generally speaking, if I AM working on legacy code and come across the odd == I tend to automatically change it to the === and test that nothing got busted as a result (so far, I haven't busted anything by doing this), hence my curiosity as to whether the 'unwanted consequences' are real, or just something that is theoretically possible.

"I don't know either" is a perfectly acceptable answer. :-)

Cheers
Rod.

[suedouglas]

Thanks so much everyone who replied! The === sign worked fine! I've spent about 5 days on this one piece of coding so I'm delighted I now know what the problem is! I was under the misconception that the == meant not equal to, even though I had seen coding with the != as well which I know for sure is not equal to, because I do write SQL. This was most definitely my problem with trying to get the data from the database too!!
Thanks so much for your help, it's much appreciated!

[mc12345678]

Not sure if this is the right forum for php questions, but I'm having trouble finding a PHP forum

I'm trying to display the manufacturers image on the product info page which when clicked goes to their url to see all that manufacturers products

My coding is in the following .php file:
/includes/templates/mytemplate/templates/tpl_product_info_display.php The problem is that only the first manufacturers image is shown on all products, even those that belong to the second manufacturer. Can anyone spot what I have wrong please? (I've resorted to hardcoding the urls and images which is why I need an if statement, as I couldn't get it to work at all when trying to get the manufacturers url and image from the database, and since there are only two of us ...!)

This is my problem coding:

<?php

$manufacturers_name = zen_get_products_manufacturers_name($product_info->fields['products_id']);

If ($manufacturers_name = "Sandie Burchell") {
?>
<a href="index.php?main_page=index&manufacturers_id=3"> <img src="/images/sandie_burchell.jpg"> </a>

<?php
} elseif ($manufacturers_name = "Sue Douglas") {
?>
<a href="index.php?main_page=index&manufacturers_id=4"> <img src="/images/sue_douglas.jpg"> </a>
<?php
}
?>

If I'm totally in the wrong forum for this question, could anyone recommend a good (preferably free!) PHP forum that would be able to help me please?

Thanks!

Thanks so much everyone who replied! The === sign worked fine! I've spent about 5 days on this one piece of coding so I'm delighted I now know what the problem is! I was under the misconception that the == meant not equal to, even though I had seen coding with the != as well which I know for sure is not equal to, because I do write SQL. This was most definitely my problem with trying to get the data from the database too!!
Thanks so much for your help, it's much appreciated!

As to a possibly more rounded approach to the solution now that it is more clearly represented than in a previous related thread:

<?php

$manufacturers_name = zen_get_products_manufacturers_name($product_info->fields['products_id']);

?>
<a href="<?php echo zen_href_link(FILENAME_DEFAULT, "manufacturers_id=" . zen_get_products_manufacturers_id($product_info->fields['products_id']), $request_type); ?>"><img src="<?php echo zen_get_manufacturers_image($product_info->fields['products_id']); ?>"></a>

This is untested, so may have some error(s)...

[mc12345678]

In my above recoding I forgot that there is a function also to provide the image html through ZC as well... So the above falls short of a truly Zen response.

zen_image( $src, [ $alt = ''], [ $width = ''], [ $height = ''], [ $parameters = ''])
Where $src would be everything provided above at and after the

<img src=

section related to the image....

As to a possibly more rounded approach to the solution now that it is more clearly represented than in a previous related thread:

<?php

$manufacturers_name = zen_get_products_manufacturers_name($product_info->fields['products_id']);

?>
<a href="<?php echo zen_href_link(FILENAME_DEFAULT, "manufacturers_id=" . zen_get_products_manufacturers_id($product_info->fields['products_id']), $request_type); ?>"><?php echo zen_image(zen_get_manufacturers_image($product_info->fields['products_id'])); ?></a>

This is untested, so may have some error(s)...

[mc12345678]

Yes, I am aware that there is a subtle difference between == and ===

Just curious, it a known fact about 'unwanted consequences' , or is it the same disclaimer that I probably should have made on the basis that it probably hasn't been tested in every possible case?

Fact or not, I agree, it doesn't make sense take the risk of retroactively changing all legacy code due to the current recommendations.

I do like the idea of making PHP a little more strict though, and for new code, the === is less likely to have unwanted consequences than the ==, and generally speaking, if I AM working on legacy code and come across the odd == I tend to automatically change it to the === and test that nothing got busted as a result (so far, I haven't busted anything by doing this), hence my curiosity as to whether the 'unwanted consequences' are real, or just something that is theoretically possible.

"I don't know either" is a perfectly acceptable answer. :-)

Cheers
Rod.

Outside of ZC I was programming some PHP to provide some information. During the initial coding I had used == for all such verification of equalities. I then chose to use === in all such cases by replacement of the two with the three. Problems followed. The most basic example of where such a problem is likely to occur is if the false statement is used to capture situations where the value is 0 or false... Certainly with a newer perspective one could evaluate using both criteria ored together, but under the "old" thought there was no need...

There may be other examples, but that is one that I have seen/experienced.

[lat9]

Yes, I am aware that there is a subtle difference between == and ===

Just curious, it a known fact about 'unwanted consequences' , or is it the same disclaimer that I probably should have made on the basis that it probably hasn't been tested in every possible case?

Fact or not, I agree, it doesn't make sense take the risk of retroactively changing all legacy code due to the current recommendations.

I do like the idea of making PHP a little more strict though, and for new code, the === is less likely to have unwanted consequences than the ==, and generally speaking, if I AM working on legacy code and come across the odd == I tend to automatically change it to the === and test that nothing got busted as a result (so far, I haven't busted anything by doing this), hence my curiosity as to whether the 'unwanted consequences' are real, or just something that is theoretically possible.

"I don't know either" is a perfectly acceptable answer. :-)

Cheers
Rod.

As mc12345678 replied, there are places within Zen Cart (and especially the plugins!) where configuration values are checked as

if (CONFIGURATION_VALUE_CONSTANT == 0) {
}

which works just fine. The construct

if (CONFIGURATION_VALUE_CONSTANT === 0) {
}

will never evaluate to true, since configuration constants are strings, requiring the exactly-equal-to code to be formatted as

if (CONFIGURATION_VALUE_CONSTANT === '0') {
}

[lhungil]

Not sure if this is the right forum for php questions, but I'm having trouble finding a PHP forum

I'm trying to display the manufacturers image on the product info page which when clicked goes to their url to see all that manufacturers products ...

*** deleted ***
Almost identical to the second snippet posted by mc12345678. Only difference was the use of an observer to retrieve the manufacturer info (in a single SQL query) instead of retrieving directly in the template.
*** deleted ***

Yes, I am aware that there is a subtle difference between == and ===

Just curious, it a known fact about 'unwanted consequences' , or is it the same disclaimer that I probably should have made on the basis that it probably hasn't been tested in every possible case? ...

As far as I know, unwanted consequences are likely when the original author of the code WANTED the behavior of ==, not ===. When upgrading old code, the author of the old code may have knowingly relied upon: false == 0 == "0" == null == "" (so just changing to === could have negative consequences). Or the old code may be comparing objects (not primitives) and thus intentionally using == instead of ===.


For primitive types in PHP (such as int, float, bool, etc) I'm usually a fan of using === (aka the identity operator or identical) in favor of == (aka the comparison operator or equals). IMHO this makes it less likely for a coder skimming over code to misinterpret the intent (and helps the coder avoid mistakes if they forget how == works in PHP).


When it comes to objects in PHP, I disagree with using == (aka the comparison operator or equals) altogether in favor of the class defining a comparison method (more control over what constitutes equality - such as the use of === for checking primitive properties and checking the actual classname). For objects, === (aka the identity operator or identical) is not often used as it only evaluates true when the two objects are the same instance of the same class.

[mc12345678]

*** deleted ***
Almost identical to the second snippet posted by mc12345678. Only difference was the use of an observer to retrieve the manufacturer info (in a single SQL query) instead of retrieving directly in the template.
*** deleted ***

So curious, in the concept of using the observer, that would still require modification to the template file correct? (Ie. One issue with the modification proposed is that in subsequent upgrades or in new templates, this change must be carried over to remain a part of the displayed informatiion.) I haven't played/tested this aspect but do the variables assigned in the observer become a part ofthe global space or do they fall out of scope? Would declaring the variable in the observer as global maintain it in scope for "global" use?

I understand that the above basically would have provided all of the requested data (manufacturers_id as well as manufacturers_image), but was trying to understand how to keep it in use for the code space that had the notifier.