Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Setup Wizard not functional on new install #1697
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
Screenshot(s) showing the problem:
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.
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.
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!
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 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
I have fixed it in src/octoprint/templates/dialogs/wizard.jinja2 as:
to set the flag:
Not nice, but does the job and fixes the wizard.
@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.
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!
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
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 :)
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
Ah, you're on Windows, not sure how to resolve it, then.…
On Mon, Jan 9, 2017, 16:59 murdocman ***@***.***> wrote: @LeftyBC <https://github.com/LeftyBC> when i do git pull it says - 'git' is not recognized as an internal or external command, operable program or batch file. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1697 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPovvhLA-l_BDm1KwgFdMfuSPVjrsXgks5rQtf4gaJpZM4Ld7sM> .
Well, you must have checked out the sources to originally install it somehow. That's the command you need to use here too.
Shouldn't be necessary I think. Tested (on Windows btw), doing a broken install, then updating and running
referenced this issue
Jan 13, 2017
referenced this issue
May 3, 2017
This seems to be the solution :