stk wrote:

I'm sorry, but I Pound the Podium and Proclaim: "Put Auto P to Prison for Putzing with my long Post and Pressuring me to Provide 10-days of <P> and </P> for every Paragraph, or Provoking me to Play with the NEW Auto P so it Provides the SAME code that the OLD Auto P Put out."

Um... not trying to get you riled up or anything, but shouldn't that be "... 10-days of <p> and </p> for every Paragraph ..." cuz tags are supposed to be lower case?

I haven't noticed that it changes the way some old stuff looks, and back in the day I jumped through some small hoops to make posts look happy and be valid 1.0 stuff, so maybe I should revisit them for (if nothing else) valid appearance. Back then I didn't think of turning it off and doing my own <p>s. I do now though. Specially when I post youtube stuff with the plugin.

Have you tinkered with the priority of the various plugins at work on any given post? I understand you can't order them on a post-by-post basis, but I'm pretty sure back in the day some problems got resolved by re-ordering the renderers. I forget which way does what, but if auto-P is now a lower priority number than your foo renderer try giving it a higher number and see what you get. Or the other way around but you catch the drift I'm sure. It's a maybe eh?

Yer not Provoking me are you? :-/

Haven't tried the ordering of plugins yet, as I'm still PO'd about having to do anything with my (Put away for Posterity) Post. I'll give it a look, but frankly, I'd give a snowball a higher chanch of surviving till July here in Edmonton than that will make a difference.

You never know. Stranger things have happened.

Actually I was serious, but I can't recall the situations where it helped. Just randoming a guess to illustrate: Isaac's auto-acro plugin and the packaged auto-link plugin. If you had auto-acro with a lower number it would potentially put an acronym inside what was supposed to be a link, so then - and here's a guess on a guess - auto-link would either give up or build a link with an acronym tag inside it. By changing the priority of auto-acro to a number higher than auto-link's number the link-maker would go first, and auto-acro knew it wasn't supposed to go inside links to look for matches. Problem solved with priorities!

Auto-P is different. If it always see a blank line as reason to do an </p><p> then it would make mistakes. I *think* it's smart enough to know there are times and then there are not times, so POSSIBLY changing priorities can get it to do less damage.

The downside is that a change in priority that fixes one type of post might damage another. auto-p is just like my boss: smart enough to mess up a lot of otherwise fine work ...

Haven't read everything, but yes, the auto-p is still buggy (with inline tags).

I've fixed it somehow (but not correctly as you've noticed) for 1.8 and started fixing it more for 1.8.1.

btw: If you have testcases, where it now fails despite of what the old one handled, please let me know. There are some tests, but obviously I've concentrated on what I wanted to fix (do not pee over block tags).

A testcase would be for example:
IN: "\n<div>FOO</div>\n"
OUT: "<p></p>\n<div>FOO</div>\n"

[url=http://www.randsco.com/blogB/index.php/2005/08/22/glacier_waterton_cycle_tour]Subject Post Link[/url] (v1.8) ... Bottom of the page "Table of Contents".

IN:

We hope that you enjoy the story and find it useful in planning your adventure.

</div>

<div style="clear:left;">&nbsp;</div>


<ins><hr style="width:75%;color:#090;text-align:center;" /></ins>

OUT (v1.8 autoP):

<p>We hope that you enjoy the story and find it useful in planning your adventure.</p>

<p></div></p>

<div style="clear:left;">&nbsp;</div>


<p><ins></p><hr style="width:75%;color:#090;text-align:center;" /><p></ins></p>

Should be fixed. Please try this version of it, which will also get shipped with 1.8.1, probably with some more fixes, if you tell me what is still broken.. :)

http://evocms.cvs.sourceforge.net/evocms/b2evolution/blogs/plugins/_auto_p.plugin.php?view=markup

Thanks!

We're leaving on a week-long trip, so I cannot test it now, but will, as soon as we return. I'll also take a close look at any of the other "Auto P" posts I have and report the IN | OUT if any are causing problems.

(Just had to check!) Here's another where the results are different and unexpected:

IN:

