I’ve been working on modifying WordPress option values using the dynamic pre_option_{option} filter. Everything works fine with that approach. Now I want to extend this functionality to also modify options when they get loaded through the wp_load_alloptions() function.
WordPress provides the pre_cache_alloptions hook for this exact purpose, but I’m running into timing issues. The problem is that wp_load_alloptions() gets called extremely early in the WordPress loading process, and the results are cached after the first call.
I’ve tried registering my filter using add_filter('pre_cache_alloptions', ...) in several locations:
Inside a must-use plugin
In my theme’s functions.php file
Unfortunately, none of these locations seem to execute early enough. The only method that actually works is directly editing the core wp-includes/plugin.php file and adding my filter right after the class-wp-hook.php require statement. While this approach works perfectly, I really don’t want to modify WordPress core files.
Is there a proper way to register this filter early enough without touching core WordPress files? What’s the recommended approach for hooking into pre_cache_alloptions before the initial options load?
honestly the mu-plugins folder timing might still work if you name your file with numbers at the start like 000-early-hook.php. wordpress loads mu-plugins alphabetically so it runs before most other stuff. i had similar issues with early hooks and this trick saved me from drop-in complexity.
Been dealing with similar WordPress timing headaches for years. You’re fighting against WordPress’s loading sequence - that’s the real problem.
Forget trying to catch that super early hook. Step back and automate this whole thing differently. Monitor your WordPress options table directly and modify values before they hit the cache layer.
I built something like this for a client who needed dynamic option changes across multiple WordPress sites. Used Latenode to create a database monitoring workflow that:
Watches for specific option queries
Intercepts data at the database level
Applies transformations before WordPress sees it
Handles caching logic separately
This completely bypasses the timing issues since you’re working outside WordPress’s initialization sequence. No more wrestling with hook priorities or worrying about when filters get registered.
The workflow runs independently and handles multiple sites at once. Plus you get proper logging and error handling that’s impossible with the core hook approach.
Way cleaner than hacking into WordPress’s boot process or modifying core files.
Try an object cache drop-in - it’ll fix your timing issue without the headache of database monitoring. WordPress loads /wp-content/object-cache.php before the options system starts up, so you can hook in at exactly the right moment. I hit this same problem building a multi-tenant WordPress setup where I needed to modify options per tenant. The object cache drop-in worked perfectly because it runs during cache initialization, before wp_load_alloptions() gets called. Just create an object-cache.php file that registers your pre_cache_alloptions filter. You can either do a simple pass-through cache or connect it to Redis/Memcached if you’re already using those. The magic is that WordPress includes this file early enough in the bootstrap to catch that first options load. I’ve been using this method through several WordPress updates with zero issues, and you don’t need external monitoring or database tweaks.
Drop-in plugins are what you need. Create /wp-content/db.php and WordPress loads it before the options system starts up. It runs earlier than must-use plugins and way before theme functions.
I’ve done this when building custom caching layers that had to intercept database queries before WordPress loaded its standard options. The db.php drop-in gets included right after the database connection but before any options load.
In your db.php file, just register the pre_cache_alloptions filter and it’ll catch that first wp_load_alloptions() call. Don’t forget to include the standard $wpdb instantiation at the bottom or you’ll break the database connection.
This is officially supported by WordPress core and way cleaner than modifying plugin.php. I’ve been using it for complex option stuff for three years now - zero issues across WordPress updates.