Custom Wizard Plugin

(Lee Strickland) #83

@mbcahyono This is the Custom Wizard Plugin and I have discussions above about my goal and case here.
The rest will be posted shortly after this post in My Marketplace Post


This plugin is almost perfect, I am just missing an option to create unlisted topics like in the attached image.

Would it be possible to add a checkbox next to the ‘Post Builder’ checkbox or is there already a way to create unlisted topics?

(Angus McLeod) #85

This is currently possible :slight_smile:

Use the Topic Fields section to set visible to false (which is what unlisting a topic does).

This is an example from the Welcome wizard on my Sandbox.

Resulting in:


Oh, that’s great. Thank you


Thanks for this plugin. Like a previous user, I’m planning on using it to get users to confirm acceptance of updated ToS/Privacy Policy.

I’m testing it out and using the “After time” setting, and whilst it seems to work for users who are logged in at that time, if a user signs in after the set time, they aren’t seeing the wizard.

Here are my settings:

Is there something I’m doing wrong?

(Angus McLeod) #88

Thanks for the feedback, I’ll take a look in the next few days.

(Angus McLeod) #89

I can’t repro this. Testing on my sandbox, I’ve set my test Terms wizard to appear for all users at a certain time. When I log in with my various dummy accounts after that time I see the wizard every time. If you had an account on my sandbox prior to April 24th 10:24 am (Melbourne time) you should also see it next time you log in.

Could you test it again and check the /sidekiq queue after you’ve scheduled it? There should be a job there called “Set after time wizard”.

The way the After Time setting works is it creates a background job that will run at the set time. If the custom wizard still exists at the set time, the job sets a custom field for all users and also pushes a notification to all current sessions via the message bus, i.e.

def execute(args)
  if PluginStoreRow.exists?(plugin_name: 'custom_wizard', key: args[:wizard_id])
    user_ids = []
    User.human_users.each do |u|
      u.custom_fields['redirect_to_wizard'] = args[:wizard_id]
    MessageBus.publish "/redirect_to_wizard", args[:wizard_id], user_ids: user_ids

The redirect_to_wizard custom field gets checked on the ApplicationController. The user is redirected to the wizard unless they are already looking at a wizard or they are in the admin panel.

class ::ApplicationController
  before_action :redirect_to_wizard_if_required, if: :current_user

  def redirect_to_wizard_if_required
    @wizard_id ||= current_user.custom_fields['redirect_to_wizard']
    if @wizard_id && request.referer !~ /w/ && request.referer !~ /admin/
      redirect_to "/w/#{@wizard_id}"

The redirect_to_wizard field is cleared later (so they don’t keep getting sent to it).

All controllers inherit from the ApplicationController so, the After Time setting should force all users into the wizard after the set time, whether they are logged in at the set time or not, assuming this logic all goes to plan.

One possible source of error here is if a user edits the After Time time, the plugin clears the existing job and creates a new one, i.e.

if wizard['after_time'] && new_time
  Jobs.cancel_scheduled_job(:set_after_time_wizard, wizard_id: wizard['id'])
  Jobs.enqueue_at(after_time_scheduled, :set_after_time_wizard, wizard_id: wizard['id'])

if existing['after_time'] && !wizard['after_time']
  Jobs.cancel_scheduled_job(:set_after_time_wizard, wizard_id: wizard['id'])
  Jobs.enqueue(:clear_after_time_wizard, wizard_id: wizard['id'])

One issue which I’ve just pushed a fix for is the clearing of the existing job wasn’t wizard specific (i.e. I had left out the wizard_id param in the cancel_scheuled_job).

So if you had created or updated a different (i.e. a second) wizard with an after time setting, the job for the Terms wizard would have also been cleared. Did you have two wizards with an After Time setting?

(ginger man) #90

@angus Awesome progress in the plugin so far. Kudos for that.

Any plans to add the below requests part of this plugin.

  • New user (not in Discourse) click on one of many Discourse Wizard links listed in an external site -> Redirected to Discourse Signup -> After successful signup, returned to the specific wizard link. (I understand we can set a specific wizard for all newly signed up users. The need here is slightly different as there will be multiple wizard links where user manually choose to fill and these are not mandatory.)

  • Create topics replaced with wizard using category settings as requested below

(Angus McLeod) #91

This is pretty specific. If you could find, say, five other people who need it, or persuasively argue a general use case, then I’ll consider it.

