">=4.0.2,<4.1" will pull in 4.1b and we don't want that due to issue with
that and websocket communication due to permessage-deflate.
While we desperately need to migrate to a newer tornado, due to some
voodoo needed to get large streamed uploads and downloads to work
that is probably not completely straightforward and therefore
something for post-1.3.0-stable release.
Having that output stay on stderr and hence in shiny red looks way
too alarming considering that it's only a pip update that is not THAT
critical usually (and we don't want to do it automatically anyhow
considering how often that appears to break stuff).
If the SettingsUpdated event for whatever reason got slightly delayed and arrived AFTER
the save request was already processed, in rare situations it could happen that the
"Settings Changed" popup was triggered even though the settings had already been
successfully saved.
Modified such that we now keep track of if we already saw the SettingsUpdated event
associated with our save request and if not we ignore the next one.
To ensure that we don't get out of sync due to that when a settings update request is
sent, but no settings are actually change, we also now always trigger the SettingsUpdated
event, even in such cases. Clients can use the hashs in the payload to test if something
actually changed - if necessary.
We used to track our webcam stream URL by the global variable
CONFIG_WEBCAMURL. That's still a left over from the architecture
about four years ago and completely obsolete these days.
Additionally it causes issues now that anything rendered into
the page (as this variable value is through initscript.jinja2)
will not be changed unless the page cache is refreshed.
Taking the stream URL from the settings view model instead
solves that problem and is way cleaner anyhow.
If there are custom system menu entries for restart, reboot and/or
shutdown, they are deleted. If the corresponding server command is
not yet configured, the command from the system menu entry is
transfered.
Can be enabled either through new --safe command line
parameter or through server.startOnceInSafeMode in
config.yaml
When running in safe mode the plugin manager will
only allow to disable or uninstall third party plugins. Enabling
third party plugins or installing new plugins is disabled.
That will hopefully allow for more straightforward recovery
in case of a misbehaving plugin.
If enabled (which it is by default), OctoPrint will now send
an M115 to the printer on initial connection in order to try
to figure out what kind of firmware it is. For FIRMWARE_NAME
values containing "repetier" (case insensitive), all Repetier-
specific flags will be set on the comm layer. For FIRMWARE_NAME
values containing "reprapfirmware", all RepRapFirmware-
specific flags will be set on the comm layer.
For now no other handling will be performed.
