CSS templates are synchronized only when visiting CP -> Templates

[bytebaby]

Summary: If I edit the style.css in the template folder ("/templates/default_site/mydirectory/de/style.css") remotely via FTP/SFTP, the changes are no longer transmitted/displayed after a (hard) reload .

When I load the "style.css" file from the template folder with my CSS editor "Nova" and make changes, the browser does not accept these changes. It doesn't matter whether I work on my provider's server or with my local web server (MAMP).

But if I open the CSS file in the EE backend with the template editor (only open it, don't even save it), then I see the changes and suddenly the browser also shows them (this applies to Chrome, Firefox, Safari and the caches I had deactivated, template caching is also deactivated).

Another note: I have upgraded to EE 6.3.2 for two customers and the problem occurs there too.
I changed the style.css via editor for a customer with EE 6.2.7. The changes were immediately visible online in the "page source code" of the browser. After that I updated this website to EE 6.3.2. After that I had the same problem: ExpressionEngine doesn't propagate the CSS changes to the browser. Even if I use a different editor, a different Mac computer or a different IP.

Now I have no choice but to reference the CSS file directly from another directory in the root (so not from "user/templates/etc"). Then everything works as usual again.

PHP 7.4
MySQL 5.7.37
EE 6.3.2 and 6.3.3
Editor: Nova from Panic

[intoeetive]

@bytebaby Looking at the sample folder structure you provided, it does not look right to me.

It should be something like templates/default_site/mydirectory.group/style.css. An extra level of /de will not be recognized by EE.

I would also double check your config.php to contain $config['save_tmpl_files'] = 'y';

If you can confirm that,

[bytebaby]

The direcotory "en" is a simple template group folder like "Products" or "Services". The index.html and style.css for the start page are in the "de" directory, which has always worked without problems over the years. :)

The $config['save_tmpl_files'] = 'y' option was missing in config.php;
I inserted them to test, but unfortunately the problem persists.

But isn't it remarkable? As soon as I log into the backend and ONLY click on the "Templates" menu item, the change is transferred to the browser when the website is called up

[intoeetive]

Ok, so can you confirm I understand you correctly:

• if you make changes to files for web pages templates, the changes are reflected in browser immediately
• if you make changes to files for CSS templates, the changes are displayed only after you visit the appropriate section of Control Panel

[bytebaby]

It is exactly like that.

[robsonsobral]

I gonna take a look on that.

---

I didn't known templates 2 levels down on groups are supported.

[robsonsobral]

Please, @bytebaby , help me here.

Does the structure of the directories of templates looks like this?

/templates
    /default_site
        /mydirectory.group
            /de.group
                /style.css

Is /de.group the only nested group you have?

[bytebaby]

Not quite. I see only now, there is a mistake, sorry. Correct

/templates
/segert-tmps <- instead of default_site
/de.group
/style.css

[robsonsobral]

Thank you!

One more thing. What do you mean by this?

Now I have no choice but to reference the CSS file directly from another directory in the root (so not from "user/templates/etc"). Then everything works as usual again.

How this new arrangement looks like, please?

[bytebaby]

With pleasure.
That means: not referencing the style.css via the template group, but via a directory in the root (/css):

<link rel="stylesheet" href="https://mydomain.com/css/style.css" media="screen" />

I hope I could help :)

[robsonsobral]

Sooooooo... de.group is the main group, the one which stores the site homepage, and to call for the css only by its name used to work, but not anymore. Is it?

[bytebaby]

Yes, it worked like this for 9 years.

[robsonsobral]

Summarizing, the file is loaded and served, but using the link without the main group doesn't trigger the update from the file.

@bytebaby , in case the group is named anything else than css, let's say foobar.group:

• the file is served?
• the file served is updated from the edited on disk version?

