I noticed something interesting regarding the autoload column in the wp_options table on a WordPress site created with Local, and I wanted to check whether this is expected behavior.
In my Local environment, the autoload values are stored as:
on
auto
off
instead of the WordPress core standard values:
yes
no
Example:
SELECT autoload, COUNT(*)
FROM wp_options
GROUP BY autoload;
Result:
on 103
auto 75
off 47
Core options such as siteurl, home, blogname, template, and stylesheet are set to autoload = on.
After migrating this site to a production server (standard MySQL setup), I noticed some performance differences, which made me wonder whether this difference in autoload values could affect how WordPress loads options.
I’m not sure if this is:
An intentional optimization in Local
A database configuration detail specific to Local
Or something I should normalize before migration
Has anyone else seen this behavior?
Is this expected in Local, or should autoload values ideally remain yes/no for compatibility with standard WordPress environments?
Security Reminder
Local does a pretty good job of scrubbing private info from the logs and the errors it produces, however there’s always the possibility that something private can come through. Because these are public forums, always review the screenshots you are sharing to make sure there isn’t private info like passwords being displayed.
Would you be able to confirm if you’re utilizing the same WordPress version between your hosted site and your Local site? It sounds like this might be version mismatch issue and not a Local one.
Great catch noticing those values! I remembered something I read recently about autoload options, and had to go back and do a little research. Turns out, this is actually expected WordPress behavior, not anything specific to Local.
WordPress 6.6 introduced new autoload values (on, off, auto, etc.) as part of a performance optimization to better manage which options get loaded on every page request. The old yes/no values were deprecated in WordPress 6.7,
though they still work perfectly fine for backward compatibility.
The good news: you don’t need to change anything before migrating to production. WordPress treats these values identically to the legacy yes/no format, so your database will work just fine on any standard MySQL setup.
Thanks so much for the detailed explanation — and for sharing the dev note. I really appreciate it.
I was actually checking this on a site that had originally been installed on a version prior to WordPress 6.5 and later updated. Because of that, the existing autoload values remained as yes/no, which is why I didn’t immediately notice the changes introduced in WordPress 6.6.
Your explanation makes perfect sense, and it’s reassuring to know that WordPress handles both formats identically for compatibility.
Thanks again for pointing me in the right direction — and for the link to the technical details!