[wp-hackers] Avoiding option cacheing for a specific option

[Bart Schouten]

Generally speaking, seeing that there are two obvious places:

- either in the option handling routines
- or in the caching routines themselves.

You would think that the option layer would be most suitable since it is 
the calling agent, BUT, there are many routines and many of them can call 
wp_cache_set() (or wp_cache_add() ) under various circumstances.

Then the caching functionality itself becomes the proper place to 
filter... and the only thing that makes sense to me is to add a filter to:

WP_Object_Cache->set();

On the other hand, that would filter everything, not only options. Perhaps 
the only places where a new option is added is add_option and 
update_option. Then you only need to add a filter on the option name. 
There are already various filters on the option /value/ but nothing on the 
option /name/ and filtering on the value itself (you could set it to zero, 
or null) does not really semantically coincide with not wanting to set any 
value at all.

Also, there seems to be a remnant of a named filter:

$value = apply_filters( 'pre_update_option_' . $option, $value, $old_value 
);

which probably should have been

$value = apply_filters( "pre_update_option_{$option}", $value, $old_value 
);

Oh, apologies, I'm misreading. The code further down uses this latter 
syntax instead of the existing.... they are the same :p.

But I don't think you can really use that to filter the option itself. If 
you set it to null, it will just still get set, it's just getting set to 
null and retrieved as null. PHP isset() does not coincide with is_null(). 
Or "=== null". So it won't work.

So my input here would be to add a filter next to these pre_update_option 
filters called pre_update... something. On the other hand, if the option 
does not in fact exist, add_option is still called.

Then you just need to add two filters, probably, to remain with the 
current design, one general one and one named one, to add_option.

Regards,

Bart.

ps. when I wrote this I didn't much think about why you would need it. But 
I'm not sure you are referring to in-memory database-caching. There is 
also another form of caching that is sometimes used, which is storing 
calculated results as options in the option db. This form of caching can 
invalidate, so to speak, the current database contents because the 
existing 'cache' will supersede getting new results from the db. This 
makes it hard to e.g. manually change certain things such as categories in 
the DB, because category hierarchy-lists get cached and you will see like 
corrupted category lists all over WordPress. But this form of caching is 
persistent, not temporary or transient.

If, in fact, your options are getting changed from outside of WP or 
through some other means than the regular WP calls, I guess the regular 
in-memory caching could also be a problem...



On Sat, 20 Sep 2014, David Anderson wrote:

> Hi,
>
> Where in WP core is the architecturally correct place to make sure that a 
> specific option is never cached?
>
> I'm not asking about how to do this via a plugin - I'm working on a patch to 
> do with an issue caused by cacheing an option that would just be better never 
> cached.
>
> Best wishes,
> David
>
> -- 
> UpdraftPlus - best WordPress backups - http://updraftplus.com
> WordShell - WordPress fast from the CLI - http://wordshell.net
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>