Site broken after upgrade to Grav 1.7 (most of the generated HTML inside double quotes)

1

Since I upgraded my website to Grav 1.7, a lot of the HTML generated is surrounded by double quotes.

It looks like this:
<link href=“https://maxcdn.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css” type=“text/css” rel=“stylesheet”>
<link href=“https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css” type=“text/css” rel=“stylesheet”>
<link href="/grav-admin/user/themes/base/css/base.css" type=“text/css” rel=“stylesheet”>
<link href="/grav-admin/user/themes/base/css/menu.css" type=“text/css” rel=“stylesheet”>
…

This of course breaks all the website, so I did not update live.

I tried disabling the cache, all plugins, disabling CSS and JS pipelines, and a few settings in system.yaml. Nothing fixed it.

Any reason for that?

2

@mathmax, The code you are showing looks perfectly valid to me… :wink:

Did you perhaps mean to show the following?

<body id="top" class=" page_home">
  &lt;link href="https://maxcdn.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" type="text/css" rel="stylesheet"&gt;
  &lt;link href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" type="text/css" rel="stylesheet"&gt;
  &lt;link href="/grav-admin/user/themes/base/css/base.css" type="text/css" rel="stylesheet"&gt;
  &lt;link href="/grav-admin/user/themes/base/css/menu.css" type="text/css" rel="stylesheet"&gt;
....

Question:

  • Did you search the forum for issues on upgrading to Grav 1.7?
  • Did you read the upgrade to Grav 1.7 documentation for breaking changes?
    Yes I agree, 1.7 should be named 2.0, because minor upgrades are generally considered to be non-breaking…
3

Thank you for you reply. And sorry for the wrong copy paste.

I feel ashamed because I read that section before upgrading and remembered about the auto-escaping thing, but I thought that since I will do an automatic upgrade, it would not be an issue. The page says:

and if you are upgrading from a version prior to 1.7, we automatically enable Twig Compatibility setting in the system configuration to ensure your old Twig code will continue to function.

But this was not functioning despite I did the upgrade through the admin panel.

After that I made a manual installation, and the problem was the same. I even remembered about that attribute which I confirmed to be false.

After you indicated the page again, I checked the details in the twig section and found out that

strict_mode:
  twig_compat: true

should also be added. This solved the issue! Thanks a lot!

4

@mathmax , If you did an upgrade by Admin or $ bin/gpm selfupgrade it should fix the autoescape issue.

If it didn’t, depending on how you did the upgrade, I would either file an issue on the repo of Admin plugin, or at Grav repo itself.

5

I am sure the upgrade by Admin did not fix the autoescape issue automatically.
I upgraded from the 1.6.28, not the latest version… could this cause a problem?
I found also that the cache should be refreshed for the whole website otherwise some sections would still display HTML as code… maybe Grav should always force refresh the cache after the upgrade?
I could try run again the upgrade from the admin on a local copy…

Btw, the doc mentions that autoescaping is a security improvements, so instead of just disabling it for backward compatibility, I was wondering if there is something I should change in my code in order to implement it correctly.

6

@mathmax, Yes, it is a security measure and the best approach is to go through the theme’s templates and add the |raw filter to outputs that can be trusted. Or ask the developer of the theme to make it 1.7 compatible.

See my answer to a similar topic.

Changes in config files should normally trigger a refresh of the cache. If templates change a manual refresh is required.

7

Ok. Pretty much all my {{}} in the template files will have a |raw filter. Does that make sense?
In that case, why the {{}} operator itself doesn’t apply the filter automatically?

8

@mathmax,

Does that make sense?

No that does not make sense, because that will be the same as adding the ‘compatibility’ properties and defies the security measure…

In that case, why the {{}} operator itself doesn’t apply the filter automatically?

Maybe a misunderstanding:
Escaping prevents malicious code to be evaluated and is added to every {{}} when autoescape: true. Filter |raw overrides the escaping and tells Twig ‘trust me, it’s save’.

Only values that will break the site when escaped should get filter |raw applied. E.g.:

  • {{ page.content|raw }}
  • {{ assets.css()|raw }}
  • {{ assets.js()|raw }}

An escaped {{ page.title }} will not break the site.

Have a look the templates of Grav to get an idea.

9

Got it! Thank you for the explanation!