Setup Wizard not functional on new install #1697

LeftyBC opened this Issue Jan 9, 2017 · 24 comments


None yet

6 participants

LeftyBC commented Jan 9, 2017

What were you doing?

Installing a fresh copy of Octoprint from master 1.3.0 branch.

What did you expect to happen?

Setup wizard to complete as normal

What happened instead?

Setup wizard is all mashed into a single step and is not completable.

Branch & Commit or Version of OctoPrint

Master at 1.3.0

Printer model & used firmware incl. version

Flashforge Creator Pro 2016

Browser and Version of Browser, Operating System running Browser

Chrome 55, Firefox 46 on Windows 10

Link to octoprint.log

Link to contents of terminal tab or serial.log

N/A, can't get to printer yet

Link to contents of Javascript console in the browser

less.min.js:13 Less has finished and no sheets were loaded.
packed_core.js?6e94734d:11710 Starting dependency resolution...
packed_core.js?6e94734d:11811 ... dependency resolution done
packed_core.js?6e94734d:12028 Initial application setup done, connecting to server...
packed_core.js?6e94734d:10454 Connected to the server
packed_core.js?6e94734d:12032 Finalizing application startup
packed_core.js?6e94734d:11936 Going to bind 28 view models...
packed_core.js?6e94734d:11977 Did not bind view model TimelapseViewModel to target #timelapse since it does not exist
packed_core.js?6e94734d:12010 ... binding done
packed_core.js?6e94734d:12021 Application startup complete

Screenshot(s) showing the problem:


Additional info

This came about as part of discussion on #1695 and is suspected to be due to a bug or behaviour change in Jinja 2.9. I was able to get the UI to go from completely devoid of CSS and JS to loading somewhat properly, but the setup wizard is still not working.

I can manually go in and bypass the setup wizard for now by adding a few lines to config.yaml but it will be an issue for other new installs in the future.



Hi @LeftyBC,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - if you have a question or otherwise need some kind of help or support refer to the Mailinglist or the G+ Community instead of here.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2017-01-23 04:50 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.


I am also having the same problem @LeftyBC , i get to the wizard, create the user but next doesnt work. I also tried to bypass with code and that didnt work.


I am also having this issue.... Seems I was too hasty in closing the other issue, but since its a different issue anyway, this probably makes more sense.


@LeftyBC also, what code worked for you to bypass the wizard?

LeftyBC commented Jan 9, 2017

@murdocman it's mentioned in #1695

nstephenh commented Jan 9, 2017 edited
  firstRun: false                                                  
  secretKey: don't change it                          
    corewizard: null                                               
    cura: null                                                           
    softwareupdate: null     

yea i did that and it doesnt bypass the wizard for me. I am running this on windows. Am i not launching octoprint correctly? i am at a loss here and its very frustrating


I hadn't indented seenWizards to the same level as the other statements and that caused issue for me. I'm running on debian 8, I'm afraid I don't know about fixing it on windows.

After applying this fix, the settings are still all on one page, but they can be saved.


yea this is getting frustrating

foosel commented Jan 9, 2017

Oh. Great. I love it when some third or fourth level dependency updates break stuff. I'll look into it.

javcz commented Jan 9, 2017 edited

I have found the problem. There seems to be a breaking change (?) in the jinja2. Variables can not be modified from the inner scope. This pattern is

a problem:

{set active=True}
      {if}{set active=False}{endif}

I have fixed it in src/octoprint/templates/dialogs/wizard.jinja2 as:

to set the flag: {% set mark_active = [True] %}
to reset it: {% do mark_active.pop() %}{% do mark_active.append(False) %}

Not nice, but does the job and fixes the wizard.

Diff: wizard.diff.txt

foosel commented Jan 9, 2017

@javcz Thanks for that. The problem is, the wizard will not be the only location that uses that pattern. I'm thinking of external plugins here that would break. I'm actually currently leaning towards pinning Jinja2 to <2.9 for that reason, even though I don't like that idea very much. But if the template behaviour is not backwards compatible, I don't have much choice.

@foosel foosel added a commit that referenced this issue Jan 9, 2017
@foosel Pinning Jinja to <2.9 for now
Variables defined in an outer scope can no longer be set from an inner scope (see
pallets/jinja#641). Regardless of whether that is right or wrong, we can't control if
people are using such constructs in their plugins, which versions of Jinja >= 2.9 would
now break out of the blue, regardless of OctoPrint version. That is unacceptable sadly
and requires pinning for now, until plugin authors have had a chance to adapt

Also see #1697.
javcz commented Jan 9, 2017

Understand. Although the jinja2 change is "puristicly correct" and the code should not use a pattern against the design, in this case, taking the plugins into an account, it would probably bring more pain that benefit. At the same time the real-world view engine needs a limited "logic facility" so I expect something to appear for jinja2 to implement this in a clean way.

In between, would you care for a pull request fixing this within octoprint server?

Thanks for the great job you do!

foosel commented Jan 9, 2017

I'd be happy about a PR, however I'm currently not completely happy with the array based approach to solve this and am wondering if there aren't better options.

Thing is, we need some way to assign the active class to the first link in a navigation list, but there can be section headers, so we can't just use loop.first for the check. That led to the construct above. Adjusting the array defined in an outer scope is probably against the basic intentions as well, so I wouldn't be surprised if that workaround stopped working sometime down the road as well.

I'm wondering if there might be some way to do this kind of "one time only" assignment of a class in the template without having to resolve to hacks like that. It's my first day back after a long needed vacation though and I merely just caught up with my mountain of OctoPrint related mails and pushing the above temporary solution, I haven't had time yet to go on the hunt for something like that :)

javcz commented Jan 9, 2017

Sure, my idea was an object with a simple function:

if(myFlag_ImFirstItem.isSet([reset = true])

but I have not even looked for any standard ways to solve it yet.

foosel commented Jan 9, 2017

For now at least, I've pushed the above commit also to master, something I do rarely. 1.3.0.post1 should therefore include it and also any manual installs from source that are made from this point forward. That should at least work fine as a workaround for now and make stuff work again.

Also, it will be part of the upcoming 1.3.1 release and also be merged to the devel branch.

@foosel foosel added the status:solved label Jan 9, 2017
@foosel foosel added this to the 1.3.1 milestone Jan 9, 2017
LeftyBC commented Jan 9, 2017

Thanks @foosel and @javcz - a quick git pull; python clean; python install has cleared it right up. I'll close this issue now, and if a new one needs to be raised as a TODO for the jinja upgrade, I'll let you take care of that.

I love Octoprint, by the way :)

@LeftyBC LeftyBC closed this Jan 9, 2017

ok well im lost on what i have to do to fix the issue. a little slow over here

LeftyBC commented Jan 9, 2017

Run the commands I posted in the comment above from your OctoPrint directory?

You may need to pip install --upgrade -r requirements.txt first, depending on how smart is.


it says giy isnt a command




@LeftyBC when i do git pull it says - 'git' is not recognized as an internal or external command, operable program or batch file.

LeftyBC commented Jan 10, 2017
foosel commented Jan 10, 2017

Well, you must have checked out the sources to originally install it somehow. That's the command you need to use here too.

You may need to pip install --upgrade -r requirements.txt first, depending on how smart is.

Shouldn't be necessary I think. Tested (on Windows btw), doing a broken install, then updating and running install, fixed it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment