I use texy and lindef in conjunction to insert images like this:

[* [#123:imagename,nolink] >]

Let me explain:
imagename is a user defined field containing an image name like "myimage.png" (#123 is a self defined cck image node, but that does not matter). So the above exression should be expanded by linodef to

[* myimage.png >]

and texy can expand it to an <img>-tag.

That's the theory. Indeed linodef somehow converts the trailing ">]", too, into 

[* myimage.png&lt;/p&gt; >]

and that's not what I have expected.

With rc1 I use

[* [#nl123:imagename] >]

and everything works well!

CommentFileSizeAuthor
#5 linodef-filter.inc_.patch1.8 KBpepe roni

Comments

Roi Danton’s picture

Roi Danton commented

Hm, can't reproduce this with a local dev version. Also the trailing >] isn't replaced correctly since >] still appears in [* myimage.png&lt;/p&gt; >]. I assume another filter which is enabled adds that odd &lt;/p&gt;, which is </p>. Seems like this is the line break converter. In rc2 I have a line that removes those </p> tags which are added by line break converter sometimes (without reasons) to fields. Therefore I'm a little bit curious about this. With the filter weight 10 for Linodef I don't encounter this problem in my test environment.

However, there is a small difference between rc2 and my test version. I don't think this causes the problem but if you want to try: Line 40, includes/linodef-filter.inc
RC2

    "@\[#([0-9]+):([0-9a-z_]+),([a-zA-Z,=]*)\]@e"                      => "_linodef_filter_processoptions($1,$2,0,'$3');",

New

    "@\[#([0-9]+?):([0-9a-z_]+?),([0-9a-zA-Z,=_]*)\]@e"                => "_linodef_filter_processoptions($1,$2,0,'$3');",
pepe roni’s picture

pepe roni commented

Thanks for your reply!

I don't see any difference in the output when I patch the code as suggested.

But I have added some test outputs to your code (includes/linodef-filter.inc)

echo "<strong>before linodef:</strong><br />".$body."<br />";
  $body = preg_replace(array_keys($preg), array_values($preg), $body);
echo "<strong>after linodef:</strong><br />".$body."<br /><strong>end linodef</strong><br />";

if the body text reads
[* [#130:field_filename,nolink] >] ***subtitle for image
there will be the following output at the beginning of the document:

before linodef:
[* [#130:field_filename,nolink] >] ***subtitle for image
before linodef:
empfang.jpg
after linodef:
empfang.jpg
end linodef
after linodef:
[* empfang.jpg

>] ***subtitle for image
end linodef

or in original html-code:

<strong>before linodef:</strong><br />[* [#130:field_filename,nolink]  >] ***subtitle for image
<br /><strong>before linodef:</strong><br />empfang.jpg<br /><strong>after linodef:</strong><br />empfang.jpg<br /><strong>end linodef</strong><br /><strong>after linodef:</strong><br />[* empfang.jpg</p>   >] ***subtitle for image
<br /><strong>end linodef</strong><br />

It was an input filter with linodef only! Watch the line break between "empfang.jpg" and ">]". This line break causes the error! If I then would apply texy, it would regard the </p> as part of the file name and mask it with &le;/p&gt;.

I think, there are problems with iterations within the filter. The first iteration was correct, but the second made the mistake.

Here is the generated html with rc1, with same changes in includes/linodef-filter.inc:

<strong>before linodef:</strong><br />[* [#nl130:field_filename]  >] ***subtitle for image
<br /><strong>after linodef:</strong><br />[* empfang.jpg  >] ***subtitle for image
<br /><strong>end linodef</strong><br />
pepe roni’s picture

pepe roni commented

I think, I have found the error: in line 208 in includes/linodef-filter.inc you call check_markup(). But what for? Do you want to implement the html filter with linodef, too? Without this line, all works well!

My filter configuration looks like this:

  1. Linodef, to generate html outof [#...] tags or include image file names
  2. texy! Filter, to format source and include images (from image file names, linodef must have done its work before!), generates html
  3. internal path filter, to convert "internal:path" into html (only for non-node or non-taxonomy pathes, as these are better-handled by linodef)
  4. html-filter, to strip off disallowed tags (texy allows to enter pure html)

    5. As you can see, the html-filter is called finally. In all my input formats, this filter is the last to be applied (especially if you use a wysiwyg-editor!), and I think this is a good idea.

Roi Danton’s picture

Roi Danton commented

Thanks for your detailed test report! One difference between RC1 and RC2 is that RC2 uses a filter for all fields instead of plain text as RC1 did. So thats the reason it works in RC1 but not RC2. In detail for RC2:

  1. check_markup, using the default input format which needn't to be the input format the node is currently using (linodef-filter.inc, line 208)
  2. remove opening and closing <p> tags if inserted by line break converter (line 210ff)

If your default filter format uses the line break converter I assume that this inserts the additional </p> tag.

Solutions

  • Quick and dirty: Replace line 208 ($output = check_markup($output, '', False);) with $output = check_plain($output);. This removes all html tags (as in RC1).
  • Better (as it will be in RC3): Replace line 210-215 with
            while (substr($output, 0, 3) == '<p>') {
            $output = substr($output, 3);
        }
        while (substr($output, -5, 4) == '</p>') {
            $output = substr($output, 0, -5);
        }

This should be enough I hope. If this doesn't work either my assumption was wrong. In that case it would be nice if you could report back. :)

Feature question

  1. Adding a setting so the admin can choose between using check_plain or check_markup (default) for the embedding of field content. That is, you have a textfield with formatted content (e.g. highlighted text): If the admin chooses check_plain the formatting would be removed from the embedded text ("plain" text). On the other the danger of a conflict with another filter (as it appears here) is greatly reduced. (only affects the embedding of fields)
  2. Giving the admin the opportunity to choose which input format check_markup should use with Linodef instead of using the default input format. (only affects the embedding of fields) Unfortunately I can't set the input format to the one of the current node automatically.

What do you think?

pepe roni’s picture

pepe roni commented
StatusFileSize
new linodef-filter.inc_.patch1.8 KB

Here is a patch, that works for me. I also included the syntax of rc1 for compatibility reasons, because I do not want to change all nodes ;)

pepe roni’s picture

pepe roni commented
Status: Active » Reviewed & tested by the community
pepe roni’s picture

pepe roni commented

I don't think it is a good idea, to apply the filter as you did. So, if you include content from other node, apply the default filter to this piece of content and then apply the current filter to the whole content again, you might create a great mess.

Example: Default filter is "filtered HTML", node 1 has a lot of html and full html filter, node 2 has also full html. So, to include the content of node 1 into node 2 applies default filter (filtered HTML) to content of node 1, includes it, and applies full html to whole content? What do you achieve? Indeed not what you wanted, because essential html-tags have been stripped off the content of node 1.

Your change above (stripping off p-tags) did not work, as I mentioned before.

btw. Filters could add other content at the end, not only closing </p>-tags (for example: "end of document"). How do you want to strip these content off? Also field content (unless it is "Body") normally must not be filtered, so applying a filter creates more nonsense than sense.

pepe roni’s picture

pepe roni commented
Status: Reviewed & tested by the community » Needs review
Roi Danton’s picture

Roi Danton commented
Title: Problems with texy and linodef » Problems with "pass-through" of filtered layout of embedded fields
Status: Needs review » Fixed

Lol, indeed you're right. I was blinded (can't see the wood for the trees) since I've used check_plain in RC1 to avoid infinite recursions of Linodef tags (in RC2 I've written a function to remove them). Of course this removed all formatting so someone wanted to have format passed through. Unfortunately due to the existence of check_plain I haven't removed this but replaced it with check_markup. See #335433: Enable "pass-through" of filtered layout of embedded fields.

That is nonsense indeed because the input filter does that job already. Thanks for pointing that out.

I've applied the bottom part of your patch. Now the input filter sort order weight has to be set the way you mentioned in #3 always. Linodef has to have the lowest weight so that other filters can apply their changes to the embedded fields. Otherwise e.g. newlines won't be created by line break converter etc. That should be much clearer for everyone now. Thanks a lot!

Commited to Drupal 6 branch.

pepe roni’s picture

pepe roni commented

Why not apply the first part? It doesn't hurt, but helps upgrading. You don't need to document that old syntax.

So one can apply the rc2 and everything works well. In the meantime one can modify the nodes one after the other to use the new syntax without braking the functionality of the site.

Roi Danton’s picture

Roi Danton commented

Okay, I've added it. I'm planning to remove that code in final version. But due to the fact there is a long list to do (views for button list, overview which items are linked where by Linodef, buttons for all editors) the RC1 backwards compatibility will be part of the package at least for this year.

Search and replace old syntax

To replace the old syntax a regular expression search & replace module for Drupal would come in handy. I think one exists for D5. The search and replace module for D6 isn't capable of doing RegExp currently resp won't be added likely by the author: #307270: REGEX Support would be great.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.