Permalink
Browse files

Rephrasing

  • Loading branch information...
eternoendless committed Dec 7, 2018
1 parent 5bfbedc commit 8744f985c198732cc84385ff694e73e803419b05
Showing with 15 additions and 16 deletions.
  1. +15 −16 src/content/1.7/modules/core_updates/1.7.5.md
@@ -3,8 +3,7 @@ title: Changes in PrestaShop 1.7.5
menuTitle: Changes in 1.7.5
---

Notable changes in PrestaShop 1.7.5
=======
# Notable changes in PrestaShop 1.7.5

## LazyArrays

@@ -14,7 +13,7 @@ They used to be `arrays` with all the data available. This change has been intro

Getting properties from the object should not change between first versions of PS 1.7 and 1.7.5.

However it appeared that some modules, especially the ones with a high compatibility range like PrestaShop 1.6 & 1.7, apply an array cast when the variable in not an array. **Casting these variables as arrays on PS 1.7.5+ will throw notices when getting their properties.**
However it appeared that some modules, especially the ones with a large compatibility range like PrestaShop 1.6 & 1.7, apply an array cast when the variable in not an array. **Casting these variables as arrays on PS 1.7.5+ will throw notices when getting their properties.**


| | 1.6 | 1.7.0+ | 1.7.5+ |
@@ -28,13 +27,13 @@ Applying an `(array)` cast is valid only when you have a `ObjectModel` instance,
public function hookdisplayFooterProduct($params)
{
/*
* Depending on the PrestaShop you run, the $product type won't be the same.
* On PrestaShop 1.7, it can be directly used as an array.
*
* However, if the module is also compatible with PrestaShop 1.6, 1.5...
* an ObjectModel class will be returned.
* Casting it as an array *in this specific situation* will allow to cover all cases.
*/
* Depending on the PrestaShop you run, the $product type won't be the same.
* On PrestaShop 1.7, it can be directly used as an array.
*
* However, if the module is also compatible with PrestaShop 1.6, 1.5...
* an ObjectModel class will be returned.
* Casting it as an array *in this specific situation* will allow to cover all cases.
*/
$product = $params['product'];
if ($product instanceof Product /* or ObjectModel */) {
$product = (array) $product;
@@ -49,11 +48,11 @@ public function hookdisplayFooterProduct($params)

* [Related issue on module Google Analytics (GitHub)](https://github.com/PrestaShop/ps_googleanalytics/pull/14/files)

## About getAdminLink and _legacy_link
## Automated link generation

The 1.7.5 version offers a conversion from legacy links to new migrated Symfony pages. Meaning if you use the `Link::getAdminLink` method somewhere in your modules to access a page that has been migrated, PrestaShop automatically converts it to the new Symfony migrated url.
PrestaShop now automatically converts links generated by `Link::getAdminLink()` calls into links to the newly migrated Symfony pages. This means that if you used this method somewhere in your modules to link to a page that has since been migrated, PrestaShop will automatically "upgrade" it so that it points to the new Symfony-style URL.

This prevents module developer to update their links each time a page has been migrated. However in many places the method is not used with the url parameters as arguments. Parameters are concatenated after the getAdminLink call. This can result in wrong conversion use cases, so you might need to refactor the way you use this method.
With this change, module developers no longer need to update their links each time a page is migrated. However in many places the method is not used with URL parameters as arguments, and parameters are concatenated as a string after the `getAdminLink` call instead. This can result in wrong conversion use cases, so you might need to refactor the way you use this method.

Example:

@@ -64,12 +63,12 @@ Example:
// Recommended code from PrestaShop 1.7.5
$link->getAdminLink('AdminOrders', true, [], ['id_customer' => $customer->id|intval, 'viewcustomer' => 1]);
// If you need to be compatible from 1.5 to the latest 1.7 version, then you can combine both writing:
// If you need to be compatible from 1.5 to the latest 1.7 version, then you can combine both styles
$link->getAdminLink('AdminOrders', true, [], ['id_customer' => $customer->id|intval, 'viewcustomer' => 1]) . '&id_order={$order->id|intval}&vieworder';
```

Although this won't be a problem for legacy controllers, the generated link won't work any more if it is not used properly once migrated to Symfony. So we advice you to refactor your call to `getAdminLink` beforehand.
Although this won't be a problem for legacy controllers, if it's not used properly, the generated link won't work anymore once the page is migrated to Symfony. We recommend refactoring your calls to `getAdminLink` beforehand.

You can find more details about this new feature in the [Controller and Routing][controller-routing] page.

[controller-routing]: {{< relref "1.7/development/architecture/migration-guide/controller-routing.md#more-about-the-legacy-link-property" >}}
[controller-routing]: {{< ref "/1.7/development/architecture/migration-guide/controller-routing.md#the-legacy-link-property" >}}

0 comments on commit 8744f98

Please sign in to comment.