Serendipity Forums

Posted: **Sat Mar 07, 2009 12:43 pm**

hoi
when i install and enable both plugins, the html code of the navigation links, that entrysplit creates, are converted to normal text.

i tried changing the order of the plugins (i dont use caching) and playing around with the options of textwiki ("Html" and "Entities"), but that did not help.
i noticed that the nl2br seems to have the same problem, when textwiki is enabled, but ive removed it, because textwiki converts linebreaks too, so nl2br is redundant anyway.

i skimmed through the code of both, but since textwiki is quite big, i was not able to spot anything.

edit: the geshi plugin has the same problem... so its definitely a problem with textwiki.
im quite sure im not the first one experiencing this... how do i solve this?

Posted: **Mon Mar 09, 2009 10:35 am**

Hi!

If you put the order of the entrysplit plugin AFTER the textwiki, this should actually work. Only make sure you use eithe rlength splitting or a split char that is not affected by TextWiki transformations.

Sadly, the textwiki plugin has no current maintainer (the PEAR package is VERY complex) and the HTMLEntities-conversion is currently a problem. So the plugin only works well, when no other HTML-relevant transformations are performed. :-/

There's bee a thread about the current issues:

http://board.s9y.org/viewtopic.php?f=2& ... it=schlitt

Regards,
Garvin

Posted: **Tue Mar 10, 2009 1:48 pm**

thanks a lot for the link... ppl need to use the correct name for the plugins, when i should find their posts :)

your suggestion (entrysplit after textwiki) does not work (tested with the default nextpage macro () and customized versions. although it worked partly for the geshi plugin: the html is not escaped anymore, but the \n inside the code is translated by wikitext to "<br />"s.

but there is an easy fix for this (and probably other problems): if one uses the raw `` thingy for oneliners or <html> tags for multiline markup such as geshi around the respective code, everything looks ok:

Code: Select all

``<a href=http://s9y.org>weeee</a>``
<html>
[geshi lang=bash]#!/bin/bash
command &
[/geshi]
</html>

not very convenient, but it works :)
of course "Html" has to be turned on (off by default).
interesting is that the "Entities" option does not need to be turned off. it has no effect in this case.
the most important note here though is: the html end tag "</html>" needs to be own its own line!

Code: Select all

<html>
[geshi lang=bash]#!/bin/bash
command &
[/geshi]</html>

this does not work!

the problem with the entrysplit plugin is more complicated.
if i add <html> tags around the nextpage tag, it looks like the splitted output is fed into the wiki plugin (again?) although nextpage is placed below wikitext.
the opening <html> is there (though escaped) but the </html> is removed by the entrysplit (because its "after" the nextpage split). and i thought maybe the textwiki does not recognize the html tag, if it is not closed correctly, when it is fed again to it.

so i hacked the entrysplit plugin to echo "\n</html>" as last part of the footer and now it works (if i add the opening html tag myself of course).

of course modifying every plugin to output the <html> tags, if the textwiki plugin is installed, is not a very good option.
but since its only mandatory for the entrysplit, would you accept such a patch? in the other cases one can use the workaround mentioned above (manually inserting the <html> tags).
ill investigate further, maybe there is an easy solution within textwiki (like a configurable whitelist of tags, it is not supposed to touch).

ps: if you want to spend some time on this... the best option would be to join in irc and discuss it with me imho ;)

Posted: **Tue Mar 10, 2009 2:00 pm**

Hi!

