Hi and thank you in advance for any help. I am in the middle of experimentation with ISPConfig, I already managed to set my custom plugin, remote function and module. The remote function aims to trigger the creation of a new site webdomain and immediately proceed with installing a Joomla Site on it (kind of an App Installer). I set the plugin to listen to the event triggered when a new site webdomain is added, and then I should do the installation. Didn't yet finished that, but I think that is the way to go as the plugin has access to the server it should be able to do the job. Now, I would like to have multiple Joomla versions (major ones) and to know if a site is based on Joomla 4 or Joomla 5 for example. In order to do so, I thought on extending the web_domain table as long as there is a proper way of doing so. I don't want to mess with the core code, instead override/expand it withing my module/code. This is where I need help the most: 1. Is that even possible. Can I extedn the core without hard coding it? 2. If not, what would you suggest instead? Perhaps create a custom interface and table where to list "Joomla Apps" and their metadata? Kind regards, Miljan
That's the right approach. Just ensure that your plugin name comes after the Apache or Nginx plugin in the alphabet to ensure your code is after the website has been created. You can add new columns in the database web_domain table, just take care that you use e.g. a prefix to ensure that they will not collide with possible future columns added by ISPConfig. The interface also has two types of plugins, but I fear there is no documentation on that. One is an event-based plugin that allows you to run code, e.g., when a website gets updated, the event name for that would be, e.g., "sites:web_vhost_domainn_after_update" or in case a website gets inserted, it "sites:web_vhost_domainn_after_insert." You can find them in interface/lib/plugins/. There are also events that trigger early in form processing, like "sites:web_vhost_domainn_after_formdef," triggered right after the form handler has loaded a form definition. The second type of plugins are UI plugins that implement special functionalities that the default form handler can not do, like the backup list or the list of DNS records that is included inside a normal form. you can find them in interface/lib/classes/plugin_* One important thing to note when working with interface plugins is that the events are stored in the session, so when you add a new plugin, you must log out and log in again once, as the system scans for new plugins and their event handlers just once when you log in.
Thank you Till for your prompt answer. I will take into account your suggestions while getting forward with this project. Cheers!
