Clearing cache link doesn't work properly in 2.6.0

[Waivor]

After updating Modx to version 2.6.0 the "clear cache" menu button doesn't work anymore. Having a closer look at the html code, the browser shows me this:

<a onclick="{literal} MODx.clearCache(); return false;{/literal} ">

Comparing this line of code with the one that is generated in the Modx version 2.5.X I guess it shoud look like this:

<a onclick="MODx.clearCache(); return false;">

[OptimusCrime]

Is there possible to create a minimal reproducable example outside of the manager with the same version of Smarty, using eval and {literal} tags? Are we 100% sure that this actually works like it should in Smarty? I tried to search for eval in the code, and as far as I could tell, this is the only place where we to this.

Like I asked earlier; is it confirmed that this works without any issues for sites created with 2.6.0 directly? Can we use the same var_dump I posted above and verify that it actually strips away the tags?

Edit: Can someone try to install 2.5.7 and then upgrade to 2.6.0 and see if this causes the problem?

[Jako]

The template paths are set here: https://github.com/modxcms/revolution/blob/a6dabd869fd426d21ae022caa651554650b6fe74/core/model/modx/modmanagercontroller.class.php#L376

Do you have different paths than /.../manager/templates/default/ set there?

[OptimusCrime]

How can I check this? The code is somewhat confusing. We are using a custom template, but only change the login template as far as I know.

Edit: I figured it out. It is because we have our own template. I though this template only used the login.tpl, but it actually contains copies of all template files. We lack the {eval val=$navb} bit from the header.tpl file.

[Jako]

Yay, that looks like it is/could be solved.

[Jako]

If I am right the default template folder is searched everytime. So if you only want to change the login.tpl, you don't have to copy the others.

@Waivor Do you work with own templates too?

[OptimusCrime]

@Jako I think you are right. I'll make the guys at the office test this and verify. Awesome work ya'll, especially you Jako :)

[Jako]

I close this now, but we should think about warning the users that use custom templates about the change.

[Waivor]

@Jako Yes and no. One of the two websites uses a custom login.tpl. Everytime I update Modx I also update the login.tpl file as well.

[OptimusCrime]

@Waivor Your custom template does not have a header.tpl file in it?

[Waivor]

@OptimusCrime It does have a header.tpl file. I copied the whole default template folder to create the custom manager login. I only changed the image (path) above the login form in login.tpl and made some adjustments in the login-min.css / login.css file.

[OptimusCrime]

That's the problem. Unless you copied the header.tpl file after you upgaded to 2.6.0, you will see the bug. The reason is that there are changes to the default template, but your template does not contain these changes, because they were copied before the change was introduced. Try to copy the header.tpl file from the default template to your template and check if that solves the problem.

[Jako]

… or remove all not changed files in that custom folder. Then MODX will use the according files in the default folder.

[alexeyp0708]

Maybe on the topic. PHP 7.1 Apache 2.4 MySql 5.6 win10 MODX revo 2.6.1 New project. Under development.

Created a plugin for FrontEnd. Hanged on the event OnWebPagePrerender. I cleared the cache with regular means. (The global cache is disabled). The plugin does not start. The problem was solved by deleting the file core \ cache \ context_settings \ web \ context.cache.php Everything worked.

In MODX revo 2.5.5 - No such problems were detected

[alexeyp0708]

I suspect that the problem is that for some reason the plugins are not started, due to the lack of information about such plug-ins in the context file in the cache.

[alexeyp0708]

I compared 2 versions 2.5.5 and 2.6.1 to the result of caching. Settings. cache_action_map = false cache_alias_map = false  cache_context_settings = true cache_db = false cache_db_expires = 0 cache_db_session = false cache_default = true cache_handler = xPDOFileCache cache_resource = true cache_scripts = true cache_system_settings = true clear_cache_refresh_trees = true syncsite_default = true use_context_resource_table = true cache_disabled = false

Operations:

1. creating the context "test".
2. creating a resource in context.
3. viewing the result to create a cache in \ core \ cache \ context_settings \ Result: 2.5.5
4. created the file - \ core \ cache \ context_settings \ context.cache.php

2.6.6

1. The file was not created - \ core \ cache \ context_settings \ context.cache.php

2 test. deleted the context.cache.php files Updated the page in the admin panel. in 2.5.5 the file was created again. in 2.6.1 the file was not created. Later I will check the result on clean installations.

[alexeyp0708]

As long as the output: the cache for "context_settings"is not created and not cleared and not updated.

[OptimusCrime]

@ALexeyP0708 How is this related to the issue here?

[alexeyp0708]

@OptimusCrime 1. Title topic: clearing the cache link does not work properly in 2.6.0

2. And in the file cache \ context_settings \ context.cache.php, there is a cache of installed plugins and their connection with the events. Maybe as an option to analyze it to solve problems in the topic. I described the problem that I had.
3. But if my post do not in the topic, then I will not waste any more time. ))

[OptimusCrime]

@ALexeyP0708 I think the root cause of your problem is not connected to the original issue posted here. If you still experience problems, I suggest opening a new issue and follow the provided template.