1.0.8.7 Questions / Comments / Concerns

[ecartz]

Update instructions (from 1.0.8.6): https://github.com/CE-PhoenixCart/Updat ... /README.md
Update SQL: https://github.com/CE-PhoenixCart/Updat ... update.sql
Update zip: https://github.com/CE-PhoenixCart/Updat ... update.zip
Release: https://github.com/CE-PhoenixCart/Phoen ... g/v1.0.8.7

This is the 1.0.8.7 release, in the 1.0.8.* series. Primary changes:

1. All the sideboxes.
2. All the header tag modules, including the JSON-LD Product Schema.
3. Review writing.
4. All the payment modules except 2Checkout and those in the PayPal App.
5. All the product_info modules, PI and content.
6. The shopping cart class and anything that uses get_products.

Users of get_products include

1. The cart order builder (used during checkout).
2. The shopping cart page's product listing, both module and template.
3. The shopping cart navbar template.
4. The shopping cart sidebox template.
5. Who's online in admin.

This updates everything in core that had been using product information to use the Product class instead. It updates the header tag modules and sideboxes because some of them needed updated, so I updated all of them.

Some people have asked why we are switching from function files to classes. There are several reasons:

1. Classes can be autoloaded, so we don't have to explicitly load them before use.
2. If they are never used, we don't have to load them at all.
3. This allows developers to modify the behavior of the Product class without having to change all the consumers.
4. This allows developers to use different data from the Product class if they already have a product object.

In the old way, to add a new function, we had to modify a core file. Either we added the function to something like includes/functions/general.php or we modified includes/application_top.php to load the file containing the function. And we had to add the function regardless of whether or not it was ever used. Then, to use the function instead of an old function, we'd have to go around to every consumer of the old function and change it. And the function itself would have to make a separate database query to get the information.

In the new way, we can add new class methods by simply putting the class in the right place. If it's needed, it gets autoloaded. Not needed? Not loaded. If we want to change an old function's behavior, we simply use one of the methods to override it. And, once data is loaded to the product (which can happen as part of the initial load of the product in many cases), it's saved until it's needed. So we only load the data once, often as part of the initial query. Finally, if we have a product object, and we want to get different data from it, we just tell the object what data we want. If we've set up the data to be loaded, the product will either already have it or it knows how to load it. So no direct SQL in template files to hack around the fact that the module file didn't know to load it. Modules don't have to know how to load product data. The Product class handles that.

To give another (not Product) example: we generate a link in the module's class file and pass it to the template. Now, how does the template modify the link? The old way was to parse the URL string, modify the data, and then recreate the URL. Where both parsing and recreating could be fragile. In the new way, the URL string hasn't been created yet. So we can just modify the data in the URL object directly. Then when we want a string, the object generates one. So the template doesn't have to parse or recreate the link. And we gained this just from passing around the URL object instead of a URL string, only changing the object to a string at the last moment.

We can do the same thing with form inputs, etc. This is especially powerful with CSS, where the template can add to or even completely replace whatever the module sets. Or the module can not set CSS and leave it to the template file.

Objects can do these kinds of things. Strings returned from functions can't. So while strings are superficially easier and more direct in unmodified code, they harden the code and make it more difficult to modify. Meanwhile, the objects stay flexible.

In any case, this finishes the Product class consumers. Many of the other new classes still need the legacy function calls to be replaced with method calls.

[Nigel]

Sounds exciting.
I was about to start a new install and this has made my mind up.
Is this likely to break hacks, hooks etc., that have been applied ?

[ecartz]

Is this likely to break hacks, hooks etc., that have been applied ?

Any update can break hacks/hooks. This would be most likely to break hooks related to the shopping cart or showing product information. Overall though, this is mostly changing from calling the old functions (which behind the scenes, use the new classes) to calling the new class methods directly. Absent mistakes, this should be less impactful. Because it should be doing the same thing, only less circuitously.

[Nigel]

I had a little code change in "includes/modules/boxes/bm_whats_new.php", suggested by Zipurman.
The idea is to hide whats new from visitors.
The 1.0.8.7 changes give a new version of this file.
Should I create an override version of it rather than change the main file?
Thanks.

viewtopic.php?p=6428#p6428

[ecartz]

I would copy the new file to a new module and modify that. The change is the same, even if the rest of the code is different.

I wouldn't try to maintain a copy of the old file, because eventually I'm going to remove the old functions. Probably version 1.0.9.1 or so. At that point the old file would stop working.

[MyGamesShop]

Congratulations! on this release, I got all the plugins to function (That I Use) without any issue except sloppy words cleaner had a small issue. I was nearly at my end with all the changes. So I guess I will now step up and subscribe instead of give up and go as I promised myself.

[radhavallabh]

Hi dear i am getting these errors please can you guide and help--

Warning: Use of undefined constant HTTP_CATALOG_SERVER - assumed 'HTTP_CATALOG_SERVER' (this will throw an Error in a future version of PHP) in /xx/xx/includes/modules/header_tags/ht_opensearch.php on line 69

On product page all blank in the product area and in also_purchased box it gives below error-
I know it may be because of addon but pls guide me....
Fatal error: Cannot declare class Image, because the name is already in use in /xx/xx/includes/apps/kiss_image_thumbnailer/classes/Image.php on line 23

Regds./
radhavallabh

[ecartz]

Warning: Use of undefined constant HTTP_CATALOG_SERVER - assumed 'HTTP_CATALOG_SERVER' (this will throw an Error in a future version of PHP) in /xx/xx/includes/modules/header_tags/ht_opensearch.php on line 69

I suspect that the easiest solution would be to delete

Code: Select all

HTTP_CATALOG_SERVER . DIR_WS_CATALOG . 

from line 69, so it just says

Code: Select all

          'value' => 'favicon.ico',

Try it and let me know? You also might want to leave the value blank in that code, as it may still need to be set to the full URL in order to work.

On product page all blank in the product area and in also_purchased box it gives below error-
I know it may be because of addon but pls guide me....
Fatal error: Cannot declare class Image, because the name is already in use in /xx/xx/includes/apps/kiss_image_thumbnailer/classes/Image.php on line 23

If you are using the free version of KISS IT, try asking at app.php/addons/free_addon/kissit_image_ ... er/support

If you are using the paid version, I think that support is via email. Presumably the download has documentation that says explicitly how to request support.

I would guess that either

1. It should be switched to an override class.
2. It should be namespaced.
3. It should be renamed.

Note that it is not uncommon for add-on developers to wait for a .0 version before updating.

As I said earlier in the thread, I am mostly done introducing new classes. My primary work now is updating the calling code to use the new classes directly. I can't really guarantee that I won't change the new classes, as sometimes new issues arise. But I don't plan to change them and would only do so reactively, in response to a problem. I'll probably do the rest of the modules in the next release or three. I haven't decided to what degree to break them up. I'll probably go to at least release 1.0.8.14 before 1.0.9.0. I try to avoid doing more than one release per month, so at least April (2022).

I will probably be code complete on 1.0.8.8 within the next week, leaving most of November for testing.

I have not changed the URL code significantly since 1.0.8.2. Since then, tep_href_link in catalog calls $Linker->build which uses the Href class which has the hrefLink hook. In admin, tep_href_link calls $Admin->link which calls $Linker->build. There was a minor change with 1.0.8.5, but that shouldn't have changed URL rewriting. While I can't say definitely that there will be no more changes, as I will continue to respond to problems and reports (like the one that produced the 1.0.8.5 change), I don't plan on additional changes other than to replace tep_href_link calls with the appropriate direct object method calls. Since the current code already calls the object methods indirectly, this should not affect things much. So I would consider the current version stable. Others may have their own definitions.

[radhavallabh]

Warning: Use of undefined constant HTTP_CATALOG_SERVER - assumed 'HTTP_CATALOG_SERVER' (this will throw an Error in a future version of PHP) in /xx/xx/includes/modules/header_tags/ht_opensearch.php on line 69

I suspect that the easiest solution would be to delete

Code: Select all

HTTP_CATALOG_SERVER . DIR_WS_CATALOG . 

from line 69, so it just says

Code: Select all

          'value' => 'favicon.ico',

Try it and let me know? You also might want to leave the value blank in that code, as it may still need to be set to the full URL in order to work.

The error disappeared dear;
Thank you so much

On product page all blank in the product area and in also_purchased box it gives below error-
I know it may be because of addon but pls guide me....
Fatal error: Cannot declare class Image, because the name is already in use in /xx/xx/includes/apps/kiss_image_thumbnailer/classes/Image.php on line 23

If you are using the free version of KISS IT, try asking at app.php/addons/free_addon/kissit_image_ ... er/support

If you are using the paid version, I think that support is via email. Presumably the download has documentation that says explicitly how to request support.

I would guess that either

1. It should be switched to an override class.
2. It should be namespaced.
3. It should be renamed.

Thank you dear shall move forward accordingly...

Note that it is not uncommon for add-on developers to wait for a .0 version before updating.

As I said earlier in the thread, I am mostly done introducing new classes. My primary work now is updating the calling code to use the new classes directly. I can't really guarantee that I won't change the new classes, as sometimes new issues arise. But I don't plan to change them and would only do so reactively, in response to a problem. I'll probably do the rest of the modules in the next release or three. I haven't decided to what degree to break them up. I'll probably go to at least release 1.0.8.14 before 1.0.9.0. I try to avoid doing more than one release per month, so at least April (2022).

I will probably be code complete on 1.0.8.8 within the next week, leaving most of November for testing.

I have not changed the URL code significantly since 1.0.8.2. Since then, tep_href_link in catalog calls $Linker->build which uses the Href class which has the hrefLink hook. In admin, tep_href_link calls $Admin->link which calls $Linker->build. There was a minor change with 1.0.8.5, but that shouldn't have changed URL rewriting. While I can't say definitely that there will be no more changes, as I will continue to respond to problems and reports (like the one that produced the 1.0.8.5 change), I don't plan on additional changes other than to replace tep_href_link calls with the appropriate direct object method calls. Since the current code already calls the object methods indirectly, this should not affect things much. So I would consider the current version stable. Others may have their own definitions.

Thank you so much dear for your valued detailed response-will be waiting for the 1.0.9.0 release eagerly... Sooner the better as it will help me upgrade my addons to start working.
You are the best Phoenix Team!!!!

Very warm Regds./
radhavallabh

[zipurman]

Found more issues. I will do a fresh install and see if I can reproduce there.

If I remove all shipping modules and try to checkout, all kinds of errors. I was also getting some of those errors when I had flat rate shipping enabled ... so I tried removing all and it really blows up. Could be my install as it has a bunch of hooks and custom mods, but no core edits at all.

Some of the errors:

Undefined variable: products_id in /includes/system/versioned/1.0.8.7/shopping_cart.php on line 329

array_filter() expects parameter 1 to be array, null given in /includes/system/versioned/1.0.7.4/shipping.php on line 141

count(): Parameter must be an array or an object that implements Countable in /includes/system/versioned/1.0.7.4/shipping.php on line