XF 2.0 Parse custom BBCode in EditorHtml (can't add new tags...)

[Jean-Baptiste]

Hello,

I made a BBCode, and I would like it to be parsed in the WYSIWYG editor.

I made a class extension :

class EditorHtml extends XFCP_EditorHtml
{

    public function addDefaultTags()
    {

        parent::addDefaultTags();

        $this->addTag('fa', [
            'callback' => 'renderTagFA',
        ]);

    }

    public function renderTagFA(array $children, $option, array $tag, array $options)
    {
        return 'This is a test...';
    }


}

The method "addDefaultTags" is executed, and I can modify existing BBCode tag (like the "B" tag). But I can't add new BBCodes...

Do you have any ideas ?

Best regards,
Jean-Baptiste

 

[Slion]

I've had that same issue with the basic Html renderer. In the end I got it to work using custom BB code framework instead of class extension but I'm not sure how that does apply to editor rendering.

 

[Slion]

Any tips on that guys as I would like to render my custom BB codes in the editor?

 

[Slion]

@Chris D
Any chance of getting your expertise on that one?
Why adding tags by overriding addDefaultTags is not working? Is it by design?

Looking at the code it seems like EditorHtml is just disabling custom tags:

public function getCustomTagConfig(array $tag)
    {
        // custom tags are displayed
        return [
            'replace' => null,
            'callback' => null
        ];
    }

Though the comment is confusing and I'm assuming it was meant to say "disabled" and not "displayed".
I guess I'm going to try extend EditorHtml to see if I can enable custom tags.

 

[Slion]

I figured out how to support my custom BB codes in WYSIWYG:

Add support for WYSIWYG. · Slion/XenForoAddOnSlionsToc@8df0118

Table Of Content add-on for XenForo 2. Contribute to Slion/XenForoAddOnSlionsToc development by creating an account on GitHub.

github.com

I could indeed enable WYSIWYG support for my custom BB codes as explained above by extending \XF\BbCode\Renderer\EditorHtml.

I still need to fix a few bugs like new line inserted when switching back to WYSIWYG from raw but that's looking really good already.

 

[Slion]

I still need to fix a few bugs like new line inserted when switching back to WYSIWYG from raw but that's looking really good already.

This one is going to be a pain, if there is a block of text between two heading Hx BbCode an extra new line is inserted at the end of that block of text each time you switch back to WYSIWYG editor. Tried playing with the custom BB code rules without luck. Thing is, I don't know where and how text block outside BB code are being processed when switching back to WYSIWYG. In any case it sounds like an XF core bug since WYSIWYG support for custom BB code is disabled and therefore most certainly not tested. Here again help from devs would be awesome.

 

[Slion]

Looks like I'm narrowing down on that extra empty line issue when rendering my custom BB code in rich editor.
In fact just editing a post in WYSIWYG is enough to reproduce it. It adds an extra <p><br /></p> at the end of a block of text in between two of my heading BB codes.
Therefore I figured the culprit is \XF\BbCode\Renderer\EditorHtml. Right now I'm looking at that filterString function as it seems to be responsible to convert text outside of BB codes to HTML. While I have not worked out exactly where the problem is, I wanted to report the fact that in the code I'm looking it is using that stopLineBreakConversion option which not referred to anywhere in the code based. I think it was meant to be stopBreakConversion @Mike @Chris D you may want to take a look at this.

 

[Slion]

So in my case in filterString that line $string = preg_replace('/\r\n|\n|\r/', "<break />\n", $string); is responsible for adding our extra break in paragraph. However that's obviously needed in most places so the question is why the $string input contains a trailing new line as soon as I enable custom BB code WYSIWYG? The answer to that question lies in our base class I guess \XF\BbCode\Renderer\Html which has a trimAfter data member that should be taking care of that but does not for some reason.

I'll need to examine that code to see if I can spot the issue, or I could just add an extra trim after in \XF\BbCode\Renderer\EditorHtml.filterString and hope it does not break other use cases.

 

[Slion]

Looks like I fixed that extra new line <p><br /></p> whenever you render html for the editor.
My understanding is that existing code in \XF\BbCode\Renderer\EditorHtml.filterFinalOutput is incorrect and somehow enabling custom BB code editor html rendering makes those issue surface.

So in that function the first issue is with the following regex:
$output = preg_replace('#<break />\s*(' . $btOpen . '|' . $btClose . ')#i', "</p>" . ($debug ? "\n" : '') . "\\1", $output);
Looks like this is intended to remove extra line breaks before block opening and closing. But why then do you insert that orphaned </p>. Then it looks like later it gets converted into <p><br /></p> somehow. That was responsible for one case of extra line.
My fix was to replace it with: $output = preg_replace('#<break />\s*(' . $btOpen . '|' . $btClose . ')#i', $debugNl . "\\1", $output);, basically removing the closing paragraph element.

Then the next regex also does something weird $output = preg_replace('#<break />\s*#i', "</p>" . $debugNl . "<p>", $output); that can potentially result in generating two <p><br /></p> in the final output. Well for n such replacement in a row it generates n+1 <p><br /></p>. That's also not what we want and it's another case of extra new line.
I replaced it with $output = preg_replace('#<break />\s*#i', $debugNl . "<p />", $output); which somehow ends up as one <p><br /></p> in the final output.

@Mike @Chris D IMHO there is something not quite right going on here, you may want to get to the bottom of that and fix it at some point. Do I get a free one year license for spending my weekend debugging your code?