filter:post.parse and filter:post.parseSignature changes

  • hey, it seems like this breaks plugins that might operate on links.

    If its priority is too low, the html the plugin could output is escaped. If it is too high, the markdown auto-linkifier will run on the link which will feed our plugin some html where the original link would be.

  • Community Rep

    @dwn Is that something you've experienced already? I was taking a look at @a_5mith 's youtube lite plugin but there doesn't even seem to be the notion of priority anymore.

  • @BDHarrington7 yeah, I'm trying to update his gfycat plugin to work. I have no idea how his youtube-lite plugin catches links before they're linkified, but this does not. It seems like they're functionally the same.

  • GNU/Linux Admin

    As far as I know, the functionality hasn't changed, it's just been renamed, and the arguments have been swapped around (that's what makes it a breaking change).

    Markdown listens on priority 5, listen on 6 or 4 if you want to handle links before or after (though for the life of me I can't remember which is which).

    Better bet would be to write a plugin for the underlying remarkable parser we use, although we don't have any examples of that yet...

  • @julian said:

    Markdown listens on priority 5, listen on 6 or 4 if you want to handle links before or after (though for the life of me I can't remember which is which).

    listening on a lower priority and adding HTML will result in the HTML being escaped by the markdown plugin on 5. listening on 5 or greater -- or not specifying a priority, results in your plugin seeing link HTML in many varied cases.

    the issue is pretty much certainly not related to this thread though. youtube-lite seems to work fine, I'm sure there is some trick to this in there.

  • @dwn been meaning to look at that. 😆 accepting PRs.

    The majority of my plugins don't use a priority, but do use callbacked:true. Unless there's some default behaviour when that happens, like only converting at the end for example, after markdown has parsed everything, I'm not sure. I'm not sure what made the gfycat plugin stop working. One day it worked, the next, less so. 😞

  • Community Rep

    @dwn I see your problem (although, I'm not sure why your plugin was working before, maybe the defaults changed on the markdown plugin, defaulting to linkifying urls where it wasn't before?). Anyway, the way @a_5mith and I are handling it is assuming the link to be wrapped in the anchor tag, and then parsing that out, running at a priority > 5. You can write your regex in a way that handles either case, but the trick you need to implement is to look for "<a href=" before the actual url.

    Admittedly this is really hacky and we shouldn't be parsing html with regex in the first place, but that should get you up and running. If you need help, just ask, or take a look at the regex strings for youtube-lite or imgbed

    If you do go this route, don't try to do it on priority < 5, as the markdown parser will escape the html if the setting for that is on (but you already knew that).

  • I've updated the plugin for 0.6.0, got it running, just need to diagnose why it's not working. It's getting to the winston warn about raw coming back as false. Not sure why. Will do some digging, see what I can pull out.

    If anyone fancies taking a look at that, I'm pretty stumped.

    30/11 16:34 [11326] - warn: Encountered an error parsing gfycat embed code, not continuing false
    This is the data: false [ undefined ]

    Here ish

  • NodeBB

    What is the error?

     else {
            winston.warn('Encountered an error parsing gfycat embed code, not continuing', raw);
            console.log('This is the data:', raw, gfycatinfo)
            callback(null, data);

    If it goes in there it means there is an error, try console.log(err.stack);

  • @baris Thanks Baris, that showed the issue, was using // as the URI instead of https which was incorrect apparently. 😆

    Plugin updated to 1.1.5 for 0.6.0 of NodeBB.

Suggested Topics

| |