Curate system info data during support submission

[brashrebel]

I really, really want this but I don't know how we can do it. Basically, I would like to have a database where we store a record of all the data regarding system info submitted through support. The end goal is to be able to view reports on that data. For example, we could query this database to see the % of sites using a certain PHP version. Or we could see which themes are commonly used. Or which plugins.

Right now that info is only sent as a .txt attachment to the email. That is great and helpful in the context of the ticket but we don't keep any ongoing record of the configurations our customers have. How could we do this?

Can we send that data somewhere in addition to sending the email?
Can we attach that data to the email in another format and manually pull it into our database?
Where would this database even be and how would it be setup?

Does this just overlap way too much with #26 ? That might accomplish all the same things.

[joelworsham]

Hmmm that would be pretttttty cool

[d4mation]

This sounds like a duplicate of #26 to me. What you're describing is exactly what #26 lays out from what I'm reading here.

Similar to the Debug Email, individual "Parent Plugins" will be able to add their own Data to track to send back to RBP.com. It can then be graphed/displayed to get us information like % of sites using X feature. PHP Version would be a default piece of data sent for any instance of RBP Support, so that would be reportable as well.

[brashrebel]

I actually think they're not the same but overlap a lot. In #26 we'd be collecting data when people opt in to usage tracking. In this issue, we'd be collecting that same data when support inquiries are made. Those are different. Both can gather the same data though. It's just a question of when it is collected and whether the user knows they are providing it.

Perhaps this becomes our mechanism for updating an entry for a specific site. Either this or the usage tracking could create a new row in the database and then new support inquiries could additionally update that same row.

[d4mation]

Hm, having it send the data on Support Submission as well is a good idea. I don't know if I'd consider it a good substitute to having a generic cron running to send that data once a week or something, but it is definitely a good idea.

My main concern with "On Support Submission" being the only method updating the entries is that a fair amount of users don't know the Support Form is there (Mostly people who activated long before RBP Support was implemented in the plugin in question) so they go and fill out a contact form on RBP.com instead.

[brashrebel]

That's all true, though at the same time the question of how often we need to update the data and how important that even is should be raised. I don't believe it is super important to constantly update our data.

[d4mation]

Well, part of how I have the cron in my mind is that if they were to activate another one of our plugins, it would then send that new data (Since you only opt-in once for the site, not once per-Plugin) and it would also ensure any added data to a Plugin that had already sent data once before would have the opportunity to send after X amount of time has passed.

Even 1 week is probably too often, it was just an example time for a cron I threw in there. I do think there should be a cron though.