-
-
Notifications
You must be signed in to change notification settings - Fork 699
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugins for the Webinterface #1521
base: stable
Are you sure you want to change the base?
Conversation
Thank you for the pull request. First there is to say we can not accept such patches on the stable branch, because this one is only for plugin fixes. The webUI in stable can't be considered very good and extensible, we had plans to make a new one from scratch, which can be found in the 1.0.0 branch. I would prefer to extend this one and finish it instead of patching and adding stuff to the old one. Allowing plugins to extend the webUI is certainly interesting, but could you describe a few use-cases for what you think such plugins could be useful? |
By defining a function called 'webinterface_add_plugin_content' in your hook, you can register resources to be added to the webpage.
…pets of code to the webinterface.
Actually I have at least one: forum.pyload.org/viewtopic.php?f=13&t=4061&p=17244 But I could also imagine having it display the remaining drive space or quotas for premium accounts. And - not to be rude - but the web interfaces ability to manage the packages is fairly primitive and even a pain in the ass when it comes to managing more complex tasks like removing the links of a specific hoster from a specific folder - there could be a plugin for those more specialized tasks as well. Although I'm fairly certain, that improving on use cases like the latter is part of the reason you think of rewriting the interface from scratch, consider this: pyLoad is highly modular anyway - why not making the web interface modular as well? People will find a way to make use of it, that's for sure! |
One plugin that I'm using for some months now are HTML5-Notifications for the Webinterface. I started changing I finished the implementation of Web-IF plugins locally. And another thing I was thinking about for a longer time now is downloading from Serienjunkies.org |
This Plug-in will provide Popup notifications for latest chrome and opera browsers. The Webinterface has been modified such, that plugins can register additional content which is embedded as base64 string. This way, each plugin still consists of only one file. this helps to keep the update procedures intact. Files served are parsed by the template system. if the name of a file registered by a plugin contains the string "static" it won't be parsed. This is important for binary data like images.
… way, the template system won't try to read the PNG as ASCII file.
Finally added the code. Feel free to browse and of course integrate it! :) |
Very nice work! 👍 |
^i'd really appreciate this! |
Hi,
this pull request is the preparation for a bigger plan of mine and should be a discussion platform, of how my ideas are implemented best!
My plan is to have the possibility to extend the Webinterface with additional content.
I made up a function name
webinterface_add_plugin_content
, that --if exposed-- will be recognised bypyload_app.py
.This function can return a list of tuples that will be added to the Webinterface as HTML tags.
will add the following right before the HEAD tag:
These possibilities may tempt others to link to 3rd party websites to include scripts into the Web-IF, therefore I would like to add the possibility for Plugins to serve whole files for the Web-IF locally.
Currently there is only the
/api/call
which can only serve JSON compatibe responses.For Images or Javascript, this won't work.
I all cases I want to prevent serving additional files together with the Plugins, so everything to be served is embedded into the
.py
file.I considered one of the following possibilities:
A.
<configDir>/tmp/plugins/<plugin>
.B.
__web_files__
which is parsed by thePluginManager
PluginManager
cleans the folder on startup and refills it with every plugin that provides the variable.C.
/api/pluginContent/<pluginName>/<fileName>
I would prefer either B or C.
What do you guys think?
PS: I accidentally added a commit (08fb26f) which already has a pull request to this branch. I will remove it next time I have shell access.