Custom Wizard Plugin 🧙

Well, I have one site that’s running 957e851ffe9bf15bb4d8c6a6d4fe8ff9326f86da and it’s working fine, but

params:
  ## Which Git revision should this container use? (default: tests-passed)
  version: 957e851ffe9bf15bb4d8c6a6d4fe8ff9326f86da

is now failing to bootstrap, even on that same server.

1 Like

Last rebuild suddenly is giving me this error:

  I, [2020-08-20T02:25:48.615489 #3387]  INFO -- : Writing /var/www/discourse/public/assets/wizard-raw-templates-01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b.js
    rake aborted!
    SassC::SyntaxError: Error: File to import not found or unreadable: theme_colors.
            on line 78 of app/assets/stylesheets/common/foundation/variables.scss
            from line 2 of plugins/discourse-custom-wizard/assets/stylesheets/wizard/wizard_custom.scss
    >> @import "theme_colors";

       ^

I see above that a lot of others have also reported error in loading a stylesheet. Rebuild works without any errors after I comment this plugin.

1 Like

Did you resolve this Jay?

Could you try pinning the Custom Wizard Plugin to an earlier commit too?

There seems to have been a lot of stylesheet changes by @angus yesterday.

For me, this commit was ‘working’ with 2.6.0.beta1 albeit without the correct stylesheet.

1 Like

No, it turns out that the client wasn’t actually using it, so I removed it.

That should do it. I have a system in place to on discourse and plugins to particular plugins and automatically so upgrades when a change is pushed to the inventory in github for just this reason.

2 Likes

Thanks all.

Yup, there was an issue with Wizard stylsheets caused by a change in Discourse. Long story short, I’m now integrating wizard styles into the Discourse stylesheet system, one upshot of which will be that active themes and color schemes will work by default in wizards (e.g. if the active Discourse theme is dark theme, the wizard will appear in dark theme by default). That’s not quite complete, but the various issues that have been mentioned should be fixed now, and the plugin should be working as before.

:nerd_face: Pro tip!

An easy way to update this plugin with 99% confidence is to test it on try.thepavilion.io before you update. Try is updated automatically every 24 hours (via a cron job) to the latest discourse commit and has this plugin installed with various test wizards, e.g. try.thepavilion.io/w/super-mega-fun-wizard (a personal fav). l’d be happy to add any wizard you’d like to test on it (just pm me the wizard.json file). It’s a free staging server! Woohoo!

If try.thepavilion.io is down, or a test wizard doesn’t work for you, don’t update. The instance may be down because another plugin on there is broken, but why take the risk eh, the ole update can probably wait a few days. Most issues will be addressed relatively quickly, although I should point out Pavilion’s official support period is the first 5 days of every month (or @merefield will tell me off :stuck_out_tongue: ).

We’re actually currently working on a special test framework and notification system so you can subscribe to get automated notifications when the plugins you’re using are not supported on the latest version of whatever branch of Discourse you’re on. Which will work regardless of whether the plugin has its own tests! Fun times. That’s still a ways away, but in the meantime, I would recommend just checking try.thepavilion.io and maybe the Super Mega Fun Wizard before you update. Take a minute to check before you update and save yourself the headache.

7 Likes

The watchmute plugin I mention here is now superseded by inbuilt Discourse functionality as from 2.6.0beta2 Groups can set category and tag notification levels

3 Likes

That is brilliant, Angus! Definitely what we need and will solve what is probably the biggest problem that I/we have with CWP. Great to be able to see the current compatibility on try.thepavillion.io too; these are great steps forward.

2 Likes

@angus, I guess you’re chasing the same bugs I’m seeing as I saw that you fixed the Could not find module 'bootbox' import from 'discourse/lib/ajax-error overnight, but I am now seeing

Uncaught Error: Could not find module `discourse/lib/cookie` imported from `discourse/models/user.

This is reproducible at The Pavilion site:

https://try.thepavilion.io/w/super-mega-fun-wizard

And here is the console output…

I’m doing a new server install and using my fork of the CWP that we’ve discussed which is why I’m always bleeding edge on this.

Bug report filed…

2 Likes

A workaround for this is to peg your Discourse version to a commit before the Cookie refactoring and then rebuild.

This worked for me - in app.yml (extract).

params:
  .
  .
  .
  ## Which Git revision should this container use? (default: tests-passed)
  #version: tests-passed
  version: a8502ae1c429ece6980f8eb7b064eab4894c2365

In fact, it looks like there is a lot of core refactoring going on at the moment so this might not be the last ‘breakage’ in this and other plugins.

2 Likes

This plugin is working on the latest tests-passed again :slight_smile:

As per our policy, I’ll be supporting tests-passed updates from today until September 5th. If you’d like to report an issue on tests-passed in this period please reproduce it on try.thepavilion.io first and submit a bug report via the bug report wizard linked there.

I’ve also updated the compatibility file to incoporate the stable and beta updates since I last did a compatibility update of this plugin. If you update to the latest stable or beta this plugin will use the indicated commits that work with those branches (see further).

The next update period (after this), will be October 1st to 5th.

5 Likes

Something looks to be off with the latest commit, @angus.

I’ve just updated one of my sites and the dropdown control in my wizard doesn’t instantiate properly. It simply displays the text of the default value (I think) but the control is not created.

I tried the thepavilion.io test wizard and it yields the same issue.

https://try.thepavilion.io/w/super-mega-fun-wizard

The console shows the following error - looks like it could be related.

2 Likes

Thanks @bletch :+1: Much appreciated. This is addressed.

See e.g. Super Mega Fun Wizard

Note that, after some testing, I’ve removed beta support from this plugin, for the time being at least. Please take care if you’re on beta and are updating. See further here: Pinning plugin and theme versions for older Discourse installs.

If you’re on stable or tests-passed update away!

4 Likes

I’ve merged those changes into my fork (eventually!) and have just rebuilt with the latest tests-passed and the wizards load again.

Nice one!

2 Likes

Interesting. The plugin is extensible so there’s a chance that you may write a separate plugin and don’t have to maintain the fork. If you wish to contribute your changes upstream, we can chat about that too. In any case happy to guide.

2 Likes

Yep look at the National Flags Plugin for a way you can ‘inject’ new functionality into the CW without including it natively in CW. See PR here: FEATURES: Localisation support, Custom Wizard plugin integration, code improvements, static data moved to yml files by merefield · Pull Request #4 · Ebsy/discourse-nationalflags · GitHub

2 Likes

Has anyone managed to solve this issue?

Is it possible to select multiple groups in a field ?

@MostafaXdev Could you explain the specific issue? I’m not seeing it from the screenshot.

@evantill Not currently

1 Like

Nevermind, I got it working.

1 Like

I’ve chatted with @angus about this already.

Here is the basis of the change.

And here's the background.

So prior to v2 where there are now potentially other ways of doing this, I needed a way to pass dynamic values into the wizard.

i.e. to pre-populate dropdown lists dynamically to allow for scenarios where I need a value from step_1 to create a dynamic set of dropdown options in step_2 for example.

I should say at this point that I’ve just assembled enough Ruby skills to be dangerous but Ember remains out of my grasp for the moment. As the saying goes “If all you have is a hammer, everything looks like a nail”.

So as I could only conceive this as a Ruby-based solution I changed the Wizard builder. I’ve basically copied @angus’s step handler validation model where blocks of code are registered and then called when needed.

If certain conditions are met, my content_providers approach calls out to blocks of pre-registered code that it expects to update the default values of the field.

It’s simple but it works. It does rely on manipulating internal structures within the step_updater which isn’t ideal.

Separately, and as you’ll see in the commit above, I also came across a show-stopper in my validation routines. I’m surprised others haven’t had this issue with v2 - or I’m missing something.

Now that the field id is auto-generated, two or more wizards can, in fact, will have the same field id step_1_field_1.

When all you’re passed in the validation routine is the field id this makes validation impossible as you can’t uniquely identify a field across many different wizards.

I had to make wizard accessible from outside the step_updater object so that I could combine wizard.id with the field.id to get something unique.

On dynamic content, Angus has (understandably) suggested that he’d like to achieve the same result in the client and not the backend. So he would prefer to focus efforts there.

So for the time being, I’m going to have to maintain the fork.

I work in schools with children that have behavioural challenges and have developed a complete system to manage their day using Polls in Discourse to capture responses to questions, and I use the CWP to interface with the user on specific, real-time tasks.

I have to say that if, like me, you not a full-time developer and don’t have the time or knowledge to understand the complexities of Ember, using the CWP as your user interface is fantastic.

I have encapsulated the validation of fields, the population of dynamic fields and the capturing of multi-step wizard results into more intuitive fields names into a singeWizardManager object like this.

  class CreatePointsCards < WizardManagerBase

    def initialize
      super
      @wizard_id = 'create_new_blank_points_cards'

      all_children = DynamicContent::AllChildren.new

      register_field(
          'step_1_field_1',
          'children_to_create',
          validate_as: 'string_not_null',
          &all_children.content_handler
      )
      register_field(
          'step_1_field_2',
          'create_from_date',
          validate_as: 'date_or_blank'
      )
      register_field(
          'step_1_field_3',
          'create_to_date',
          validate_as: 'date_or_blank'
      )

      register_step_handler
    end

    def step_handler
       ...
       ...
       ...
    end

It works really well.

2 Likes