Conflict with Link Break converter causes invalid XHTML output
| Project: | Code Filter |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
version info: codefilter.module,v 1.10.2.2 2005/04/23 02:40:04
Because the text in comments are being outputed with HTML tags around it my web pages with the PHP code blocks were not validating as XHTML Transitional. The codefilter div tags were being returned surrounded by p tags, which the W3C validator doesn't like.
I was able to workaround this by changing the div tags on lines 47 and 82 of the codefilter.module (PHP related outputs) to span tags and then modifying the CSS to turn the span into block elements. Here's what the changed lines look like now:
47: return '<span class="codeblock">'. highlight_string("<?php\n$text\n?>", 1) .'</span>';
82: if ($multiline) $text = '<span class="codeblock">'. $text .'</span>';
Then I changed the div to span and added display:block; in the CSS:
span.codeblock {
display: block;
padding: 15px;
border: 1px solid #CCC;
background-color: #EEE;
}
The page validated after this and I haven't noticed any other adverse affects.
Hope this helps.
#1
-1, span breaks my code blocks in firefox, but I did verify the sequence
<p><div class...does not validate.#2
I found this too, with codefilter.module,v 1.10.2.5 2006/03/28 02:42:55. To work around I added these two lines after line 111
<?php$text = preg_replace('@<p><div class="codeblock"><code>@','<div class="codeblock"><code>',$text); $text = preg_replace('@</code></div></p>@','</code></div>',$text);
?>
So it strips the offending
and
before returning the string. Not very elegant but code then passes validation.
#3
That didn't look quite right!
<?php$text = preg_replace('@<p><div class="codeblock"><code>@','<div class="codeblock"><code>',$text);
$text = preg_replace('@</code></div></p>@','</code></div>',$text);
?>
#4
That still doesn't look right. Could you put it in a txt file and attach it?
#5
The code has changed since this issue was last updated. Does this problem still exist?
#6
I can confirm that the problem still exists. Example: http://wimleers.com/blog/textmate-command-look-functions-api.drupal.org.
#7
#8
Ok this is not a bug.
In your input format, you have to move the code filter *before* the line break converter, if you're using it. People who don't use the line break converter in their input format(s), should not experience this issue.
#9
I’ve added this to the INSTALL.txt doc. Thanks for finding the fix!
#10
FYI, I just added an issue about the input filtering order on d.o.
http://drupal.org/node/198179
#11
Wow, I wasn't aware this problem existed here on Drupal.org as well! :D Nice catch :)
#12
Automatically closed -- issue fixed for two weeks with no activity.
#13
I’ve been playing around with input ordering until my eyes bug out. Any ordering dependency that we can get rid of is a good thing.
If codefilter wraps its code blocks in its own
<p>tags during the 'prepare' stage of input filtering, than Line Break Converter won't wrap one around it. Then we can strip the<p>off during 'process'.#14
I had a hard time getting that to work until I remembered the line breaks just inside the
<p>tags.I can confirm that enabling Code filter on a format automatically puts it at weight 10, so this should help keep people's content up to standards.
#15
If the module surrounds the code with
<div>tags, then you cannot put<p>tags around that.#16
True, but like John suggested, it's taking out the
<p>tags in the process step with the preg_replace().