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?
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
Just tried this with a similar format, but got a nonspecific error during the rebuild, something about a failure to bootstrap.
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.
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
https://github.com/critcola/discourse-overwatch-hero-icons/pull/1
You’re amazing. Thanks so much for your help.
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., https://critcola.com/community/).
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?
Hmmm… that is indeed a puzzle. I’ll have to take a look later when I’m home.
@eviltrout, do you have any ideas?
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.
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.woffOkay, 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.
https://github.com/discourse/discourse/blob/4d65370797d87d90741f2f3774b7c6dccdb6a7ae/lib/discourse_plugin_registry.rb#L96-L119
So the best solution I can give you, is one of the following
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)So without getting the fonts to a location where they can be served, you won’t be able to reference them 
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!