[issue] v4.0: bq(class_name). outputs unexpected HTML formatting

Sandwich · 2005-08-15 14:17:54

EDIT: This bug is still valid for 4.0.1.

When I post an article with blockquotes, and assign the blockquote a class through <code>bq(class_name).</code>, the class gets applied to a paragraph tag inside the blockquote, not to the blockquote itself. This does not happen on these forums (here it works as expected), only in Textpattern.

This blockquote should have a class of “blurple”. Blurple is an awesome color. On these forums, the class is properly applied to the <code><blockquote></code>.

In a TXP article, the class is applied to the paragraph inside the <code><blockquote></code>, as follows:
<pre>
<code>
<blockquote> This blockquote should have a class of “blurple”. Blurple is an awesome color. On these forums, the class is properly applied to the <code><blockquote></code>.
<blockquote>
</code>
</pre>

Partially related, is it possible to have a way to generate a blockquote with multiple paragraphs using Textile?

Oh yes, diagnostic info (*‘s added by me):
<pre>
<code>
Textpattern version: 4.0 (r789)
last_update: 2005-08-15 13:43:13/2005-08-15 13:42:59
Document root: /web/clients/****/htdocs
$path_to_site: /web/clients/****/htdocs/txp
Textpattern path: /web/clients/****/htdocs/txp/textpattern
Permanent link mode: messy
Temp folder: /web/clients/****/htdocs/txp/textpattern/tmp

Site URL: www.****.org/txp

PHP version: 4.2.1
Register globals: 1
Magic quotes: 1/0
MySQL: 3.23.46
Locale: en_GB
Server: Apache/2.0.39 (Unix) PHP/4.2.1

.htaccess file contents:
———————————— # DirectoryIndex index.php index.html # Options +FollowSymLinks # RewriteBase /relative/web/path/

<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{REQUEST_FILENAME} -f [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^(.+) – [PT,L]

RewriteRule ^(.*) index.php </IfModule> ———————————— </code> </pre>

EDIT: Can’t seem to prevent those crosshashes from being parsed into an ordered list.

EDIT 2: The search function seems to be broke; I’d searched for threads containing “blockquote” before I posted this, and didn’t find any. Then after posting, I searched again, and still didn’t find any. Then I told Google to search the forums.textpattern.com for “blockquote”, and lo and behold, results!

Last edited by Sandwich (2005-09-13 13:38:32)

Sandwich · 2005-09-01 14:39:52

Bump! :)

Sandwich · 2005-09-13 13:36:13

Another bump, since this still is not fixed in 4.0.1. :)

dsiem · 2005-09-13 15:26:20

If you want to change this behavior, change line 484 to:<code>$start = “\t<blockquote$cite$atts>\n\t\t”;</code>
And line 488 to: <code>return “$start$content$end”;</code>

Sandwich · 2005-09-13 15:42:16

Thanks – lines 484 and 488 in, uhm, which file? ;)

Jeremie · 2005-09-13 16:00:14

My guess is classTextile.php. Still, it should be fixed in core.

dsiem · 2005-09-13 16:15:43

Correct, it’s the file classTextile.php. I forgot to mention that. I’ll submit the ‘fix’ as a patch against the current revision.

Sandwich · 2005-09-13 16:21:23

That did it! Big thank-you’s to both dsien and Jeremie! :)

Sandwich · 2005-09-18 12:17:50

IMPORTANT: The above fix is buggy. :p

It seems to me that this thing is fairly problematic. Here’s the original code (plus the relevant lines specified and some added formatting for clarity), lines 465-489 in textpattern/lib/classTextile.php:

<pre>
<code>
<style type=“text/css” media=“screen”> ol#sandwich_list li { margin: 0; padding: 0; font-size: 0.8em; } </style>
<ol start=“465” id=“sandwich_list”>
<li> function fBlock($m)</li>
<li> {</li>
<li> // $this->dump($m);</li>
<li> list(, $tag, $atts, $cite, $content) = $m;</li>
<li></li>
<li> $atts = $this->pba($atts);</li>
<li></li>
<li> if (preg_match(“/fn(\d+)/”, $tag, $fns)) {</li>
<li> $tag = ‘p’;</li>
<li> $atts .= ‘ id=“fn’ . $fns¹ . ‘”’;</li>
<li> $content = ‘’ . $fns¹ . ‘ ‘ . $content;</li>
<li> }</li>
<li></li>
<li> $start = “\t<$tag”;</li>
<li> $end = “</$tag>”;</li>
<li></li>
<li> if ($tag == “bq”) {</li>
<li> $cite = $this->checkRefs($cite);</li>
<li> $cite = ($cite != ‘’) ? ‘ cite=”’ . $cite . ‘"’ : ‘’;</li>
<li> $start = “\t<blockquote$cite>\n\t\t<p”;</li>
<li> $end = “\n\t</blockquote>”;</li>
<li> }</li>
<li></li>
<li> return “$start$atts>$content$end”;</li>
<li> }</li>
</ol>
</code>
</pre>

