[wp-trac] [WordPress Trac] #48116: Proposal: Tracking PHP Extension Usage

[WordPress Trac]

#48116: Proposal: Tracking PHP Extension Usage
------------------------------------------------+--------------------------
 Reporter:  dd32                                |       Owner:  (none)
     Type:  enhancement                         |      Status:  new
 Priority:  normal                              |   Milestone:  Awaiting
                                                |  Review
Component:  Upgrade/Install                     |     Version:
 Severity:  normal                              |  Resolution:
 Keywords:  2nd-opinion dev-feedback has-patch  |     Focuses:
------------------------------------------------+--------------------------

Comment (by dd32):

 Replying to [comment:8 adamsilverstein]:
 > This would also be a great way to track php extension support for modern
 image formats such as WebP and help inform our decision about including
 them in core

 Agreed! That's a perfect example of it.

 The only request I have regarding additional data, is that it can be
 boiled down to a minimal list of things on the collection side,
 unfortunately the stats system is not really designed to track an
 arbitrary list of data points right now, especially when it's expected
 that a lot of sites will have those values set. The PHP Extensions even
 falls into this category, but I think the extra storage/complexity is
 worth it for something so generic.

 For example, the `gd_info()` call returns a list of key-values where value
 can be false, ideally we'd probably only send the truthful items over
 (That way, older versions which don't know about a flag is the same as a
 newer version that knows about it, but says it doesn't support it)

 I don't have any systems with `Imagick` installed, but it looks like that
 probably sends ~230 items that will most likely be set for all clients,
 storing those flags on a per-site basis is a lot of duplication when
 they're all probably going to be set.

 When we're only really interested in one or two pieces of that data, it's
 a lot to preemptively collect if not really useful.

 I guess, core can just send all of those datapoints, but on the collection
 side we'd boil it down to something like `GD Supports WebP`, `Imagick
 supports WebP`, or `Supports WebP: yay, nay`. Or other things like `PDF
 Support: yay, nay`.


 Replying to [comment:11 adamsilverstein]:
 > Can we work on adding this feature in 5.8?
 If someone wants to add it on the Core side, I'd be happy to see that.
 Someone else just needs to lead that, as I'd prefer someone else be
 involved :)

 > Are there matching changes we need on the collection side to gather this
 data?
 Yep! That'll be added once the data starts to be sent over to
 WordPress.org, there's no harm in sending it prior to dotorg actually
 handling collection for it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48116#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform