1.0.8.7 Questions / Comments / Concerns
Posted: Fri Oct 29, 2021 3:19 pm
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.
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.
