All this trigger stuff is over my head but it seems we're missing the update trigger to decrement things. Beyond that though seems good to me.

I'd probably do the API response as a nested array though instead of how you've got it.

{
    "3.8.12": {
        "7.1.21": 1
    },
    "3.8.11": {
        "7.0.31": 1,
        "5.3.10": 1
    }
}

yes, sure the update trigger is currently missing.... i'm on this sorry i'm quite lazy 😄
but it is on my to do list with high priority ... coming soon...

I'd probably do the API response as a nested array though instead of how you've got it.

again yes, there are a lot of things that can be done in a better way.... and this is surely one of these...

what about the bin/stats install for the trigger sections issue
did you experienced it already ?

I haven't run the install command from a long time. I just do a DB backup if I need a current snapshot. So, no guarantees on the state of that command (or what issues it may or may not have with interacting in the database API).

added the update trigger

with the nested array now the response should be like this

This needs to go through buildResponseData or something similar to ensure the grouping/sanitization step takes place as required (remember the API does not allow access to get the full versions of everything without special permission, result sets are grouped generally on minor versions or the first word of the O/S name for those).

not sure to understand, 🤕 may i ask "someone else" to cover this side ?

He means using this function https://github.com/joomla/statistics-server/blob/master/src/Views/Stats/StatsJsonView.php#L179-L205 which if you notice calls a data sanitisation method.

yeah, but I still don't fully understand why, ect.. i know it's me 🤕

API does not allow access to get the full versions of everything without special permission

what special permission ?
i'm able to get the full info from API without any special permission

did you mean to expose the percentage instead of the total number of each items?
did you mean some kind of sort should be made on result before to expose them?

So, there's a check in the controller to determine if the requestor is authorized to get the full raw data from the database. By default, that isn't the case (actually right now the only way to get raw data is to go through the database, the config value for what that header allows to see raw data isn't even set).

In the view, after building the initial response structure (which is geared toward allowing the raw data), there is a check if the view is giving the raw data response. If not, the view pushes the data through the sanitizeData method which groups data on a key (so for things with versions those are grouped on <major>.<minor>, operating systems grouped on the first word) then gives a percentage instead of the raw total.

When authorized raw data, you get this response:

{
    "data": {
        "php_version": {
            "7.1.20": 5,
            "7.0.31": 5,
            "5.6.1": 3,
            "5.6.20": 5
        }
    },
    "total": 18
}

When not authorized raw data, you get this response:

{
    "data": {
        "php_version": {
            "7.1": 27.78,
            "7.0": 27.78,
            "5.6": 44.44
        }
    },
    "total": 18
}

reworked on #43