Describe the bug
Using the sprintf function in non-native module templates causes an error depending on how the string is contructed.
Multiple bugs here.
1.75 templates using this function no longer work,
Using this format
{l s='%s available' mod='roja45productrental' sprintf=['$model.availability]}
resultant string is corrupted in 1.7.6 whereas it is correctly displayed in 1.7.5.
Using this format, as templates in 1.7.6 seem to use:
{l s='%qty% available' mod='roja45productrental' sprintf=['%qty%' => $model.availability]}
This string template contruction works:
{l s='%qty% available' mod='roja45productrental' sprintf=['%qty%' => $model.availability]}
This string template does not,
{l s='Collection After: %collect%' mod='roja45productrental' sprintf=['%collect%'=>$rental_product->collection_time]}
The position of the %xxx% is causing the error. One is matched by the regex used in checkAndReplaceArgs in Translate.php, the other is not, so they follow different string replacement paths in the code.
Update the template to use
To Reproduce
As described
Screenshots
If applicable, add screenshots or screenrecords to help explain your problem.
Additional information
PrestaShop version: N/A
PHP version: N/A
Hi @roja45,
Thanks for your report.
Could you please provide me a demo module to test it.
Thanks!
nope, there's sufficient information there for you to test the software correctly. I have to update all my modules to work around this.
@roja45, I did not manage to reproduce the issue with PS1.7.6.0.
I tried with this module
translationbug.zip
In my tpl file, I have this
{block name='title'}{l s='1 Hello %1$s!' sprintf=[$test] mod='translationbug'}{/block}
{block name='content'}{l s='%s My original content 2 ' mod='translationbug' sprintf=[$test2]}
{l s='3 Collection After: %collect%' mod='translationbug' sprintf=['%collect%'=>$test]}
{l s='%qty% available 4' mod='translationbug' sprintf=['%qty%' => $test]}
{l s='%s available 5' mod='translationbug' sprintf=[$test]}
{/block}
In BO => All expressions are well displayed
Thanks to check & feedback.
Hi @khouloudbelguith,
Yes, I can see that yours is working. I'm trying to track down the cause, you can see in the screenshot my translation failing alongside yours that is working.
Will get back to you.
Thanks
@roja45, thanks!
Waiting for your feedback.
Hmm, bit tricky to explain this one, I can recreate the issue with your module
The problem lies in: \classes\Translate.php
When translating my text above, that gets corrupted, it is dropping into block 1, in the screenshot above becuase the $_MODULES variable is 0 in size (though not null).
This translates the text correctly, though I'm not sure what this block is doing as the return ret variable is never used.
In then drops into block #2 in the screenshot, and translates a second time, this corrupts the string.
In your module, it does not drop into the block #1 as the $_MODULES variable is not empty, screenshot below.
This is because in your module you provide an en.php translation file, but in my module the english translation is in the template, and I provide translation files for the additional languages.
If you delete the en.php in your module, you will see the error.
This is the result if I comment out that 1st block in the above code screenshot, I don't think that code needs to be there.
Does that make sense!? :-)
@roja45, I deleted the en.php file & it is OK.
I attached a screen record
https://drive.google.com/file/d/1EOrLBZQJxhHemkDPPRgDAVBnjnRtfSbS/view
Thanks!
The issue is with front office translations.
An updated version of your module is attached, it just includes a front office hook for the product page.
@roja45, I checked the module provided.
But, there are no front office translations.
I attached a screen record
https://drive.google.com/file/d/1jqAvRIaYG_E9__VPiCUc2u0D2XwTw34h/view
Thanks to check & feedback.
erm, can't answer that one. Try transplanting it to the displayProductAdditionalInfo hook, it's there in the code. The module hook process is not without it's own issues.
@roja45, thanks for your feedback.
Yes, now I manage to reproduce the issue PS1.7.6.0.
In the FO, I have this
With PS1.7.5.2, it is OK
I鈥檒l add this to the debug roadmap so that it鈥檚 fixed. If you have already fixed it on your end or if you think you can do it, please do send us a pull request!
Thanks!
@khouloudbelguith Ok, cool. Yes, I can create a pull request. As noted above, I don't think that the code that is causing the issue is doing anything useful, so can be removed.
Most helpful comment
@khouloudbelguith Ok, cool. Yes, I can create a pull request. As noted above, I don't think that the code that is causing the issue is doing anything useful, so can be removed.