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

[WordPress Trac]

#48116: Proposal: Tracking PHP Extension Usage
------------------------------------+------------------------------
 Reporter:  dd32                    |       Owner:  adamsilverstein
     Type:  enhancement             |      Status:  assigned
 Priority:  normal                  |   Milestone:  6.0
Component:  Upgrade/Install         |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |     Focuses:
------------------------------------+------------------------------

Comment (by dd32):

 My comments from Comment [comment:12] still stand.

 PR 1096 is [attachment:"48116.2.diff"] which has the "benefit"/"downside"
 that:
  - WordPress.org has to parse the gd/imagick arrays into what data to
 record.
  - We don't really know what data will be in those payloads in the future
 and whether it might potentially contain PII data.

 [attachment:"48116.3.diff"] is an iteration on that, post comment
 [comment:12] suggestions that:
  - Shifts the logic to the client for GD, looking for `WebP, AVIS, HEIF`
 support.
  - Passes the All the Imageick supported formats through, instead of
 selecting which ones. Perhaps an `array_intersect` with
 `$supported_formats` is needed (see next)
  - Comment [comment:21] still applies. It seems that the second
 `$gd_supported_formats` with static array was supposed to be called
 `$supported_formats` perhaps?

 Doing the parsing on WordPress.org (per [attachment:"48116.2.diff"]) has
 some benefits though;
  - If new versions of the libraries change the format they report in, we
 can handle it there.
  - If we decide we need to record data about some new flag that is present
 in the GD/Imagick data, we can do so.

 That all being said, I now question what flags need to be sent/recorded.
 Do we really need to know how many sites support WebP and AVIF? Yes, it
 would've been nice to know before we implemented webp support how many
 sites could generate it, but that time has passed.. Likewise for PDF
 support (Which [attachment:"48116.3.diff"] might prevent if GD supports it
 in the future?)
 So perhaps doing the parsing on the API side is the best course of action,
 and we just discard the data until a time comes where we actually want to
 know the stats it will provide?

 Increasing the payload size also has detrimental impacts upon the
 processing speed of the API requests and time it takes to run, also the
 length of time it takes the stats processing to run, etc.

 So...
  - I'm okay with [attachment:"48116.2.diff"] or
 [attachment:"48116.3.diff"] (with fixes)
  - I question the need for the GD/Imagick data, but no harm
  - Please ensure that the payload size doesn't bloat up with irrelevant
 information
  - Please define the stats wanted to be recorded from GD/Imagick,
 something that 99% of sites support is not a good data-point for us to
 record.
  - Stats based on the submitted data likely won't be available for
 sometime, as we'll need to add the recording/generation code for it,
 determine what to generate daily/weekly/monthly/on-demand/etc.

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