Well, another problem now with a remote user API. Just by checking the code, I see that "mail_domain_get" function inside "remoting_mail" class use the "remoting_lib" class to load the form definitions (loadFormDef), but "remoting_lib" override the "loadFormDef" function in "tform_base" and don't trigger the events like "on_before_formdef", so, my custom fields are not loaded
Nice! I think a good option is to create two new events, like on_remote_before_formdef and on_remote_after_formdef because tabs are removed and this can conflict with already made plugins. Also I can't check right now if this array key is set in a remote call $_SESSION['s']['module']['name'] Something like: PHP: //* Load the form definition from file. - special version for remoting// module parameter is only for compatibility with base classfunction loadFormDef($file, $module = '') { // EDIT: Removed because the array $_SESSION['s']['module']['name'] isn't set in the remote call.}
I'll add an issue in the issue tracker with a merge request for that, so we can add further things under this issue if we find more things that need to be improved to make plugin development easier. Btw. I'm working on a new extension and plugin installer for ISPConfig. The goal is to have some kind of extension repository similar to CMS systems like WordPress, which allows users to download and install extensions with a single click from within ISPConfig UI. I do not have the spec finished, so I can not go into details yet. Basically, the code of the extensions (for interface and server) will be located in /usr/local/ispconfig/ext/SOMENAME/. I'm placing it outside of ISPConfig because I'm preparing ISPConfig for Docker installs, so this directory will be a volume that survives a Docker pull of the image. The extension must then have a file, e.g., named file.list, which contains a list of all files of this plugin and where in the ISPConfig source tree they belong; the plugin installer will then take care to copy the file or create symlinks, in the correct locations inside ISPConfig source tree. The code you write now does not have to be changed for that; its more about packaging and enabling/disabling an extension and providing an easy way for users to discover it.
EDIT: @till can I use the config column in the server table to store some information like nextcloud root path etc., or this data is overridden in server updates with the values from the server.ini? Please, can I have the link to this issue in the ISPConfig repo? I can't find it. Thank you! This is a great news! +1 for this.