Modifying ISPConfig, chances of getting it integrated upstream,…

Discussion in 'Developers' Forum' started by kwisarts, Jul 25, 2024.

Tags:
Page 2 of 2
  1. CubAfull

    CubAfull Member

    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 :(
     
    CubAfull, Aug 6, 2024
    #21
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    That's not a big deal; we just have to add the event then to this function, too, in the core.
     
    till, Aug 6, 2024
    #22
    CubAfull and ahrasis like this.
  3. CubAfull

    CubAfull Member

    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 class
    function loadFormDef($file, $module = '') {
            // EDIT: Removed because the array $_SESSION['s']['module']['name'] isn't set in the remote call.
    }
     
    Last edited: Aug 9, 2024
    CubAfull, Aug 6, 2024
    #23
    till likes this.
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
    till, Aug 6, 2024
    #24
    CubAfull likes this.
  5. CubAfull

    CubAfull Member

    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.
     
    Last edited: Aug 6, 2024
    CubAfull, Aug 6, 2024
    #25
    ahrasis likes this.
Page 2 of 2

Share This Page