Tracking environment changes

[betweenbrain]

How do you plan on tracking environment changes? Is this something that will be tracked and stored for later analysis?

[dongilbert]

I have not thought that far ahead, but you are not the first one to ask about this, so I guess it should be considered. Any ideas?

[betweenbrain]

If you are not storing each submission, maybe do a comparison of the data being submitted and save it only if it has changed.

It looks like you are sending stats every 12 hours , so storing each submission could become fairly massive. While providing the most data for analysis, I'm not sure if you'd need all of it.

[Bakual]

You could just have a table where you store the change. But then I'm not sure if it is that important. The purpose of the plugin is to get data of current installations. We don't need to know who updated to which PHP version. We just want to know what PHP versions are used by how many people.

[betweenbrain]

We don't need to know who updated to which PHP version. We just want to know what PHP versions are used by how many people.

While I agree with that, it may also be helpful to know the rate of change. For example, if we are unsure about raising the minimum version of PHP, knowing how quickly people are upgrading, on average, might help that decision.

In my opinion, the more data you have, the better, even if you don't plan on using it right away.

[Bakual]

In my opinion, the more data you have, the better, even if you don't plan on using it right away.

Google and Facebook for sure share this opinion. 😄
From a user perspective I don't share this as a general statement.

Back to topic: It sure would be nice to have this data if possible. However if it generates a huge amount of data (what it probably will), then I'd more in favor of dropping that data and just stick with a live view without history.

[dongilbert]

There is still a lot of architecture to figure out. Overnight we had some guy think he was being funny or something and send in totally bogus stats, like Joomla 1.0 running on PHP 6.4.0, which obviously would never occur. So, we really need to find a way to validate the incoming data to ensure it has not been tampered with. Thats my top focus right now.

[eddieajau]

I think in these early stages of testing you want to capture all the data
you can, so I'd dump the entire $_SERVER variable in a field as well.

[Bakual]

Overnight we had some guy think he was being funny or something and send in totally bogus stats, like Joomla 1.0 running on PHP 6.4.0, which obviously would never occur.

Actually I would say this is a good tester. I'd like to see more of those. Don't just test the obvious but also try to hack around the system 😃

[dongilbert]

Well there is no way to prevent spoofing, so I am not sure what to do about that.

[dongilbert]

We can put constraints on the data, but there is nothing preventing someone from just spamming the site with their preferred setup, and saying 'Look at all the users on PHP 5.4.19 and running 3.x! We should totally drop support for everything else!'

[Bakual]

You could do some ip checking to prevent the same guy sending data multiple times with different ids. Or limit it at least to a certain value or something.
Validating of the data would need some sort of token which is handled out first between server and client or something. But that makes the whole thing just a lot more complicated.

To be a bit realistic: The more plugins are installed, the less a single user faking the data will have any impact on the outcome. So just promote the plugin well and the fakes become irrelevant 😄

[Bakual]

Another verification could be that the server makes a 'callback' to the plugin, verifying the id and maybe a property somehow. This would make it a bit harder to fake it. Just an idea.
However the server with the plugin must be public available which would rule out my intranet server 😄

[eddieajau]

What is firing the callback to the server?

[dongilbert]

It would make it more of a pain to fake, but still 100% possible.

[dongilbert]

The problem we have to address is that our plugin offers nothing to the user. WordPress uses this data to provide detailed update checks, and if an update is not compatible with the environment, they do not allow the user to install it. We have nothing to offer the user, at least along those lines.

I think keeping it as a plugin for 1.7-3.x, and then rebuilding the installer / updater to actually support PHP version checks for 4.0 will allow us to make this info mandatory and useful, thus less susceptible to spoofing.