It's been one month since we posted. I can laugh at myself, because I had every intention of making entries, while we were away on summer holidays, but it didn't happen.

It's a bit like taking books home on Christmas holidays. You think that you'll study, but you soon find yourself back at University in January and not one book has been opened ... even though you've lugged them back and forth!

The month-long hiatus involved mostly visits with friends and family. The itinerary:

<p style="text-indent:-30px;margin-left:60px">&bull; 13-hour night drive from Edmonton to Vancouver.</p>

<p style="text-indent:-30px;margin-left:60px">&bull; 2-day visit with grandparents (maternal).</p>

OUT:

<p>It's been one month since we posted. I can laugh at myself, because I had every intention of making entries, while we were away on summer holidays, but it didn't happen. </p>

<p>It's a bit like taking books home on Christmas holidays. You think that you'll study, but you soon find yourself back at University in January and not one book has been opened ... even though you've lugged them back and forth!</p>

<p>The month-long hiatus involved mostly visits with friends and family. The itinerary:<br />
</p>
<p style="text-indent:-30px;margin-left:60px">&bull; 13-hour night drive from Edmonton to Vancouver.</p>
<p><br />
</p><p style="text-indent:-30px;margin-left:60px">&bull; 2-day visit with grandparents (maternal).</p>
<p><br />

