Fixed Custom BB Code "Stop parsing BB code" still rendered in WYSIWYG

[Rasmus Vind]

I made a custom BB Code called "noparse" that should do the same as the existing tag called "plain". This was the simplest BB code I needed to port from my old vBulletin site. I have some much more complex for code highlighting. They all share the same problem.

I set the following setting in the BB Code:
Stop parsing BB code: ON

When I post something like [noparse][b]Test[b]Test[b]Test[/noparse] and press "Edit" and see the WYSIWYG editor, the [b] tags are interpreted and the text becomes bold ignoring the setting.

I went into XenForo_BbCode_Formatter_Wysiwyg and added 'noparse' to the $_undisplayableTags variable. But this had no effect. How can I make my custom BB code behave the same way as [code] and [plain]?

The reason for this being reported as a bug is that I think "Stop parsing BB code" should stop it from being parsed in the WYSIWYG editor too.

EDIT:

After intense debugging and inspecting I have found how to solve the problem. The problem is that standard BB codes are the only ones that the parser will not parse into even when setting "Stop parsing BB code" to true. The standard parser does simply not seem to be getting the custom BB codes.

I made my fix by extending the class XenForo_BbCode_Formatter_Wysiwyg using the hook load_class_bb_code.

<?php

class RaBbCodeMisc_Wysiwyg extends XFCP_RaBbCodeMisc_Wysiwyg
{
    public function getTags()
    {
        $tags = parent::getTags();
        $tags = array_merge($tags, array(
            'noparse' => array(
                'stopSmilies' => true,
                'stopLineBreakConversion' => true,
                'trimLeadingLinesAfter' => 2,
                'plainChildren' => true,
            ),
        ));
        return $tags;
    }
}

This properly informed the parser to ignore the tag.

EDIT:

Okay, I believe this to be a bug. The Wysiwyg BB Code formatter must get all the custom BB codes so the codes with the plainChildren property set to true are correctly parsed by the parser.

 

[Chris D]

This appears to be As Designed.

We deliberately override the custom tags in the Wysiwyg formatter:

public function addCustomTags(array $tags)
{
   // do nothing -- can't do this in the WYSIWYG editor
}

With that in mind I'm going to mark the report as such. Your current workaround is valid, or you could override the above method to ensure that, at minimum, your own tag is added if the others aren't.

 

[Rasmus Vind]

I just think it's kind of sad that 'plainChildren' is not respected in Wysiwyg. Couldn't you make it fetch the custom BB codes but override many of the properties instead?

 

[Liam W]

The reason they aren't in there is because rendering of custom bbcodes can't be reversed back to the custom bbcode.

So the custom ones aren't rendered at all in the WYSIWYG editor...

Liam

 

[Rasmus Vind]

Liam, you are not getting this at all. Let me walk you through it.

Imagine this code:
[code]set x[b] = 1[/code]

It contains [b] which is part of some source code, because it is inside [code] it will not be rendered in the Wysiwyg editor.

However, I wrote my own various code highlighters [trigger] and [jass]. When rendered in the Wysiwyg editor, it suddenly does this:
[trigger]set x<b> = 1</b>[/trigger]

And when saving, suddenly it looks like this:
[trigger]set x[b] = 1[/b][/trigger]

This is because the system does not respect the 'plainChidren' attribute of custom BB codes. This property tells XenForo not to parse codes inside (in this case the [b] tag).

 

[Liam W]

You're not getting me. When the WYSIWG editor is displayed, the BBCode is rendered to HTML to display in the WYSIWYG editor. Custom BBCodes are ignored in this conversion, remaining as the become tag, as there would be no way to convert the resultant HTML back to bbcode when submitted.

Because the WYSWYG parser doesn't include any custom BBCodes, it doesn't parse them, including any plain tags, because it doesn't know they exist - so it can't remove the styling.

Liam

 

[Chris D]

Liam is correct in the reason why this happens, but we have identified a workaround which is currently being tested. It will still be the case that custom tags will not be parsed, but we will try and maintain some of their other behaviours on conversion.

 

[Rasmus Vind]

Thank you. I am glad you are going to fix this.

 

[Mike]

We have managed to workaround this now, so fixed for the next release.

 

[Rasmus Vind]

Excellent. I'm glad you take it this seriously.

 

[Robert9]

How can i tell not to regex it inside [code ?

            'example' => array(
                'hasOption' => false,
                'optionRegex' => '/^[0-9]*$/',
                'callback' => array($this, 'doSomething')
            )