10

I'm troubleshooting a Session Preview issue in Experience Manager for an ASP.NET training site (IIS 7.5).

Setup:

  • Site.Master includes: <link rel="stylesheet" type="text/css" href="styles1.css" />
  • CSS is managed as a code component as a CP on a Tridion Page.
  • Session Preview serves the wrong MIME type.
  • No error if CSS is on the file system.

Behavior:

  • Session Preview works in Chrome and Firefox, however the page in **IE 10 (Standards mode) lacks styles.
  • Console shows:

SEC7113: CSS was ignored due to mime type mismatch styles1.css

Background and attempted fixes:

How do I make this setup work?

Update 1: viewing the CSS in IE directly opens the file, but gives:

HTML1527: DOCTYPE expected. The shortest valid doctype is "<!DOCTYPE html>". styles1.css, line 1 character 1

Update 2: Moving the CMS site in the browser to the recommended Local Intranet zone and following the docs accidentally turned on Compatibility Mode. IE 10 loses focus after logging in.

Improve this question
2
  • What happens if you take your CSS files out of Tridion and host them on the server just like the last one? Also, does your site work when not in Session Preview mode?
    – Nickoli Roussakov
    Jul 25, 2013 at 0:36
  • Good questions. I just checked by copying and referencing the Tridion-managed CSS "pages" as files outside Tridion and they are delivered correctly. Some type of browser detection would work as a hack then. The published files work fine outside of Session Preview. The staging page references the staging CSS as normal in that case.
    – Alvin Reyes
    Jul 25, 2013 at 1:37

5 Answers 5

Reset to default
9

Session Preview works off the Session Preview Broker DB and inherently through the Session Preview Odata service.

Despite your "code" components being regular CPs on a regular statically published page, when in Session Preview mode pages and CPs go to the session preview broker db and get served up via odata.

So you should check the mime type settings of your session preview odata website.

