TypeError: Discourse.Dialect.postProcessText is not a function


(Daniel Marquard) #1

I’m writing my first plugin for Discourse, modeled after the plugin in this tutorial, but I’m encountering an error.

In my error log, I see the error “TypeError: Discourse.Dialect.postProcessText is not a function” for this server-side file.

Any thoughts on this? Is it that the function is too long?


Why is Discourse sometimes not loading?
(cpradio) #2

You should see a console message saying it is deprecated.

I haven’t tested this, but I think this is close to what you’d want.

Create a file at /assets/javascripts/lib/discourse-markdown/pirate-speak.js.es6

import { registerOption } from 'pretty-text/pretty-text';

registerOption((siteSettings, opts) => {
  opts.features['pirate-speak'] = true;
});

function piratize (text) {
  return text.replace(/\b(am|are|is)\b/ig, "be")
             .replace(/ing\b/ig, "in'")
             .replace(/v/ig, "'");
}

export function setup(helper) {
  helper.postProcessText(function (text) {
    text = [].concat(text);
    for (var i = 0; i < text.length; i++) {
      if (text[i].length > 0 && text[i][0] !== "<") {
        text[i] = piratize(text[i]);
      }
    }
    return text;
  });
}

I haven’t actually tested this, but it should at least put you on the right track.

You can find more about the dialect helper at
https://github.com/discourse/discourse/blob/master/app/assets/javascripts/pretty-text/engines/discourse-markdown.js.es6


Plugin Tutorial #1 - How to manipulate the text in the composer?
(Daniel Marquard) #3

Just tried this with a similar format, but got a nonspecific error during the rebuild, something about a failure to bootstrap.


(cpradio) #4

I’ll see if I can find time to play around with it here shortly, but at a quick glance, you should remove

register_asset "javascripts/lib/discourse-markdown/pirate-speak.js.es6", :server_side

from your plugin.rb, that file doesn’t exist and you don’t need such a line with the new API.


(cpradio) #5

Okay, so I removed that register_asset line and then I added

        helper.whiteList([
                'span.ohi-ana',
                'span.ohi-bastion',
                'span.ohi-dva',
                'span.ohi-genji',
                'span.ohi-hanzo',
                'span.ohi-junkrat',
                'span.ohi-lucio',
                'span.ohi-mccree',
                'span.ohi-mei',
                'span.ohi-mercy',
                'span.ohi-pharah',
                'span.ohi-reaper',
                'span.ohi-reinhardt',
                'span.ohi-roadhog',
                'span.ohi-soldier76',
                'span.ohi-sombra',
                'span.ohi-symmetra',
                'span.ohi-torbjorn',
                'span.ohi-tracer',
                'span.ohi-widowmaker',
                'span.ohi-winston',
                'span.ohi-zarya',
                'span.ohi-zenyatta'
        ]);

after and inside your setup method

	helper.postProcessText(function (text) {
		text = [].concat(text);
		for (var i = 0; i < text.length; i++) {
			if (text[i].length > 0 && text[i][0] !== "<") {
				text[i] = formatOverwatchHeroNames(text[i]);
			}
		}
		return text;
	});

Output after changes

Created a pull request for you too


(Daniel Marquard) #6

You’re amazing. Thanks so much for your help.


(Daniel Marquard) #7

I knew this was probably going to be an issue, but couldn’t find any resources for circumventing it. The fonts are registered as assets, then referenced in the stylesheet as relative URLs. This is a problem for our website, and will be for other Discourse websites accessed in a directory (i.e., Crit Cola).

Of course, I could easily fix this for us, but then the plugin would be unusable by other Overwatch communities. Any thoughts on how to approach this?


(cpradio) #8

Hmmm… that is indeed a puzzle. I’ll have to take a look later when I’m home.

@eviltrout, do you have any ideas?


(cpradio) #9

This may be over-simplifying it, but can you use

    src: url('../fonts/overwatch-hero-icons.ttf?rql2oo') format('truetype'),
    url('../fonts/overwatch-hero-icons.woff?rql2oo') format('woff'),
    url('../fonts/overwatch-hero-icons.svg?rql2oo#overwatch-heroes') format('svg');

As I think it is relative to the Stylesheet path, and thus the font folder will be up one directory which will also be true for non-subfolder installs.

Also, it seems to work on my dev machine.


(Daniel Marquard) #10

I didn’t even think of that. I think we’re getting closer. Since I knew the first approach I took wouldn’t work, I didn’t even bother to check if the fonts were actually there, but now that I updated the font paths using your relative URL scheme, I’m seeing that the fonts don’t appear to be there.

There are fonts for Font Awesome in Discourse’s assets directory, but no actual “fonts” directory, as far as I can tell. A search for fonts in Discourse’s filesystem found the fonts in the plugin’s directory, but not somewhere where it would be Internet-accessible, I think. Any idea why? Where should fonts registered as assets in the plugin be stored?

root@ANDROMEDA-app:/var/www/discourse# find . -name "*.woff"
./app/assets/fonts/fontawesome-webfont.woff
./vendor/bundle/ruby/2.3.0/gems/logster-1.2.3/assets/fonts/fontawesome-webfont.woff
./vendor/bundle/ruby/2.3.0/gems/logster-1.2.5/assets/fonts/fontawesome-webfont.woff
./public/assets/fontawesome-webfont-c812ddc9e475d3e65d68a6b3b589ce598a2a5babb7afc55477d59215c4a38a40.woff
./plugins/discourse-overwatch-hero-icons/assets/fonts/overwatch-hero-icons.woff
./plugins/docker_manager/assets/fonts/fontawesome-webfont.woff

(cpradio) #11

Okay, so it works locally (or in a dev) environment because you don’t have to use register_asset to get to it. The issue you are going to have is register_asset doesn’t accept font files.

So the best solution I can give you, is one of the following

  1. Upload the fonts to a CDN, reference the CDN in the CSS (applies for all scenarios).
  2. Upload the fonts to the root of your main site and in the CSS use /fonts/overwatch-heroes…
  • Inform people in the README to do the same so it works for them too (doesn’t really apply for those running on a sub-domain though)
  1. Instruct users to change the Site Setting authorized extensions to be able to upload the fonts, then copy and paste CSS into the Admin > Customize area to reference those uploaded URLs for the @font-face (and in your plugin CSS, do not have that @font-face portion in it)
  • This is probably the most convoluted way

So without getting the fonts to a location where they can be served, you won’t be able to reference them :frowning:


(Daniel Marquard) #12

Strange. Last night, I ended up hosting the fonts with GitHub and changing the font URLs in the stylesheet, so I’ll probably stick with that approach. I wonder why fonts are restricted in plugins?

Thanks so much for your help with this!