smarterweb

as reported here: https://github.com/thirtybees/thirtybees/issues/1016 we now had to revert back to 1.0.8 (which was easy thanks to the new core updater) If you have a multistore environment, there's some rather serious issues still and we will have to wait until they are fixed. all reported in git, just wanted to make aware of this in the forum as well. Guest checkout issue: https://github.com/thirtybees/thirtybees/issues/1015 Password masking issue: https://github.com/thirtybees/thirtybees/issues/1014 I hope these can be resolved quickly, so that we can finally update to 1.1.0 Thanks

sorry just double checking: you did clear your TB cache, right?

but was IS the error in your case?

so what's the error you see when you switch on error reporting?

sure thing, here you go. don't forget to clear cache 🙂 order-carrier.tpl

yes, working fine with warehouse theme, however you need to alter the file order-carrier.tpl around line 82 from {if $option.unique_carrier} {foreach $option.carrier_list as $carrier} <strong>{$carrier.instance->name|escape:'htmlall':'UTF-8'}</strong> {/foreach} {if isset($carrier.instance->delay[$cookie->id_lang])} <br />{l s='Delivery time:'}&nbsp;{$carrier.instance->delay[$cookie->id_lang]|escape:'htmlall':'UTF-8'} {/if} {/if} to {if $option.unique_carrier} {foreach $option.carrier_list as $carrier} <strong>{$carrier.instance->name|escape:'htmlall':'UTF-8'}</strong> {if isset($carrier.instance->delay[$cookie->id_lang])} <br />{l s='Delivery time:'}&nbsp;{$carrier.instance->delay[$cookie->id_lang]|escape:'htmlall':'UTF-8'} {/if} {/foreach} {/if} If you are using the OPC checkout process. Otherwise you face the error 500 (this might be the same problem in the Panda theme...)

Despite some people ranting about KnowBand, I personally found their support to be outstanding and yes they always fixed issues for us in a timely manner and even did some customisation for free. Agree we should get them onboard as their modules are really good (mostly...). Most of their modules work out of the box with TB anyway.

ok, I replaced your attached file but the error remains the same. cleared cache and all of course.... We are using a different version of that file, but I found the foreach loop and replaced your code, but it's still giving us the same error. So we can't update to 1.1 unfortunately (I know it's a bug in the module, so will have to wait until knowband provides a fix)

@datakick This is probably related to new version of smarty. Similar problem was in community theme / niara, and it was fixed by simply moving the block of code to the proper place. If you send me the module, I can fix it for you @datakick Can you possibly post the fix for the supercheckout module here as we are having the same issue? I think there are still many people who use this module and if TB 1.1. breaks the checkout module like this we are having a bit of an issue I guess...

@datakick I have just updated to the latest stable 1.1 and the issue with stripping slashes in my warehouse theme editor has been reintroduced. recap: paste some custom CSS into the theme editor like this: span.cart_name:before { content: "\f291"; } it now strips all my line breaks and backslahes and I get: span.cart_name:before { content: "f291";} Git created here: https://github.com/thirtybees/thirtybees/issues/880 And apparently fixed here: https://github.com/thirtybees/thirtybees/commit/bdb04ce186c13bc60b3f2fbd6805d88cf349a738 So not sure why this coming back now.

ok, so done a bit more testing and to answer your questions: yes it was in the front end only and related to the warehouse theme module "content creator". Once I switch this off, it's all working as expected. Of course now the question is why did it break with the latest bleeding edge version?

so the issue must have been introduced after you updated the private repo. I did use the updater to bleeding edge before that and it worked fine.

yes, cache cleaned, and there are no files in cache folders at all. after downgrade to 1.0.8 all works as expected again

ThirtyBeesException Allowed memory size of 536870912 bytes exhausted (tried to allocate 536870920 bytes) in file vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php at line 62 Source file: vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php 43: if ($parent === null && ($this instanceof Smarty || is_string($template))) { 44: $parent = $this; 45: } 46: // create template object if necessary 47: $_template = ($template instanceof $this->template_class) 48: ? $template 49: : $this->smarty->createTemplate($template, $cache_id, $compile_id, $parent, false); 50: // if called by Smarty object make sure we use current caching status 51: if ($this instanceof Smarty) { 52: $_template->caching = $this->caching; 53: } 54: // merge all variable scopes into template 55: if ($merge_tpl_vars) { 56: // save local variables 57: $save_tpl_vars = $_template->tpl_vars; 58: $save_config_vars = $_template->config_vars; 59: $ptr_array = array($_template); 60: $ptr = $_template; 61: while (isset($ptr->parent)) { 62: $ptr_array[] = $ptr = $ptr->parent; 63: } 64: $ptr_array = array_reverse($ptr_array); 65: $parent_ptr = reset($ptr_array); 66: $tpl_vars = $parent_ptr->tpl_vars; 67: $config_vars = $parent_ptr->config_vars; 68: while ($parent_ptr = next($ptr_array)) { 69: if (!empty($parent_ptr->tpl_vars)) { 70: $tpl_vars = array_merge($tpl_vars, $parent_ptr->tpl_vars); 71: } 72: if (!empty($parent_ptr->config_vars)) { Of course, all cache disable, also tried switching to default theme, but same issue.

@datakick just updated to the latest bleeding edge, but now we have a 500: ThirtyBeesException Allowed memory size of 1073741824 bytes exhausted (tried to allocate 1073741832 bytes) in file vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php at line 62 I've assigned 1024MB of memory and it's still not enough? Something has gone wrong here....

awesome, thanks for the explanation and hope to see the automated feature soon (alongside the release of 1.0.9 )

great, thanks! question on th side: how do I update from bleeding edge to like latest bleeding edge? I ran the core updater but since we are already on bleeding, it doesn't seem to apply latest commits. maybe I'm missing something...

@LucaSabatoUK your solution may fix the warehouse theme issue, but not the issue I reported in my initial post - so you may want to make this very clear for others. I am talking about the built-in custom code which still strips backslashes, even in the latest bleeding edge version.

We've been on the OC-train for years and every time I have to update any TB site, it makes me giggle. Reason being: It's just so easy and simple updating TB and doesn't break my modules and only takes about 10min of my time (max, including creating the obvious backup). I remember trying to update (I'm not talking about an upgrade here.... just a simple update of minor core version) OpenCart and always got frustrated and sometimes ended up doing a complete fresh install, including all extensions, then migrating the DB after having spent countless hours on their forum. ThirtyBees delivers, is easy, stable, works out of the box, and is compatible with most PS extension. On top of that you have fast responses from the devs and a great community. It's a no brainer really...

There's still an issue in latest bleeding edge with escaping custom code: If you put: .footer-title section-title-footer:before { content: "\f002"; } into "Add extra css to your pages", it strips my escape so it looks like: .footer-title section-title-footer:before { content: "f002"; } After saving.

in the official PS paypal module all that information is passed on to paypal, so users don't have to fill out another form with the exact same details (address).

Not sure if this is country related (there used to be different official PS paypal modules for uk and usa) but in this latest version, address details do no longer get passed on to the paypal website when using PP standard method. We're based in New Zealand and used to have to install the UK version.

maybe more an enhancement, but could be considered a bug too: When you enable B2B mode in one specific shop (multistore mode), some controllers seem to pull the wrong info from the table "configuration" or it doesn't work as expected. Let me explain: When you enable B2B for store 1 and disable B2B for store 2, then for example in admin->customers, there is no extra column for "company" when in store 1. If I look at AdminCustomersController.php, I can see around line 114: if (Configuration::get('PS_B2B_ENABLE')) { $this->fields_list = array_merge( $this->fields_list, [ 'company' => [ 'title' => $this->l('Company'), ], ] ); } This would mean that if the B2B mode for this shop is enabled, it should show the extra column. If I change both stores to B2B then we can see the extra column. But really the configuration pulled from that table should apply only to the selected store. I have checked that DB table and can see both values for both stores, not sure why it's not working.

logs are empty. can you reset the module without issues? I will install an older version (before 5.4) and see if that still works... tried uninstalling, get the same error

tried both php 7.0 and 7.1 - same issue