Sandwich · 2005-09-18 12:19:41

Admins, please excuse my “abuse” of HTML and CSS code in this and the above post – I wanted to be as clear as possible.

Now, the original fix was to relocate the “<code>$atts</code>” from line 488 to line 484, and to move the “<code>></code>” from line 488 to the end of line 484. This, however, causes header tags (“<code>h1.</code>”, “<code>h2.</code>”, etc.) and specified paragraphs (i.e. “<code>p.</code>” tags, not just paragraphs generated from blocks of text seperated by linebreaks) to break (they have no closing “<code>></code>”).

So the fix is simple: re-relocate the “<code>></code>” from line 484 back to its original position in line 488. This fixed the immediate issue of the other block-level elements being broken, but raised some other questions:

Since this function deals with headers and paragraphs (and whatever else) in addition to blockquotes, relocating the “<code>$atts</code>” from 488 to 484 removes any attributes (centered text, class names, etc.) from being applied to the other block elements. So, since <code>blockquote</code> is a special case that generates 2 block-level elements from one bit of Textile code (<code><blockquote></code> and <code></code>), there needs to be an exception when addressing blockquotes. Here’s what I propose:

<pre>
<code>
<style type=“text/css” media=“screen”> ol#sandwich_list li { margin: 0; padding: 0; font-size: 0.8em; } </style>
<ol start=“465” id=“sandwich_list”>
<li> function fBlock($m)</li>
<li> {</li>
<li> // $this->dump($m);</li>
<li> list(, $tag, $atts, $cite, $content) = $m;</li>
<li></li>
<li> $atts = $this->pba($atts);</li>
<li></li>
<li> if (preg_match(“/fn(\d+)/”, $tag, $fns)) {</li>
<li> $tag = ‘p’;</li>
<li> $atts .= ‘ id=“fn’ . $fns¹ . ‘”’;</li>
<li> $content = ‘’ . $fns¹ . ‘ ‘ . $content;</li>
<li> }</li>
<li></li>
<li> $start = “\t<$tag”;</li>
<li> $end = “</$tag>”;</li>
<li></li>
<li> if ($tag == “bq”) {</li>
<li> $cite = $this->checkRefs($cite);</li>
<li> $cite = ($cite != ‘’) ? ‘ cite=”’ . $cite . ‘"’ : ‘’;</li>
<li> $start = “\t<blockquote$cite$atts>\n\t\t<p”;</li>
<li> $end = “\n\t</blockquote>”;</li>
<li> $atts = “”;</li>
<li> }</li>
<li></li>
<li> return “$start$atts>$content$end”;</li>
<li> }</li>
</ol>
</code>
</pre>

In essence, I apply any specified attributes to the blockquote and then erase them inside the blockquote <code>if … {}</code> block, before they are applied again in the last line. Can anyone spot any problems with this method?

Last edited by Sandwich (2005-09-18 12:21:14)

Sandwich · 2006-03-07 13:23:53

Don’t rightly know why this is in the Dead Letter Office… this hasn’t been fixed in 4.03.

Textpattern CMS

Textpattern CMS support forum

#1 2005-08-15 14:17:54

[issue] v4.0: bq(class_name). outputs unexpected HTML formatting

#2 2005-09-01 14:39:52

Re: [issue] v4.0: bq(class_name). outputs unexpected HTML formatting

#3 2005-09-13 13:36:13

Re: [issue] v4.0: bq(class_name). outputs unexpected HTML formatting

#4 2005-09-13 15:26:20

Re: [issue] v4.0: bq(class_name). outputs unexpected HTML formatting

#5 2005-09-13 15:42:16

Re: [issue] v4.0: bq(class_name). outputs unexpected HTML formatting

#6 2005-09-13 16:00:14

Re: [issue] v4.0: bq(class_name). outputs unexpected HTML formatting

#7 2005-09-13 16:15:43

Re: [issue] v4.0: bq(class_name). outputs unexpected HTML formatting

#8 2005-09-13 16:21:23

Re: [issue] v4.0: bq(class_name). outputs unexpected HTML formatting

#9 2005-09-18 12:17:50

Re: [issue] v4.0: bq(class_name). outputs unexpected HTML formatting

#10 2005-09-18 12:19:41

Re: [issue] v4.0: bq(class_name). outputs unexpected HTML formatting

#11 2006-03-07 13:23:53

Re: [issue] v4.0: bq(class_name). outputs unexpected HTML formatting

Board footer