Hm yes, I had forgotten about this. I’ll take a look at it over the weekend.

(ginger man) #92

Sure. I will try.

  • imho, this is a good fit for all private forums where different membership levels are issued after admin approval based on the structured data submitted by the requester.
  • Advantage of a wizard link over a create topic link is the ability to capture structured data from the end user which helps to decide the membership.
  • List of request membership wizard links can be maintained in the static website for different roles.
    (For eg. in a mentorship connect platform
    • Request to be a mentor wizard link
    • Request to be a mentee wizard link )
  • Here is the intended workflow -> New users click on the wizard link from a static website -> sign up as a discourse user -> returned back to correct membership request wizard -> fill in the details -> wait for admin to approve / add in correct groups.
    Therefore, the ability to return back to the correct wizard context after registering as a new user is critical in the above usecases for better user experience and conversions.


Thanks for taking the time to look at my issue, @angus.

I did keep editing the After Time of the same job, to retest it, so that might have been causing the issue. But I only ever had one wizard.

I’ve just logged on to your sandbox and did see the wizard as expected.

I’ll update the plugin and retry on my end with a new wizard, and will check sidekiq and let you know how it goes.

(Angus McLeod) #94

@tobiaseigen Thanks for reporting your issue the wizard on my sandbox. It should work for you now.

(Per Torstensson) #95

Been a lurker for quite a while, but just recent weeks have found time and practical use cases for working with this great plugin - Extremely useful work @angus, much appreciated!

Based on highly egotistical needs, I would like to suggest three feature requests;

  1. Possibility to reorder steps and fields. Preferably via drag-and-drop, but via list value at the least; The reason is that as soon as I have had a semi complicated wizard/form, I constantly find myself wanting to insert a step or field in a new order. This forces me to remake the wizard a couple of times to get it right, which can get cumbersome.

  2. Possibility to preload a field value with user profile values; The possibility to update the user profile is really awesome, which has gotten me to wanting to preload those fields if the user already has set them. Either in their profile or via an earlier wizard.

  3. Purely cosmetic and very minor; allow for field values to render emoji short codes

Once more, thank you for super awesome plugin @angus and hope you will consider.

All the best

(Angus McLeod) #96

Yeah. I actually added this when building this plugin for the same reason you mention, but removed it for some reason I now forget. I’ll take a look at it again.

It should do this already. For example, this is what I see in Step 2 of the Welcome wizard on my sandbox.


My name and bio on my sandbox:


Do you mean field labels? e.g.


(Per Torstensson) #97

Great news! :crossed_fingers:

Either I am completely confused, or we are talking about two use cases with opposing directions; I tried to take the welcome wizard at again, but it is only allowed to take once, so I can’t check on your site, but basically what I desire is that if I were to take you welcome wizard once more, the fields for Name and Bio, in my case would be pre-set to “Per” and “en liten bio”
In my use case, the desired fields to “reach” in a wizard would mainly be custom user fields set up in discourse. The idea of using the wizard is to better be able to encourage users to update their information via links to wizards (can’t be done in vanilla discourse) and also only relevant subsets of user information for the context of a wizard. If these fields are already set for the user, either via the profile earlier (or another wizard), it would be great to be able to have the pre-filled in the wizard the user now is taking.

Good question. Yes, in the case of input fields I mean field labels I guess, but where I noticed the “need” first was for the value field in a custom dropdown

(Angus McLeod) #98

Ah indeed; I just turned multiple submissions on. Give it another shot, and it should work as you describe.

Got it :+1: I’ll add emoji support for both a little later today.

(Christoph) #99

Just a quick thought: I wonder if some of this could be achieved with conditional wizard questions, i.e. “if user answered ‘apply for mentorship’ in question x, go to quesrion z” and the like.

(Per Torstensson) #100

Gotcha, thanks! Wow, this is so so great! :smile: I had missed it earlier because I only had tested with user custom fields and misunderstood the syntax for mapping to them. I now see this already is documented in post 64

:heart_eyes: :heart_eyes: :heart_eyes:

(ginger man) #101

You are right. It works for simple usecases with conditional wizard questions. It may not work in complex usecases where each wizard submission is configured to post in specific categories. Having 1 catch-all wizard
for all newly signed up users may not be viable in those usecases.

(Angus McLeod) #102

I’ve added emoji support for field labels and dropdown choices.