[url=http://randsco.com/index.php/2005/06/15/introducing_photo_caption_zoom_2]Here's another.[/url] Because auto-P was/is an Opt-OUT plugin, it's still doing it's thing, even if someone manually puts in <p> tags. The last version seemed to handle this without issue, but the current one (this and the last post are both off of the recent fix you put on the post before) doesn't.

Here's an example:

IN:

<p><span class="catBlue geor16">The images on your left are a demonstration of the new and improved <span class="catRed">Pure-CSS PZ²</span> "Pure-CSS Photo/Caption Zoom (Version 2)"</span>.</p>

<p>The images expand upon mouseover, displaying a larger image and corresponding caption (just like the original), but this advanced version won't distrupt the flow of the XHTML page.</p>

OUT:

<p><span class="catBlue geor16">The images on your left are a demonstration of the new and improved <span class="catRed">Pure-CSS PZ²</span> "Pure-CSS Photo/Caption Zoom (Version 2)"</span>.</p>
<p><br />
</p><p>The images expand upon mouseover, displaying a larger image and corresponding caption (just like the original), but this advanced version won't distrupt the flow of the XHTML page.</p>
<p><br />

By no means an extensive test, just the most obvious issue I noticed with this recent version put up.

I hope this helps.

What do you think is wrong with it? The extra BR tags?

I think you've done a copy'n'paste error about the last part, because I get no extra unclosed "<p><br />" at the end.

Therefor I've said: give me test cases, not failures.. ;)

Because it's a snippet of a longer post, I wouldn't recommend looking at the stuff immediately at the beginning or end, as the end/start point might be different.

It's the stuff in the middle that counts.

It's interpreting

<p>blah</p>

<p>blah</p>

and spitting out

 <p>blah></p><p><br /></p>

<p>blah</p>

My guess is that it's incorrectly reading line breaks in the input and, again incorrectly, wrapping a <p> around them.

This is contrary to (a) the way line breaks are intrepreted by a non auto-P post (b) the way it used to read line inputs and (c) to what one would expect (if line breaks become <br />'s, then I wouldn't wrap them with <p>'s). :)

I think there is enough information there to see the issue (regardless of the fact that I swiped too much at the end). The pattern is established.

Sorry ... I'd cut-and-paste another, but we're literally, out the door.

I can spend a bit more time on it next week, if you want.

Hope this helps.

Please try the new one:
http://evocms.cvs.sourceforge.net/evocms/b2evolution/blogs/plugins/_auto_p.plugin.php?view=markup&pathrev=v-1-8

Actually, newlines get respected and replaced by BR, so you can add horizontal "padding"/"margin".

I've changed it now, though, so that single newlines between two HTML-tag-blocks get ignored.

And btw: BR gets wrapped in P, because of XHTML validity.

Cheers the new version works properly.

blueyed, with it does not like this:

paragraph1

<hr />

paragraph2

<hr />

paragraph3

paragraph2 will not be inside a <p> tag

Thanks, balupton. I've committed a fix for this to HEAD and v-1-8.

Ok but now there is another issue.

My paragraph one.

<hr />

My paragraph two

<hr />

My paragraph three

turns into

<p>My parapraph one.
</p>
<hr /><p><br />
<br />
My paragraph two
</p>
<hr /><p><br />
<br />
My paragraph three
</p>

instead of the expected (well what i expect)

<p>My parapraph one.
</p>
<hr />
<p>
My paragraph two
</p>
<hr />
<p>
My paragraph three
</p>

Also discovered another problem with the update:

<strong>When I was writing this I was listening to:</strong><em>
<a href="http://www.last.fm/music/Stereophonics/_/Nothing+Compares+To+You" title="Learn about this track." >Stereophonics - Nothing Compares To You</a>
<a href="http://www.last.fm/music/Stereophonics/_/Nothing+Compares+To+You" title="Learn about this track." >Stereophonics - Nothing Compares To You</a>
<a href="http://www.last.fm/music/Stereophonics/_/Nothing+Compares+To+You" title="Learn about this track." >Stereophonics - Nothing Compares To You</a>
<a href="http://www.last.fm/music/Stereophonics/_/Nothing+Compares+To+You" title="Learn about this track." >Stereophonics - Nothing Compares To You</a></em>

Ends up all on one line.

I just installed b2evo 1.8.1 with the Auto P plugin delivered with it. I have the following piece of code:

blabla <a href="http://foo.bar">link</a> says:
<blockquote>This isn't <strong>that difficult</strong> at all.</blockquote>
It should be easy

wich is rendered as

<p>blabla <a href="http://foo.bar">link</a> says:</p>
<p><blockquote>This isn't <p><strong>that difficult</strong></p> at all.</blockquote></p>
<p>It should be easy</p>

p-tags around my strong-tags? 8|

I wanted to check the settings, but when I click on the Auto P link in the plugins panel (logged in as admin), I recieve following error just after the "Add P tags in blocks" checkbox:

An unexpected error has occured!

If this error persits, please report it to the administrator.

Go back to home page
Additional information about this error:
Unsupported type [input] from GetDefaultSettings()!

So I exported that database from the production server and imported it into my development server where I also copied the files to. I had the same problem, but when I looked into the plugin code and placed a few comments, I recieved following error when clicking on the plugin tab in de backoffice:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 46080 bytes) in /var/www/blog2/inc/_misc/_plugin.funcs.php on line 362

Can you help me any further? Thanks!

Replace the _auto_p_plugin file with the one from:
http://evocms.cvs.sourceforge.net/evocms/b2evolution/blogs/plugins/_auto_p.plugin.php?view=markup

It fixes everything, but the memory_limit issue. Try adding [code]ini_set('memory_limit', '16M');[/conf] in /conf/_basic_config.php.

blueyed wrote:

Replace the _auto_p_plugin file with the one from:
http://evocms.cvs.sourceforge.net/evocms/b2evolution/blogs/plugins/_auto_p.plugin.php?view=markup

Great, it fixes the first problem i mentioned, but not the second one, although should that one be fixed? Or not... (this is the one having <a>asd</a> on newlines)

Problem solved for me, thanks!

Fine. Balupton: try the new one.

You're the man blueyed!

Although because of the <em> at the end of the line that line and the next line are on the same line, But that's cool, i just move the <em>s one line down.

Cheers :D

Sorry for having not tested it fully. Maybe it works now.. ;p

After an "</li>" tag a br is also inserted wich isn't wanted. Can I disable this? I can also write all list items on one line, but that isn't comfortable writing. In a <li>-</li> tag however, br's can be wanted if an item is split over multiple lines.

Sylvain, good catch. I've updated the file above.

Thanks!

Yep latest version is working perfectly :)

Kudos to blueyed :)

Geez, I've been gone too long. :( (I've not had the time to download and check/use the new version, blueyed, but thanks for posting it.) :D

