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...
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
http://lists.automattic.com/mailman/listinfo/wp-hackers