Payment modules in 1.7

[roja45]

Is it actually possible to make a payment module that is compatible with 1.6 and 1.7?

 

I can implement all the various hook changes, etc and so on but you need to add the namespace: 

 

use PrestaShop\PrestaShop\Core\Payment\PaymentOption;

 

to the module, which generates the error below when you try to uninstall the module in 1.6

 

( ! ) Parse error: syntax error, unexpected 'use' (T_USE) in /mnt/workspace/dev.prestashop.dev/www/classes/module/Module.php(1361) : eval()'d code on line 3

[PrestaShop] Fatal error in module file :/mnt/workspace/dev.prestashop.dev/www/classes/module/Module.php(1361) : eval()'d code:
syntax error, unexpected 'use' (T_USE)

[Krystian Podemski]

It's not possible to use namespaces within a PrestaShop 1.6

[roja45]

thanks, but that wasn't the question.

[Krystian Podemski]

 

 

Is it actually possible to make a payment module that is compatible with 1.6 and 1.7?

 

no it's not possible if you want to use a new API

[rocky]

I was told by PrestaShop that they recommend creating separate modules for PrestaShop v1.6 and PrestaShop v1.7.

[roja45]

Thanks, that would appear to be the less problematic route for making all my modules compatible with 1.7.  Might explain why there are around 1000 modules compatible with 1.7 and almost three times as many for 1.6, and also why I'm not rushing to upgrade mine, I don't so keen on doubling my workload.

[Xpert-Idea]

You have to need build module for prestashop 1.6 & prestashop 1.7 separately. You can not merge both version of code with one it.  

[roja45]

Seems that it is possible, I have a payment method now working in both 1.6 and 1.7, whether it would pass validation though is another matter.

 

The only problem I had in 1.6 was the error on uninstall with the namespace declaration, it's not actually necessary to declare the PaymentOptions namespace in the 1.7 module so long as you fully qualify the the Payment options class in the code.

 

Module seems happy in both environments now, though I haven't pushed the boundaries of what the payment can do in 1.7 yet.

[Krystian Podemski]

If you know better then why you're asking? PrestaShop 1.6 doesn't work properly with namespaces, it's not only about uninstallation but about every single aspect of reading module code by Module.php class via eval() function.

 

It's much better to keep this things separaterly especially that many changes on front-end also require modifications on PrestaShop 1.6, like not having {displayPrice} etc.

[roja45]

I was asking because I didn't know, and thought someone might already have the answer (the purpose of the forum).  I responded again because I investigated and found an answer and decided to share with the community (again, the purpose of the forum).  How you choose to design your modules is, of course, entirely up to you.

[MahmutGulerce]

First let's define the lines and diagnose

1.) 1.6 doesn't have the namespaces in 1.7 art.

2.) You can only put the "use" in first line. 

3.) Its not allowed to "use" in any logic condition such as if ( like (if _PS_VERSION_ > x)  use /A/B/C;  generates fatal error)

 

Then solve it;

(Actually it's simple though took my time)

Do not put the line starting with "use /A/B/C/" and call the class as "new /C/B/C "

For this issue the solution would be

Use 

$newOption = new PrestaShop\PrestaShop\Core\Payment\PaymentOption;

at hookPaymentOptions function instead of 

use PrestaShop\PrestaShop\Core\Payment\PaymentOption;

 

The next step will be put a version compare condition (if it's 1.6) into the hook function for redirect the function calls on 1.6 and 1.7

Summary;

So, as I said, it's simple, but it doesn't touch that "Prestashop 1.7 architecture is not legacy-friend for developers"

That's why I hate to adding new frameworks by modifying core objects.