(Please, forgive all these questions! I'm trying to narrow down the scope of the tests I need to do.)

[robsonsobral]

@bytebaby , I did some tests. We are talking about 2 things here:

1. the CSS file could be served from the default group using only the first segment;
2. the file isn't updated from the disk on request, which is a bug I find by myself many times on previous versions.

The first

Testing whether the file news.group/foobar.css is served, being news.group the default group.

	strict URLs	no strict URLs
http://localhost/index.php?/foobar.css	no	no
http://localhost/index.php?/foobar	no	yes
http://localhost/index.php?/news/foobar.css	no	no
http://localhost/index.php?/news/foobar	yes	yes

Everything as it should, by the documentation.

I think you used an undocumented bug as a feature, which disappeared at some point between versions 6.2.7 and 6.3.2. You can "reenable" it by disabling the Strict URLs setting, what I don't recommend. From the docs:

Our official recommendation is that users enable Strict URLs, as doing so makes the path to your content more precise, allows more relevant 404 pages, and does not allow your content to be shown with variances in the URL structure. However, for legacy reasons, Strict URLs are disabled by default.

Can you, please, test opening the CSS files and changing the Strict URL setting? You don't even need to edit your site. Just change the setting and call the same URL you use on the href attribute, as I understood you aren't using the {stylesheet} variable.

Also, keep in mind that you can't have a group called css.group. A /css segment will always serve the requested file as text/css

The second

I couldn't replicate the saving issue on the last version, 6.34, but I'll do more tests. Actually, I've found that the header last-modified is being more updated than it should. Hmmmmmmnnnn... 👀

[bytebaby]

I tried the following. Template group "news" set as default group and converted the style.css to foobar.css. In the source code, the line looks like this (regardless of whether strict URLs are enabled or disabled):

https://mydomain.com/?css=news/foobar

Result: The CSS file is no longer loaded. Only the bare markup is displayed in the browser :)

If I convert foobar.css back to style.css, the CSS file is loaded again and appears in the source code:

https://mydomain.com/?css=news/style.v.1651906541

However, the problem persists even if I disable strict URLs.

I'm not sure if I could help. I would like to do that. Thank you for your work! :)

The bug also persists with the update to EE 6.3.4

[robsonsobral]

So, you're using the {stylesheet} variable! Can you show me this line of your code, please? The old and the new line, please.

(I can't understand the reason it stopped to work just by renaming the file. Hmmmmmnnnn...)

[bytebaby]

Sorry, I guess I wasn't fully awake yet :)
It also works with a filename like foobar:

<link href="{stylesheet=de/style}" type="text/css" rel="stylesheet">
or
<link href="{stylesheet=en/foobar}" type="text/css" rel="stylesheet">

One of these lines is contained in
includes.group/head.html

(I'm trying it out on the live system of my site segert.net ;)

[robsonsobral]

I guess I know what happened. Please, look for me in the Slack Channel. Let's move this conversation before all the devs go crazy.

[robsonsobral]

I misunderstood what happened here. The problem 1 doesn't exist:

@bytebaby , I did some tests. We are talking about 2 things here:

1. the CSS file could be served from the default group using only the first segment;
2. the file isn't updated from the disk on request, which is a bug I find by myself many times on previous versions.

I couldn't reproduce the second.

I'm sorry.

[robsonsobral]

Bug found! Working on it!

[robsonsobral]

@bytebaby , can you, please, give this PR a try? It fixes a bug I found while trying to help you. However, I'm not sure the bug you found is the same I found.

[bytebaby]

@robsonsobral – I'm not on Github very often, what does "PR" mean? –
That's exactly the bug! :) And if your solution is implemented in the next EE update, I will start a test immediately. Or can I test it beforehand?

[robsonsobral]

I'm not on Github very often, what does "PR" mean? –

From Github docs:

Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

---

That's exactly the bug! :) And if your solution is implemented in the next EE update, I will start a test immediately. Or can I test it beforehand?

You can test right now and I need you to do it!

I ask that you, please, backup and replace the file system/ee/ExpressionEngine/Library/Resource/Request.php by the version available at the Pull Request number #2075 .

Thank you for your patience and help.

[bytebaby]

I'm sorry, but unfortunately it still doesn't work. See the short screencast below:

https://download.segert.net/eebug.mp4
ID: kunden
PW: kunden

I could set up temporary FTP and admin access for you.

[robsonsobral]

You're using the same version suffix, @bytebaby . After you update the file, is the link generated by the {stylesheet} the same?! Please, check.

[robsonsobral]

@bytebaby , wait for a new testing version soon!

[robsonsobral]

Done, @bytebaby !

[bytebaby]

You're using the same version suffix, @bytebaby . After you update the file, is the link generated by the {stylesheet} the same?! Please, check.

Yes.
In the Template:
<link href="{stylesheet=de/style}" type="text/css" rel="stylesheet" media="screen">
Source-Code:
<link href="https://mydomain.net/?css=de/style.v.1652209588" type="text/css" rel="stylesheet" media="screen">

[robsonsobral]

Thank you, @bytebaby , for reporting this. While I tried to reproduce this bug, I found some edge cases. The code is now more robust and the tests cover more situations.