"disable nl2br" only works in preview

[Guest]

I'm trying to post an html table. I've already discovered the trick with 'disable nl2br' to stop the table being moved down several lines. For some reason, though, the 'disable nl2br' flag only seems to be respected in the post preview, and not when the post is displayed on the blog. Examining the HTML on the blog, every text line in the table is followed by <br/>-tags; in the post preview, it is not.

I don't want to remove the nl2br plugin, because it's great for most entries. Does anyone know why the behaviour is different, and where I can change this. (I'm comfortable with coding, but am new to Serendipity)

[Guest]

By the way: I've also checked the database (serendipity_entryproperties), and the ep_no_nl2br flag is set correctly for the entry. It's also displayed correctly (checked) when I edit the displayed entry.

[Guest]

The problem seems to be connected with the caching system. I suddenly noticed that the cache entry in the serendipity_entryproperties table also contained the <br/> tags. Rebuilding the cached entries removes the <br/> tags. However, editing the entry and re-saving puts them back in! It is then necessary to select 'Build cached entries' again.

[garvinhicking]

What is the order of your event plugins? Which serendipity version are you using, and which are the versions of the involved plugins?

What you describe is not how it's meant to be!

Regards,
Garvin

[Guest]

I'm using Serendipity 0.9.1, downloaded a few days ago.
Sidebar Plugins:
- Calendar 1.0
- Quicksearch 1.0
- Archives 1.0
- Wikipedia Finder 1.2
- Categories 2.0
- Syndicate This Blog 1.0
- Blog Administration 1.0
- Powered By 1.0

Event plugins:
- Markup: Serendipity 1.1
- Markup: Emoticate 1.1
- Markup: nl2br 1.2
- Browser compatibility 1.0
- Spam protector 1.26
- HTML Validator 1.0
- Extended properties for entries 1.6
- Announce entries 1.02
- Spartacus 2.5
- Post via XML-RPC 1.10

Looking at the settings for 'Extended properties for entries', I guess I could turn off 'Allow to cache entries', but it's probably still a bug.

I took a quick look at the svn repository; there have been several changes to serendipity_event_entryproperties.php since revision 598. I can't tell whether the bug would be fixed, though. Note: there's no tag for Serendipity 0.9.1!

Thanks,

Steve

[Guest]

By the way, I suspect that the bug is in the call to serendipity_plugin_api::hook_event() in serendipity_event_entryproperties::updateCache(). As far as I can tell, no eventData is passed, so nl2br::event_hook() sees 'ep_no_nl2br' as not being set.

[garvinhicking]

It wasn'T quite that bug, but easily fixable:

Code: Select all

Index: plugins/serendipity_event_nl2br/serendipity_event_nl2br.php
===================================================================
--- plugins/serendipity_event_nl2br/serendipity_event_nl2br.php	(revision 806)
+++ plugins/serendipity_event_nl2br/serendipity_event_nl2br.php	(working copy)
@@ -20,7 +20,7 @@
         $propbag->add('description',   PLUGIN_EVENT_NL2BR_DESC);
         $propbag->add('stackable',     false);
         $propbag->add('author',        'Serendipity Team');
-        $propbag->add('version',       '1.2');
+        $propbag->add('version',       '1.3');
         $propbag->add('requirements',  array(
             'serendipity' => '0.8',
             'smarty'      => '2.6.7',
@@ -89,7 +89,8 @@
 
                 foreach ($this->markup_elements as $temp) {
                     if (serendipity_db_bool($this->get_config($temp['name'], true)) && isset($eventData[$temp['element']]) &&
-                            !$eventData['properties']['ep_no_nl2br']) {
+                            !$eventData['properties']['ep_no_nl2br'] &&
+                            !isset($serendipity['POST']['properties']['no_nl2br'])) {
                         $element = $temp['element'];
                         $eventData[$element] = nl2br($eventData[$element]);
                     }

I also committed this to our repository, many thanks!

Regards,
Garvin

[Guest]

I've applied the diff, and it's working fine. Thanks, particularly for the prompt response on a holiday!

Steve