On call of the lazyload plugin, all matched img elements will be
checked if they have a data-src attribute. If so, their src attribute
will be replaced with the contents of the data-src attribute
(effectively loading the image) and the data-src attribute will be
removed (so that multiple calls don't call multiple processing).
* Don't restrict the list of compatibility values to check against
to only those we have mapped, also support unmapped more exotic
ones.
* Allow 1:1 check against sys.platform values (with startswith).
Combined with the above that allows very granular compatibility
modelling ("freebsd11", "freebsd12") if required.
* Instead of only whitelisting ("linux", "freebsd") now also black
listing is possible ("!windows").
A detected os must match all provided whitelist elements (if the
whitelist is empty that is considered always the case) and none of
the backlist elements (if the blacklist is empty that is also
considered always the case).
See the included unit tests for examples of how this works.
Apparently python setup.py develop tries to re-install all scripts
provided by plugins (maybe only under Windows?). Since that includes
OctoPrint's own executable, things will explode with an access denied
error there. Switching over to pip install -e . fixes that, and also
is more conform with the install approach the plugin will take in
production anyhow.
So far using the "... from URL" or "... from an uploaded archive"
mechanism for installing a plugin would fail without further
information if the plugin to be installed was already installed.
The plugin manager will now detect this situation by parsing the
corresponding message from the pip output and trigger a reinstall
instantly.
A message about this will be logged to octoprint.log and the install
output.
Additionally the error handling for installation errors has been
slightly improved (install output no longer says "Done!" but "Error!"
with the reason as provided by the server) and the "could not install
plugin from URL unknown" issue should also be solved.
Evaluates json data file as e.g. published on
plugins.octoprint.org/notices.json and displays notices for plugins
installed and matching (optional) version lists.
* Extended plugin metadata by new property, only evaluated for bundled
plugins.
* Adjusted plugin manager to evaluate new metadata and add
confirmation dialog with details when attempting to disable such
a plugin.
* Added combined OctoBlog feed, replacing news + spotlight (+
octoprintonair), added corresponding config migration
* Subscribe to all registered feeds by default
* Added config button to announcement reader
* Added note how to edit announcement subscriptions to notifications
* Auto-hide announcements on logout
* Order channels server-side based on new order config setting
Old default behaviour of showing logged in users the update
notification stays default, but can now be disabled via the software
update plugin settings.
Additionally added the ignore button to the notification for users as
well (and made ignore entry in local storage user specific to still
show notification to other logged in users), plus a small hint that
in order to apply updates an admin is needed. Additionally now hiding
the notification on log out.
Closes#1739
Also introduced a new helper, a progress modal that can be used for
providing feedback about things such as bulk delete operations in the
background.
See #748 and discussion in #1807
It now resides in a file on disk and can be deleted. If the profile
configured as default is not available (e.g. due to having been
manually deleted, or on first start), the default profile as defined
in the profile manager will be written as _default and that will be
used/set as default.
On first start after this change gets applied, OctoPrint will migrate
the old "default overlay" residing in config.yaml to a file on disk
and delete the old entries in config.yaml.
Solves core reason of #1734
