[wp-trac] [WordPress Trac] #50434: Replace the `$new_whitelist_options` variable with a more inclusive name

[WordPress Trac]

#50434: Replace the `$new_whitelist_options` variable with a more inclusive name
--------------------------+---------------------
 Reporter:  desrosj       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  5.5
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+---------------------

Comment (by desrosj):

 I was having issues with [attachment:"50434.2.patch"] applying cleanly so
 I recreated the changes in a PR on GitHub attached to the ticket above.

 I removed the inline `@deprecated` documentation tag where the variable
 was passed by reference. I could not find any other instances in Core
 where something had a `@deprecated` tag inline, except action and filter
 hooks.

 Based on an [https://wpdirectory.net/search/01ECQA23HYAXM4JS48EMQYKF8C
 initial scan of the plugin directory], it does not seem like this change
 should be too problematic. A lot of the instances being flagged on that
 search are caused by the plugin bundling the WPCS sniffs, which includes
 checks for the variable.

 @ayeshrajans I did have one question on the patch. What is the need to
 pass the new variable by reference in `unregister_setting()`? Is this to
 ensure that if a a plugin or theme manually erases and repopulates the
 global the setting is correctly unregistered?

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