Need help getting an "enable plugin" setting feature to work

Dev
1

I’m working on a markdown plugin and I’m having trouble adding a site setting to allow you to disable the feature. I wrote the plugin by following the structure of Discourse footnote, which has a setting allowing you to disable that plugin. I installed the footnote plugin and verified that it can be disabled from the UI and that its corresponding test passes. However, disabling my plugin from the site settings has no effect, and the unit test confirms this by failing.

I’m not sure what I’m doing differently compared to the footnote plugin. It’s possible my usage of opts.features is completely wrong or making bad assumptions, because like pretty much everywhere else I just replaced “footnotes” with “ruby”. Any help would be appreciated.

The repo is here: https://github.com/seanblue/discourse-ruby

Key aspects related to the site setting would include:

https://github.com/seanblue/discourse-ruby/blob/master/assets/javascripts/lib/discourse-markdown/markdown-ruby.js.es6#L2-L4

https://github.com/seanblue/discourse-ruby/blob/master/config/settings.yml#L1-L4

https://github.com/seanblue/discourse-ruby/blob/master/plugin.rb#L9

And this is the test that keeps failing (not in the repo yet):

  it "can be disabled" do
    SiteSetting.enable_markdown_ruby = false

    markdown = <<~MD
      Here is some text: {漢字|かん|じ}.
    MD

    html = <<~HTML
      <p>Here is some text: {漢字|かん|じ}.</p>
    HTML

    cooked = PrettyText.cook markdown.strip
    expect(cooked).to eq(html.strip)
  end

Not surprisingly, the failure says it’s getting the cooked text as if the markdown still applied.

expected: "<p>Here is some text: {漢字|かん|じ}.</p>"
     got: "<p>Here is some text: <ruby>漢<rt>かん</rt>字<rt>じ</rt></ruby>.</p>"
3 Likes
2

What I usually do in cases like this is start printing stuff out.

Have you tried adding some internal console.log statements outputting vars, they may help shed some light here. I do believe the settings are send down to the markdown engine, your test does look legitimate.

1 Like
3

It’s been a while since I’ve done some good old console log debugging. I’ll give that a shot.

1 Like
4

I am very much a puts debugger it is the mechanism I find I fallback to most of the time.

5

I figured out the issue. It was in fact a problem with how I was using opts.features as I suspected. After looking at the core markdown code, I realized that the feature name is based on the file name. I had my file named markdown-ruby.js.es6, so the feature name was implicitly markdown-ruby even though I was assigning the feature ruby in my code. Renaming the file to ruby.js.es6 resolved the issue.

It’s still a little unclear to me if the opts.features I’m modifying represents all features or just the markdown subset of features. If it’s all features, ruby feels a little too short/vague and I might rename the file and feature to markdown-ruby just to be safe.

4 Likes