Improve this answer
4
  • That makes sense. Would that be the Content Delivery Endpoint URL (Staging publication target's Session Preview tab)? IIS shows the site has a MIME Types setting of .css as text/css. I'll double check the web.config. Do pages also get served this way?
    – Alvin Reyes
    Jul 25, 2013 at 1:49
  • Yes, in Session Preview everything magically becomes dynamic including pages. I suspect the issue could be with how the page gets serialized to be served. As per SDLLiveContent (soz I don't have the link handy), the odata web service has special handling of mime types for binaries (MM components). Your scenario is slightly different since you have static pages, which might require a Support ticket.
    – Nickoli Roussakov
    Jul 25, 2013 at 2:23
  • Here is the link to the SDLLiveContent page I mentioned above (login required): sdllivecontent.sdl.com/LiveContent/content/en-US/…
    – Nickoli Roussakov
    Jul 25, 2013 at 2:42
  • 1
    Nice and thanks for the link. I set a size in the Dashboard and the CSS "pages" no longer create session-based versions and IE previews nicely again. I'll simplify the question and highlight the fix in the dashboard. +1 and accepted!
    – Alvin Reyes
    Jul 25, 2013 at 16:19
2
+100

In the 'File Types' area of the CMS do you correctly have the CSS mime type created? I'd check and add it... also check text/html files etc to see if the 'css' extension found it's way into one of those File Types, if it has for example ended up in the 'Html document' the CMS is likely publishing the file with the incorrect mime type.

Thanks

John

Improve this answer
5
  • Interesting, does the mime file type apply even if the page template makes these pages .css (i.e. they're not multimedia components).
    – Alvin Reyes
    Nov 15, 2013 at 22:32
  • Ahh I wasn't aware that you were pushing the file via a page template -issued that info. Can you test the mime of the published file / change it on the server to save it directly as text/plain or even text/CSS - does that fix it? Just trying to bolt it down to publishing / encoding
    – johnwinter
    Nov 16, 2013 at 3:31
  • There's no actual "publishing" with session preview afaik. Maybe encoding?
    – Alvin Reyes
    Nov 16, 2013 at 16:35
  • yeah! cheers @AlvinReyes :)
    – johnwinter
    Nov 25, 2013 at 22:56
  • TRex defaulted the bounty to you. Unfortunately I didn't get this setup to work.
    – Alvin Reyes
    Sep 27, 2014 at 0:02
2

This may not be the issue, but it's burned me in the past:

  1. Goto Administration > Multimedia Types
  2. Open Cascading Style Sheet
  3. Is it called Cascading Style Sheet, or Cascading Style Sheets ?
  4. is the MIME Type text/css?

Also:

Is the title attribute being applied to any of your <link/> elements? If so, remove it.

Another thing you could do to see if IE is disabling things is to pull up the IE console:

  1. with IE open, press f12
  2. go to the console
  3. type document.styleSheets in the console and press enter
  4. You should see something like [object Object]. expand that.
  5. Each object within this is a stylesheet. Expand each stylesheet. evaluate both the title property and the type property. Title should be empty, type should be "text/css"

You could also evaluate the stylesheets themselves to be sure that the first line begins with @charset "UTF-8";

Improve this answer
2
  • We have "Cascading style sheets," with an "s." But these aren't multimedia components if that matters. The CSSStylesheet object has title as "" and type set to text/css in IE's Developer toolbar. The links look like: <link rel="stylesheet" type="text/css" href="/system/css/ui.stars.min.css" media="all" />.
    – Alvin Reyes
    Nov 17, 2013 at 12:39
  • This actually removed an error when browsing to the CSS directly: @charset "UTF-8";. I'm still getting SEC7113: CSS was ignored due to mime type mismatch in Session Preview for IE, though.
    – Alvin Reyes
    Nov 17, 2013 at 12:41
1

This is due to a MIME type mismatch issue where css is ignored in Internet Explorer 9 and 10.

The MIME type can be correct by utility called FIle TypesMan It is freeware created by NirSoft. It turned out that the MIME type of .css had been changed to text/plain, preventing IE from rendering my styles.

Using FileTypesMan to change it back to text/css fixed the problem.

Here are the steps to resolve the issue:

  1. Download FileTypesMan from the NirSoft site. Use the links near the bottom of the page to select the correct version for your operating system (there are different versions for 32-bit, 64-bit, and Windows 98/ME).
  2. Unzip the files to a local folder, and double-click FileTypesMan.exe.
  3. When FileTypesMan has finished listing all file types, scroll down in the top pane to find .css.
  4. Double-click to edit the settings.
  5. Change the value to text/css in the MIME Type field in the dialog box that opens.
  6. Click OK. Job done. IE 10 should now behave itself (well, at least as far as rendering style sheets is concerned).
Improve this answer
2
  • Hmm, I'm not sure it's a MIME type mismatch across all of IE 9 and 10. Viewing the page outside of Session Preview works okay with no issues from IE 10 handling CSS. Is this specific to SDL Tridion Experience Manager's Session Preview? Even if this does work, I don't see regular CMS users downloading a utility to fix IE.
    – Alvin Reyes
    Sep 14, 2013 at 0:32
  • Ah, I see you've answered the same to this StackOverflow question, which seems related to a client registry issue. Your solution might work for my environment but I'd rather find a general approach for all users.
    – Alvin Reyes
    Sep 14, 2013 at 0:37
1

It almost sounds like the data service is overriding the content type in some unexpected way.

I would be interested in what a capture using Fiddler looks like for one of these preview sessions, especially the request for and response of the .css file which is causing issues (if nothing else this would show you exactly what content type is being set in the response when this file is server, although from your question I am pretty certain it is text/html.)

Without seeing that, and admittedly with out much experience with experience manager and what is going on behind the scene with the preview, in the end this is served via IIS so one suggestion I have is adding a new http module which listens for the PreSendRequestHeaders event and then forces the content type of the response if the request was for a .css file:

Here is some code (untested) for creating such a module:

using System;
using System.Web;
public class ContentTypeModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.PreSendRequestHeaders +=
            (Application_PreSendRequestHeaders);
    }

    private void Application_PreSendRequestHeaders(Object sender,
         EventArgs e)
    {
        var application = sender as HttpApplication;
        var context = (application != null) ? application.Context : null;

        if (context == null) return;

        var filePath = context.Request.FilePath;
        var fileExtension = VirtualPathUtility.GetExtension(filePath);

        if (fileExtension != null && fileExtension.Equals(".css"))
        {
            context.Response.ContentType = "text/css";
        }
    }

    public void Dispose() { }
}

To use, create a 'Class library' project in Visual Studio, add a reference to system.web to the project and add the above code to the .cs file, build the project and copy the resulting dll to the BIN directory of your IIS site.

Then add the following entry to the web.config file to register the httpmodule with IIS:

<system.webServer>
  <modules>
    <add name="ContentTypeModule" type="ContentTypeModule" />
  </modules>
</system.webServer>
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.