Bug report: linking to (unknown) stylesheet breaks safe-edit

#1

Matrix Version: 5.4.5.1

I don’t know if this happens everywhere, but it did happen while I was editing a Content Container Template which is outside of the normal site architecture. I have a CSS file with the Template which I need to Link in a different place so it is publicly available. If I try to link to it in the Templates folder, it shows up on the front end as (unknown). Maybe this happens with links to other assets too, not just stylesheets.

To make the bug happen

  • I put my template paint layout in safe-edit
  • Create my new stylesheet
  • Link to it with “./?a=asset_id” before I move the stylesheet to its proper location,
  • I realised the safe edit version of the component was displaying on the live site, and was broken because the CSS was missing.
  • panicked and cancelled safe-edit - component still broken and showing safe edit version
  • went into component and committed current (original) non-broken version

Then it was fine and back to normal

Further testing shows that just by adding an (unknown) css link, the safe edit version will appear on the site, and removing the link will make it display the proper live version.

I can work around this bug now I know about it. Just thought you might not be aware of it.

(John gill) #2

I don’t know if it explains the exact behaviour you’ve described, but the usual suspect for “Odd safe edit things” with files is when they don’t have a “real” URL (i.e. /a/b/c/d.css)

This usually crops up when you have a CSS File asset under a CCT. CCTs don’t have a web path by default, so when the CSS File is in Safe Edit it only has the __data URL, instead of having both the __data URL and the “real” URL. The sole URL prevents the usual “one for the live version, one for the safe edit version” situation. The fix in the usual situation is to give the CCT a web path so the CSS File has a real URL.

Normally this manifests as seeing the Live version of the file instead of the Safe Edit version, not the other way around, but it’d be worth ruling out.

#3

Yep, that’s what seemed to be causing it - the linked file not having a URL. I just figured it was a bug that it would cause the site to go haywire instead of just ignoring the problem file.