None of the Drupal 5 branches came with the README.txt.
Should probably tag that appropriately in the CVS. :-B

I just tried out the current version 5 bundle. I scratched my head a bit, the warning about the library not being available when I visited settings gave me a clue.

How about a drupal help page? That was the next place I went looking. In my modules I usually just pipe the contents of (dirname(__FILE__).'/README.TXT') out in the menu hook. May be different now with Drupal 5 and the info files...

I'd also suggest making an empty 'sifr' directory in the distro with a 'put_sIFR_download_here.txt' in it. May help.

I'm yet to see if I can get it working - need to go find some fonts I guess. :)

CommentFileSizeAuthor
#7 sifr.module.escape-js.patch614 bytessun

Comments

dman’s picture

Got it going. Very cute!

Here's a fix for XHTML validation - ampersands in attributes need to be encoded.
join($vars, '&') not join($vars, '&') on line 706 sifr.module.

function sifr_render_rule_js($rule){
  ...
  ..
  .
  if( in_array($rule->textalign,array('left','center','right'))){
    $vars[] = "textalign=$rule->textalign";
  }
  $flashvars = is_array($vars) ? ', sFlashVars: "'.join($vars, '&').'"' : '';
  $output .= "  sIFR.replaceElement(\"$rule->selector\", named({sFlashSrc: \"$fontpath\",  sColor: \"$rule->color\", sLinkColor: \"$rule->linkcolor\", sHoverColor: \"$rule->hovercolor\", sBgColor: \"$rule->bgcolor\" $padding$wsmode$case$flashvars}));\n";
  return $output;
}

sun’s picture

Assigned: Unassigned » sun
Status: Active » Fixed

If I'm replacing those ampersands with & HTML entities, sIFR only understands the first variable. I don't get warnings about XHTML invalid markup without entities.

The complete README.txt is only available in the development snapshot so far. There have been many changes to sIFR in the past weeks and because of that I'm still waiting for successful tests to create a new stable release.

dman’s picture

I was just saying that the snapshot - the tarball - does not currently include any readme at all, up-to-date or not, HEAD or not. I imagine it's just a cvs tagging thing, as I found an older one in the 4.7 CVS tree.

I did get validation complaints - but my pages are XHTML strict. You may not get the same errors if you're transitional and not claiming to be strict.
If the parameters really don't get through for you when it's encoded, I guess it's a doctype thing. :-(

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
  <title>Blueprint Theme | In Progress...</title>
<script type="text/javascript">if(typeof sIFR == "function") {
  sIFR.replaceElement("#main .title", named({sFlashSrc: "/wal/htdocs/sites/default/modules/sifr/sifr/Charlesworth.swf",  sColor: "#D0D0F0", sLinkColor: "#D0D0F0", sHoverColor: "#FCFCFF", sBgColor: "#0000A0" , sWmode: 'transparent', sFlashVars: "underline=true&textalign=left"}));
};
</script>
</head>

<body class="front logged-in sidebar-left">
<p>etc...</p>
</body>
</html>

sure fails for me in http://validator.w3.org/ , but not when the & is encoded.

sun’s picture

As mentioned before, this can't be changed without editing the sifr.js JavaScript so that it understands those escaped ampersands. Altering the sifr.module is not the problem. But altering sifr.js is a big one, since we won't host a sIFR fork on D.org.

sIFR 3.0 might support those escaped entities. As of http://drupal.org/node/120308 it is about to be released.

dman’s picture

I'm trying to help here. :-}

There are other ways to deal with XML escaping, and this can be fixed in one of a couple of other ways.

<script type="text/javascript">
//<![CDATA[
if(typeof sIFR == "function") {
  sIFR.replaceElement("#main .title", named({sFlashSrc: "/wal/htdocs/sites/default/modules/sifr/sifr/Charlesworth.swf", sWmode: 'transparent', sFlashVars: "underline=true&textalign=left"}));
};
//]]>
</script>

is valid in all flavours of HTML,XHTML, Javascript etc. It's the method used by HTMLtidy, and will solve this validation problem.

Looks like it could be patched into sifr_wrap_rules() ... if you wished to support valid pages. You don't have to of course, it was just a suggestion.

sun’s picture

Title: the README isn't committed to 5.0.X » XHTML-Strict invalid output
Status: Fixed » Needs work

Thank you for this suggestion, dman. I didn't know of this method of XML escaping yet and will definitely have a look at it.

sun’s picture

Title: XHTML-Strict invalid output » Output is XHTML-Strict invalid
Component: Documentation » Code
Status: Needs work » Needs review
StatusFileSize
new614 bytes

Attached patch adds the proposed JavaScript escaping.

sun’s picture

Status: Needs review » Fixed

Committed to HEAD and 5.x-1.x-dev.

Anonymous’s picture

Status: Fixed » Closed (fixed)