Hook for ‘delete_option’ behaviour required

[RobertoDonPedro]

Hi, I posted this about one month ago in the wordpress support forum: ​https://wordpress.org/support/topic/hook-for-delete_option-behaviour-required/

I did not receive any answers there but referred to this forum, so I post it here again:

Hi, I would need to prevent and change the deletion of certain options by the WP core function ‘delete_option’.
There is a hook

do_action( 'delete_option', $option );

available here: https://core.trac.wordpress.org/browser/tags/4.9.4/src/wp-includes/option.php#L532

But this does neither provide a way to exit the delete_option function before the option is deleted nor to change the option name to be deleted. In fact this existing hook seems to be pretty useless.
Therefore I would need a filter in the first line of the delete_option core function like

$option = apply_filters( 'delete_option_name', $option );

.
Or change the line 535 from

$option = trim( $option );

to

$option = trim( apply_filters( 'delete_option_name', $option ));

Any chances to get this into core immediately?

Thx, Robert

[danieltj]

Hi @RobertoDonPedro, welcome to Core Trac.

It won't be possible to add this to Core straight away, but after reviewing the other similar functions such as add_option and update_option, they do both have methods are bailing out early through a filter.

I think this is a good idea and something worth exploring considering what is already available within Core, it would definitely bring the delete_option inline with the others.

I've tagged this as good-first-bug because I think this would be quite a nice one for someone new to have a go at.

Thanks!

[RobertoDonPedro]

Hi, it seams that the changes did not make it into 4.9.6.
Any reasons why? Is there something I need to do?
Thx, Robert

[palmiak]

Patch with added documentation

[kkarpieszuk]

@RobertoDonPedro in case it never is applied, you can use existing action to achieve what you want:

• get option into a variable which you know will be deleted in the moment
• modify it as you want
• add new option from a modified variable, if name is the same, the best will be to add it again when it is actually deleted (in deleted_option action, you can store variable as static to pass between actions)

So this is also a thing for code maintainers if it really must be merged into the code (still, it is better to add filter like this to modify option upfront than run additional SQL queries to delete and put option back in DB)

[RobertoDonPedro]

@kkarpieszuk My software is a highly available virtualization layer, therefore I cannot accept a solution where a required option gets deleted, even if it is just for a fraction of a second.

And I really do not understand why it is so hard to get this hook into core. The source is available yet, it does no harm and above this, it is completely in line with the already available hooks for add_option and update_option...

[kkarpieszuk]

Bear in mind I am not a core developer here :) That was just my side note how you could achieve it while waiting for merge :)

[donmhico]

Changed the new filter name to pre_delete_option and added unit tests.

[yannielsen]

I read and tested @donmhico patch and it works and looks to me as a viable solution.

[threadi]

Updated for WordPress 6.6.0

Added a filter to modify the option name, which can prevent certain options from deleting.

Trac ticket: WordPress Trac ticket 44042

[mindctrl]

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.