You made a comment that had me saying "huh?" - blueyed wrote:

btw: BR gets wrapped in P, because of XHTML validity

AFAIK, the <br /> tag doesn't need to be wrapped in a <p> tag to be XHTML-valid. I've been validating to XHTML v1.0 (strict) and XHTML v1.1 standards for two years, using <br /> by itself, with nary a warning?

If you have a reference to point me to, I'd be obliged, as I've not been able to turn up anything in searching the W3C or the 'net.

Thanks.

Here we go, a new problem:

<strong>Update:</strong>
Get it here - http://storage.balupton.com/homes/storage/projects/desktop/iMulti/iMulti_v0.9.0.0.zip

The above all ends up on one line.

No, it does not.. it results in

<p><strong>FOO</strong><br />
 BAR</p>

here.

My bad, the install i was noticed the above on was not using the updated auto-p.

I noticed the auto_p plugin fales at pages that are split with <!--more--> (auto split) probably due to the fact the plugin doesn't recognise the starting <p> of "more" which is disguised as <p class="bMore">. Therefore it doesn't close the paragraph before <!--more-->.

I disabled the plugin for the pages that I cut in pieces and added the <p> myself. Now I am certified W3C XHTML 1.0 :roll:

It's been fixed a while in CVS.
Here's a patch - you can replace the whole _auto_p.plugin.php file: http://evocms.cvs.sourceforge.net/evocms/b2evolution/blogs/plugins/_auto_p.plugin.php?r1=1.23.2.10&r2=1.23.2.11

It's for 1.9.x. Not tested with 1.8.x.

Tx.

In general, it's not a bad idea to test one's site at http://validator.w3.org/. I found this erronous behaviour and a few more:
- must explicit add alt text for picture when uploading (forgot that one, would never forget when FTPing pic and manually add in text)
- wrong advice in forum about removing PermaLink icon in Linkblog (sidebar). The last line should remain intact; it closes the list item with </li>. EdB got it right, someone else not.

In general b2o does a *great* job in creating good XHTML.

Sorry for bumping up the topic but I'm implementing a rendering plugin which adds some tags (e.g. <spoiler title="NSFW">Some spoilertext</spoiler>).
What I'm doing right now is that the plugin filters the texts such that those custom tags are transformed to something like this:

<!-- spoiler title="NSFW" --><div class="spoilers">Some spoilertext</div><!-- /spoiler -->

which will get re-processed by DisplayItemAsHtml to turn to the actual rendering (With the javascript and all).
This is done to 1) preserve the formatting as much as possible even when the plugin is disabled and 2) to preserve the structure between edits.

However, the Auto P seems to mess it up a bit since it line breaks anything before and after ANY comments. Before (Pre 1.10.3 I believe), the regex for breaking those comments look like this (around line 105):

$content_parts = preg_split( '~(<!--(?:more|nextpage|noteaser)-->)~s', $content, -1, PREG_SPLIT_DELIM_CAPTURE);

So the breaking is limited only to those metacomments. However, in 1.10.3 onwards, it turned to something like this:

$content_parts = preg_split( '~(<!--.*?-->)~s', $content, -1, PREG_SPLIT_DELIM_CAPTURE);

So it linebreaks ALL comments including my meta-comments.

I'm suggesting that the regex be reverted back to the old one or, to a greater extent, don't break them at all. As in

The <!--more-->quick brown fox

shouldn't break because most people would've done this

The
<!--more->
quick brown fox

If they wanted to break the line into paragraphs anyway.

Also, there's another weird case where it linebreaks inside table tags even though I instructed it not to. I need to test this more. Something like this:

<table>
<tr><td>a</td><td>b</td></tr>
<tr><td>c</td><td>d</td></tr>
</table>

Turning to something like this:

<table>
<p></p><tr><td>a</td><td>b</td></tr>
<p></p><tr><td>c</td><td>d</td></tr>
</table>

But I think that this is a very, very specific case so when this pops out, auto p should've been turned off anyway (though it might conflict with some plugins that generate tables).