Thread

Hi there, I have a quick question about the difference in rendering between the special User Message template and the standard templates.

I have a “backup local” copy of jQuery as per HTML5 Boilerplate, called in templates like this:

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.min.js"></script>
<script>window.jQuery || document[dot]write('<script src="/assets/js/libs/jquery-1.7.0.min.js"><\/script>')</script>

Note the backslash on

<\/script>

in that backup document write.

In my templates, this piece of code is part of a larger snippet, pulls through and renders in the generated html just fine.

However in the User Message template, the backslash is being stripped out:

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.min.js"></script>
<script>window.jQuery || document[dot]write('<script src="/assets/js/libs/jquery-1.7.0.min.js"></script>')</script>

Has anyone got a quick explanation as to why this would happen, and any tips on how to hack round it?

Hope someone can help…
Mat

(Apologies for the slightly mangled code in the examples - going for readability rather than copy-n-paste-ability!)

Good grief. Minutes later I’ve hacked it.

If anyone comes across this, just double-escape. So in my example:

<\\/script>

Any explanations of the rendering process that would explain the original stripping would be really appreciated… Also, if this is a bad habit, someone please yell at me :red:

Oh and it’s EE 2.3.1 - Build: 20111017…

Hi demotive,

Does the same happen with any other Member template? The User Message template is a bit different as it always only has one purpose.

What are you attempting to show or do with it?

Hi John -

I’m only mucking around with the User Message template as opposed to the other Member templates.

The code above is simply to ensure jQuery is loaded if the Google CDN version isn’t available. The template css relies on some newer selectors, which I’m plugging with Selectivizr for IE etc. Selectivizr sits on jQuery, hence the need for it. This is site-wide, and I’m continuing that use in this template.

Otherwise the functionality is as EE default - a simple page displaying system messages.

Is that enough of an explanation? If you need more clarity just let me know. It’s not a deal-breaker in terms of the template I’m working on, mainly I was just surprised by the difference in the render of the ‘\’ character between this template and the standard templates.

Hi demotive,

I tested with default member templates and the other specialty templates like the User Message template too and can replicate this so will ping the devs on this one and hopefully have an explanation for you. Thanks for your patience

Morning John,

No worries at all 😊

I’m guessing there’s a stripslashes() or similar cleanup going on? I don’t know much about the Member Templates, but I’m guessing the User Message doesn’t run through the full templating engine…

Anyway, time being I’m happy enough - as I mentioned before I’m mainly interested in the reasons for this behaviour, it’s not holding up any development.

Thanks again 😊

Your guess is right - in show_message() in the EE_Output lib, it does a stripslashes() on the finalized data:

foreach ($data as $key => $val)
  {
   $row['template_data']  = str_replace('{'.$key.'}', $val, $row['template_data'] );
  }

  echo  stripslashes($row['template_data'] );  
  exit;

I’m not entirely sure why we need it there, though.  I’ll do some checking- may be effectively legacy.

But yes- those specialty template messages are parsed differently (and much more simply)- and it’s a stripslash clean up you’re seeing in action.

Thanks Robin, John - even though I don’t post on the forums that much, I’ve always been super impressed by the quality of response from you guys and the general EE community.

I’m happy to call this a closed topic as the reasons for the html output have been established, along with a workaround that doesn’t involve core hackery.

If it does turn out to be legacy, I get that simply cutting out stripslashes() in further releases isn’t necessarily the right thing to do as any people anticipating the function (well, me anyway) will end up with broken code. In my case it’s a negligible issue, but I guess there may far crazier things going on out there 😉

Anyway, really appreciate all the digging you’ve done on this.

Cheers, Mat

If it does turn out to be legacy, I get that simply cutting out stripslashes() in further releases isn’t necessarily the right thing to do as any people anticipating the function (well, me anyway) will end up with broken code.

LOL- exactly.  I’m putting in a mental note to think about changing it in 3.0, as with a major version change and a warning in the changelog notes, that would be the time to make such a change (and I’m not fond of the current behavior)- but yes, even then needs to be balanced against causing hassle for existing installs.

And thanks for the kind words!  We’ll call this one done as well- at least for now!