[wp-trac] [WordPress Trac] #44042: Hook for ‘delete_option’ behaviour required

[WordPress Trac]

#44042: Hook for ‘delete_option’ behaviour required
-------------------------------------------------+-------------------------
 Reporter:  RobertoDonPedro                      |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Options, Meta APIs                   |     Version:  1.2
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch dev-        |     Focuses:
  feedback has-unit-tests 2nd-opinion            |
-------------------------------------------------+-------------------------
Changes (by mindctrl):

 * keywords:  good-first-bug has-patch dev-feedback has-unit-tests => good-
     first-bug has-patch dev-feedback has-unit-tests 2nd-opinion


Comment:

 WP core prevents adding/editing/deleting certain options by running
 `wp_protect_special_option()`, which will run `wp_die()` when given a
 protected option name.

 Developers could use this same approach, using a custom function hooked
 into `delete_option` which dies when given the option name to be
 protected, but that method stops the execution of any remaining code.

 Thinking out loud here, but if I needed to prevent the deletion of some
 configuration or application data, I would probably not store it in the
 options table.

 An earlier comment said:
 > they do both have methods are bailing out early through a filter

 This isn't exactly accurate.

 `update_option` will return early if:
 - option name is empty
 - the old value matches the new value

 This technically makes it possible, but only to prevent errors and
 additional database calls. It isn't documented as a way to bypass updates.

 `add_option` will return early if:
 - option name is empty
 - option already exists

 In either case, the functions only allow filtering of the option value,
 not the option name. Ignoring for a moment the safety of allowing the data
 itself to be changed on the way in, I think it's more risky to allow
 developers to change the option name of the thing about to be deleted. The
 tests in the attached PR illustrate the potential danger. It would also
 make debugging more difficult.

 It would be safer to come up with a mechanism that allows early return
 without allowing the option name to be changed to a different string.

 Requesting a 2nd opinion.

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