Plugins should be able to be downloaded, installed, and upgraded from Plugin Management

[netniV]

Plugins should be automatically disabled if the version is no longer available or the number is different to that listed. This will prevent issues where the upgrade hasn't been performed because no one has visited the /plugins.php or /plugin/<pluginname>/<file.php> where the file is listed in a check such as:

$files = array('plugins.php', 'monitor.php');
if (isset($_SERVER['PHP_SELF']) && !in_array(basename($_SERVER['PHP_SELF']), $files)) {
    return;
}

This could be an issues as the plugin may have poller-based functions that are called without a DB upgrade having been performed. A notification should be sent to the default admin (as per 1.2)

[cigamit]

I disagree. I think we need to support upgrading the plugins from the Plugin Management page including 1) Check for new version from GitHub (custom repo), 2) Downloading and uncompressing, 3) Running upgrade function.

Additionally, we need a CLI script for upgrading a plugin for packagers. Which can include running the plugins upgrade function.

[netniV]

I have seen many times errors appear in a log file just randomly due to an upgrade in progress or an upgrade not performed especially when said plugin as poller hooks. So I disagree with your disagreement ;-)

If INFO <> PLUGIN_CONFIG there is a problem and it should be treated the same as PHP ERROR. If the plugin flags the upgrade as done, and it then matches, if previously disabled it could be re-enabled.

[cigamit]

We can then perform upgrades more aggressively instead of waiting for someone to goto the page. This was done in early plugin development not to travel down too many code paths which would add lag to the user interface. I'm okay if we add a hook during either page initiation or in global.php to auto-upgrade.

[cigamit]

My feeling is that moving forward, most upgrades are going to be handled directly from plugin management, so taking a more aggressive approach, is not a bad thing.

[netniV]

10/02/2018 20:02:12 - AUTOM8 [PID: 30988] Not time to Run Discovery for 'Test Network'
10/02/2018 20:02:11 - CMDPHP SQL Backtrace: (/poller.php[767]:api_plugin_hook(), /lib/plugins.php[74]:api_plugin_run_plugin_hook(), /lib/plugins.php[177]:reportit_poller_bottom(), /plugins/reportit/setup.php[629]:db_execute_prepared())
10/02/2018 20:02:11 - CMDPHP ERROR: A DB Exec Failed!, Error: Table 'cacti_site.plugin_reportit_reports' doesn't exist
10/02/2018 20:02:05 - SYSTEM STATS: Time:3.5117 Method:cmd.php Processes:1 Threads:N/A Hosts:3 HostsPerProcess:3 DataSources:56 RRDsProcessed:39

This is an example of the plugin kicking in during an upgrade. I was testing plugin_reportit and it's bottom poller hook kicked in whilst the DB was being upgraded. A corner case but one that could cause issues on a larger/slower upgrade.

[cigamit]

Yup, we need to change the install/upgrade process. We could either download updates directly from the internet, or like what we do with templates, we could simply allow the user to upload the updated plugin and perform the install/upgrade directly.

[TheWitness]

Some progress.

Download Data into Table 'plugin_available'

GitHub Personal Access Token:

Next, I will make the download process download the archives for each release and for the current develop. More changes coming before I start to update the UI.

[TheWitness]

MariaDB [cacti]> select name, tag_name, compat, length(archive) AS archive_length from plugin_available order by name, tag_name;
+---------------+----------+--------+----------------+
| name          | tag_name | compat | archive_length |
+---------------+----------+--------+----------------+
| apcupsd       | develop  | 1.2.24 |         192952 |
| apcupsd       | v1.1     | 1.2.24 |         192952 |
| audit         | develop  | 1.2.20 |          70189 |
| audit         | v1.2     | 1.2.20 |          70189 |
| cycle         | develop  | 1.1.22 |          84157 |
| cycle         | v4.1     | 1.1.22 |          84157 |
| flowview      | develop  | 1.2.28 |        2101727 |
| flowview      | v4.8     | 1.2.28 |        2101727 |
| gexport       | develop  | 1.2.15 |         180254 |
| gexport       | v2.1     | 1.2.15 |         180254 |
| gpsmap        | develop  | 1.1.17 |         569476 |
| gpsmap        | v2.1     | 1.1.17 |         569476 |
| hmib          | develop  | 1.2.25 |         294924 |
| hmib          | v3.5     | 1.2.25 |         294924 |
| intropage     | develop  | 1.2.17 |         568766 |
| intropage     | v4.0.4   | 1.2.17 |         568766 |
| mactrack      | develop  | 1.2.14 |        3529538 |
| mactrack      | v4.8     | 1.2.14 |        3529538 |
| maint         | develop  | 1.2.0  |          77296 |
| maint         | v1.1     | 1.1.10 |          77296 |
| mikrotik      | develop  | 1.2.24 |         404280 |
| mikrotik      | v3.1     | 1.2.24 |         404280 |
| monitor       | develop  | 1.2.15 |        3904076 |
| monitor       | v2.8.1   | 1.2.15 |        3904076 |
| quicktree     | 1.1      | 1.1.9  |          55093 |
| quicktree     | develop  | 1.2.17 |          55093 |
| reportit      | develop  | 1.2.27 |        1808422 |
| reportit      | v1.1.4   | 1.2.27 |        1808422 |
| routerconfigs | develop  | 1.2.23 |         302600 |
| routerconfigs | v1.6     | 1.2.23 |         302600 |
| syslog        | develop  | 1.2.23 |         471013 |
| syslog        | v4.2     | 1.2.23 |         471013 |
| thold         | develop  | 1.2.25 |        1149186 |
| thold         | v1.8.2   | 1.2.25 |        1149186 |
| weathermap    | develop  | 1.2.24 |        4306365 |
| weathermap    | v1.3.1   | 1.2.24 |        4306365 |
| webseer       | develop  | 1.2.24 |         260824 |
| webseer       | v3.2     | 1.2.24 |         260824 |
+---------------+----------+--------+----------------+
38 rows in set (0.005 sec)

MariaDB [cacti]>

[TheWitness]

This is complete now for 1.3.