[wp-trac] [WordPress Trac] #44416: `compact()` will throw notice for undefined variables in PHP 7.3

[WordPress Trac]

#44416: `compact()` will throw notice for undefined variables in PHP 7.3
--------------------------+---------------------
 Reporter:  desrosj       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  5.0
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------

Comment (by desrosj):

 Dove into `wp_insert_post()`. Notices being thrown for the following
 variables not existing:

 - `$filter`
 - `$context`
 - `$ID` (`$post_ID` is used instead)
 - `$file`
 - `$post_mime_type`
 - `$category`
 - `$comment_count`
 - `$ancestors`
 - `$page_template`
 - `$tags_input`

 The first `compact()` call is causing all of the issues. This is because
 it is passing `array_keys( $postarr )` to the call, so all indexes passed
 to the function may not be represented in variable form. The second
 `compact()` call is not causing any issues because those variable names
 are manually defined in the `compact()` call and all exist.

 The result of the first `compact()` call is passed to the
 `wp_insert_post_parent` filter, which attempts to prevent hierarchy loops.
 Core has one function that hooks into this filter, but it does not even
 use the result of the `compact()` call.

 I think there are a few options here.

 **Make sure all documented `$postarr` arguments get a defined variable**

 This would fix the notice for all core values, but it would not fix issues
 where a plugin or theme is passing a custom value to `$postarr`. While
 some variables can just be moved above this first call (`$post_mime_type`,
 for example), it would also require defining new variables only for the
 purpose of avoiding a PHP notice, which makes me sway away from this
 option.

 **Manually define the variables to compact in the third argument of
 `wp_insert_post_parent`**

 This would ensure that PHP notices are never thrown (similar to the second
 call to `compact()` further down). But, it could cause a backwards
 compatibility issue. A value being used by a filter could start to be
 excluded. This is not a very well known or used filter, so communication
 in a Make post ahead of time could help prevent issues with this change.
 The filter could also be deprecated in favor of a new one. But this would
 not fix the notices.

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