custom css code escapes

[smarterweb]

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.

[Traumflug]

That's disappointing. Filed as a bug here: https://github.com/thirtybees/thirtybees/issues/880

[LucaSabatoUK]

Tb 1.0.8 updated from a fresh install of tb1.0.7 with warehouse theme I have the same issue:

On the theme module when I try to update the CSS code form this :

 

after I save the code change to :

 

any idea?

[wakabayashi]

@LucaSabatoUK probably this is just not working as it should. But its very good that you confirm the issue, that helps the developers.

[LucaSabatoUK]

the solution of this problem can be found here: 

I have sorted the issue by manually upload this file https://raw.githubusercontent.com/thirtybees/thirtybees/1.0.x/classes/Configuration.php

 

Now the code looks like 

Edited March 21, 2019 by LucaSabatoUK

[smarterweb]

@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.

[datakick]

1 hour ago, smarterweb said:

@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.

Should be fixed now

[smarterweb]

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...

[datakick]

1 minute ago, smarterweb said:

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...

The core updater **DOES NOT** work against thirtybees git repository. That's because tb repository contains source code, but core updater needs *compiled* code.

I know... in php there is no such thing as compiled code. But there is a build process. To put it simply - if you were to download code from tb repository and uploaded it to your server, it would not work. You need to build it first.

So there is another (private) repository, which contains *compiled* code -- result of build process. Core updater communicates with this repository.

The problem is that there is not yet any automated mechanism to build thirtybees git repository and publish it to private repo. This is done by hand at the moment, and that's the reason why you don't see the changes very often. This automation is under construction, though, so very soon this will be solved, and Bleeding edge will truly bleed 🙂

BTW, I've just updated the private repo, so you should be able to update to *new* bleeding edge

[smarterweb]

5 minutes ago, datakick said:

The core updater **DOES NOT** work against thirtybees git repository. That's because tb repository contains source code, but core updater needs *compiled* code.

I know... in php there is no such thing as compiled code. But there is a build process. To put it simply - if you were to download code from tb repository and uploaded it to your server, it would not work. You need to build it first.

So there is another (private) repository, which contains *compiled* code -- result of build process. Core updater communicates with this repository.

The problem is that there is not yet any automated mechanism to build thirtybees git repository and publish it to private repo. This is done by hand at the moment, and that's the reason why you don't see the changes very often. This automation is under construction, though, so very soon this will be solved, and Bleeding edge will truly bleed 🙂

BTW, I've just updated the private repo, so you should be able to update to *new* bleeding edge

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

[smarterweb]

@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....

[datakick]

8 hours ago, smarterweb said:

@datakick just updated to the latest bleeding edge, but now we have a 500:

Where do you get this error? I've just updated my demo account to bleeding edge, and it works ok for me, so I'm not sure where the problem might be.

[smarterweb]

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.

Edited March 25, 2019 by smarterweb

[datakick]

@smarterweb have you also cleaned cache? Even if you have all cache disabled, smarty can still compile and cache templates in /cache/smarty directory. (btw, you can safely delete this directory using ftp / ssh)

[smarterweb]

33 minutes ago, datakick said:

@smarterweb have you also cleaned cache? Even if you have all cache disabled, smarty can still compile and cache templates in /cache/smarty directory. (btw, you can safely delete this directory using ftp / ssh)

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

[datakick]

31 minutes ago, smarterweb said:

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

That's not good, we should definitely find out root cause for this problem, so it won't get into the next release. Unfortunately I can't reproduce it locally, so it's probably caused by some module / theme interference (which does not mean that module / theme is the culprit, they may just use the system in a way that triggers this error).

Has anyone else encountered similar problem(s) on bleeding edge?

[smarterweb]

14 hours ago, datakick said:

That's not good, we should definitely find out root cause for this problem, so it won't get into the next release. Unfortunately I can't reproduce it locally, so it's probably caused by some module / theme interference (which does not mean that module / theme is the culprit, they may just use the system in a way that triggers this error).

Has anyone else encountered similar problem(s) on bleeding edge?

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.

[datakick]

6 hours ago, smarterweb said:

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.

Most certainly not. If there's a bug, it's been introduced sometime between Jan 21 - Mar 21.

You never answered my question - where did you encounter this problem? Was it on front end? One page / every pages? Have you tried disabling non-thirtybees modules?

[smarterweb]

1 hour ago, datakick said:

Most certainly not. If there's a bug, it's been introduced sometime between Jan 21 - Mar 21.

You never answered my question - where did you encounter this problem? Was it on front end? One page / every pages? Have you tried disabling non-thirtybees modules?

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?

[smarterweb]

@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.

[datakick]

@smarterweb, I've just tested the functionality (Preferences > Custom Code > Add CSS) on 1.1.0 and it works correctly even for your code snippet.

This is either problem in your Theme Editor module, or in some override in your system.

[Pedalman]

.

Edited August 9, 2019 by Pedalman