The install and update parts are missing for now. I need some guidance/idea on how to proceed. I am not sure what is the best way to handle that considering our code base.

That is a nice feature @aledeg 👍

Here is a bit of preliminary brainstorming:

• Consider where to automatically install those extensions:
  • We have ./extensions/ but only ./data/ is supposed to be writeable by the Web server (in installations, which do not perform Web-based updates).
  • Should we allow non-admin users to install their extensions in a user-specific extensions directory? Like ./data/users/alice/extensions/
  • Should we move ./extensions/ to ./data/extensions/ and allow only admins to install extensions there? Alternatively, update our guides and distributions to ask ./extensions/ to be writeable, but I am not so found of it.
• (Not necessarily for this PR): Reconsider where extensions are supposed to save their data
  • Check e.g. the existing ./data/extensions-data/
  • Different for global or user extensions?
• How to download the extensions:
  • It would be so nice to have a git client guaranteed to be available. In absence of that, I think we need to download a ZIP archive of the whole repository containing the extension, e.g. https://github.com/aledeg/FreshRSS-extensions/archive/master.zip
  • We might have to include a hash of the ZIP in https://github.com/FreshRSS/Extensions/blob/master/extensions.json in addition of the version number.
  • As the ZIP might contain more than one extension, we can either delete the others or keep them not enabled

Thank you for your insight. I'll look into that later!

Should we allow non-admin users to install their extensions in a user-specific extensions directory? Like ./data/users/alice/extensions/

This sounds like a security nightmare and extensions might require extra php modules. Enable on per user basis sounds fine but this not.

@SuperSandro2000 You are right, until we have better permissions, that is premature