Hm, I would actually prefer if we could get the TextWiki plugin up to speed and allow that one to not replace HTML code optionally. Only if that does not work at all, we could add the <html> tags (we can use "if class_exists('serendipity_event_textwiki') around that to make sure it only gets emitted when the textwiki plugin is enabled).

ps: if you want to spend some time on this... the best option would be to join in irc and discuss it with me imho

Sorry, I usually don't have time to spend on synchronous discussions. My time and work only allows support on issues where I can manage my time of reply more conveniently. Also, it's much better documented if it happens here.

Regards,
Garvin

Posted: **Tue Mar 10, 2009 2:19 pm**

garvinhicking wrote:Hi!

Hm, I would actually prefer if we could get the TextWiki plugin up to speed and allow that one to not replace HTML code optionally. Only if that does not work at all, we could add the <html> tags (we can use "if class_exists('serendipity_event_textwiki') around that to make sure it only gets emitted when the textwiki plugin is enabled).

id prefer that too... but as you know the textwiki thing is not that easy to conquer

and i fully understand your view of a/synchronous communication, np.

Posted: **Tue Mar 10, 2009 2:29 pm**

Hi!

id prefer that too... but as you know the textwiki thing is not that easy to conquer

You speak from the bottom of my heart. I'm absolutely in hate with the textwiki plugin. It's one unmaintainable mess of code, for a task that SHOULD be really straight-forward.

Regards,
Garvin

Posted: **Tue Mar 10, 2009 4:57 pm**

some of the modules of textwiki use a "skip" array of tokens, that they ignore.
every module has to implement this itself(?), but not every module does.
i wanted to add "geshi" to the skip array of the newline module (so that it does not produce the <br /> tags.
the textwiki plugin already defines such an array at line 244 of serendipity_event_textwiki.php.
but... the text_wiki newline module does not use this config at all imho.
if thats correct it could be removed... or we could submit a patch to text_wiki to actually use it heh.

just a note to show where it IS used:
later in the plugin a skip array for the paragraph module is defined. the paragraph module does use the skip array (http://pear.php.net/reference/Text_Wiki ... .html#a123).
im not sure though (i did not check), that the s9y plugin instantiates text_wiki correctly, so the array in the config is used by the module.

-----
i have still no idea why the html is filtered.
i thought maybe the entities module is not really disabled when we turn it off in the s9y plugin.
so i patched Text/Wiki/Rule/entities.php not to escape anything.
nothing changed. so its not responsible.
i looked at the other occurrences of htmlspecialchars (should i look for anything else?)... nothing suspicious.
then i googled... looked at the currect docu of text_wiki... and there is nothing at all about this file (entities.php)... because it is no longer in the distribution.
im not sure which version you have included in s9y.
.current_version in bundled_libs says "0.25.0" which would mean 2005-02-01.
but it is not included in that version either!?
is there anything that speaks against upgrading it (on my installation for testing first..., but later in the s9y repo, if it works)? do i need to do anything but extracting the current zip into the bundled-libs dir? (of course i need to fix code depending on it... but does one need to do anything else when upgrading a pear lib for s9y?)

Posted: **Tue Mar 10, 2009 5:10 pm**

hm found the html problem.
its some kind of pretranslation.. did not look into it yet.
bundled-libs/Text/Wiki/Render/Xhtml.php
if i comment out all the code inside the pre function, the entrysplit code and all other html seems to show up fine. did not notice any side effects yet.

putting textwiki at the end + patching out the pre function seems to be teh_win.

will investigate now, how to disable the "translate" config option, that triggers the pre function in the first place.

Posted: **Tue Mar 10, 2009 5:56 pm**

ok we set the translation config variable when we instantiate the wiki in the _init_wiki function in serendipity_event_textwiki.php
if i set it to null, there is no need to patch the text_wiki Xhtml.php file:

Code: Select all

624://            $this->wiki->setFormatConf('Xhtml', 'translate', HTML_SPECIALCHARS);
625:            $this->wiki->setFormatConf('Xhtml', 'translate', null);

i have no idea what the "entities" option does... or if it does anything at all. i doubt it and think, that its unusable since you updated to text_wiki 0.25.
but im not sure.
if thats true then this option should not be a "wikirule" but toggle the translation code above.
i wont try to change that though, because the config code is such a mess and i dont need to enable the escaping of html entities.
but since one can enable wiki markup in comments, just applying my patch, may open a security hole in any s9y blog with that enabled.
but im not sure... the html tags should have been filtered out anyway if they come from comments right?

Posted: **Wed Mar 11, 2009 12:09 pm**

Hi!

Thanks for digging so much into this. The SetFormatConf option looks good to me! I have some downtime due to some surgery this week, but I'll commit your patch next week. Comments should be okay, as HTML is always filtered.

Regards,
Garvin

Posted: **Wed Mar 11, 2009 10:23 pm**

good luck with whatever gets extracted, implanted etc.

the whole configuration is fucked up imho.
e.g the image path is not taken from the database or the (plugin) defaults, but from the text_wiki defaults.
you have to hardcode it into the text_wiki library (in this case bundled-libs/Text/Wiki/Render/Xhtml/image.php).
i dunno why though. it is read out correctly by the plugin and the plugin calls this->wiki->setRenderConf afterwards. maybe that api changed...

Serendipity Forums

textwiki + entrysplit incompatible?

textwiki + entrysplit incompatible?

Re: textwiki + entrysplit incompatible?

Re: textwiki + entrysplit incompatible?

Re: textwiki + entrysplit incompatible?

Re: textwiki + entrysplit incompatible?

Re: textwiki + entrysplit incompatible?

Re: textwiki + entrysplit incompatible?

Re: textwiki + entrysplit incompatible?

Re: textwiki + entrysplit incompatible?

Re: textwiki + entrysplit incompatible?

Re: textwiki + entrysplit incompatible?