smarterweb Posted January 9, 2023 Posted January 9, 2023 Hi all, we use a one page checkout module and after updating to 1.4 it seems some hooks now don't render html. I can see the html code instead in HOOK_SHOPPING_CART. Any idea how this is related to TB1.4? When I switch back to 1.3 everything displays correctly. Any help pointing me in the right direction would help. Thank you
datakick Posted January 9, 2023 Posted January 9, 2023 Never seen issue like that. There were no changes in hook execution/evaluation in 1.4.0. Maybe this is related to smarty library update.
smarterweb Posted January 10, 2023 Author Posted January 10, 2023 On 1/9/2023 at 8:15 PM, datakick said: Never seen issue like that. There were no changes in hook execution/evaluation in 1.4.0. Maybe this is related to smarty library update. we have this issue in quite a few places now. HTML within tpl files of hooks no longer get's rendered. Is there a way to revert back to old smarty lib without braking too much?
datakick Posted January 11, 2023 Posted January 11, 2023 I'm not really sure if your problem is caused by smarty. To replace smarty, you can download previous version of thirty bees from here https://thirtybees.com/download-specific/ , unzip it, and copy /vendor/smarty directory into your installation. That might be enough (or it will break your store). Backup the original /vendor/smarty somewhere.
smarterweb Posted January 15, 2023 Author Posted January 15, 2023 On 1/11/2023 at 8:30 PM, datakick said: I'm not really sure if your problem is caused by smarty. To replace smarty, you can download previous version of thirty bees from here https://thirtybees.com/download-specific/ , unzip it, and copy /vendor/smarty directory into your installation. That might be enough (or it will break your store). Backup the original /vendor/smarty somewhere. yes, breaks the store completely. I tried with just the lib folder but that does not solve the issues. I'm really struggling here and would like to know which changes in TB core now cause these issues. We have for example a tpl file with {$HOOK_SHOPPING_CART|escape:'html':'UTF-8':false:true} With TB 1.3 this renders perfectly fine, and in 1.4 it spits out the html code instead of the render. Any help would be appreciated.
nickz Posted January 15, 2023 Posted January 15, 2023 1 hour ago, smarterweb said: yes, breaks the store completely. I tried with just the lib folder but that does not solve the issues. Don't you work offline on localhost on your shop? To work online I suggest to rename original files and folders with whatever i.e._ and upload whatever replacement you have in mind.
smarterweb Posted January 16, 2023 Author Posted January 16, 2023 58 minutes ago, nickz said: Don't you work offline on localhost on your shop? To work online I suggest to rename original files and folders with whatever i.e._ and upload whatever replacement you have in mind. yes, of course on test environment, and did exactly as you suggested. replacing the smarty lib did not change a thing. bit baffled atm as can't figure out what is causing this with the 1.4 update
datakick Posted January 16, 2023 Posted January 16, 2023 11 hours ago, smarterweb said: yes, breaks the store completely. I tried with just the lib folder but that does not solve the issues. I'm really struggling here and would like to know which changes in TB core now cause these issues. We have for example a tpl file with {$HOOK_SHOPPING_CART|escape:'html':'UTF-8':false:true} With TB 1.3 this renders perfectly fine, and in 1.4 it spits out the html code instead of the render. Any help would be appreciated. It works as expected. Code: <div> {$html = '<a href="https://www.somewhere.com"><strong>Html</strong> code</a>'} {$html|escape:'html'} </div> The |escape:'html' part instructs smarty to escape all html characters and display them. The above smarty code would render something like this: <a href="https://www.somewhere.com"><strong>Html</strong> code</a> This is exactly what should happen. If you want to treat content of $html variable as html code, do NOT escape it. The question is why it worked for you in 1.3. It should have not. I tested this, and escaping behaved the same way in both 1.3 and 1.4. Maybe there was some override, custom smarty escape modifier, or something like that. But that doesn't matter. You should fix your templates.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now