Problem
Currently, resolve_content() fires for every SELECT on wp_posts that includes post_content (which is most queries, since WordPress uses SELECT *). This means even admin list tables and count queries trigger file reads, even though they don't display content.
Proposed solution
Phase 4 of the Index/Map Architecture:
- Detect metadata-only queries: queries where content is selected but never used (admin list tables, REST collection endpoints with
_fields, WP_Query with fields => 'ids')
- Use the
posts_fields filter: WordPress fires this filter on WP_Query — we can detect when content is excluded
- Lazy-lazy resolution: instead of resolving content in
query(), resolve it in the_content filter or when $post->post_content is first accessed
Impact
Low priority — file reads are ~0.1ms each. For a listing page with 20 posts, that's 2ms total. But for admin pages with 100+ posts, it adds up.
Context
Phase 4 of the Index/Map Architecture (PR #41).
Problem
Currently,
resolve_content()fires for every SELECT on wp_posts that includespost_content(which is most queries, since WordPress usesSELECT *). This means even admin list tables and count queries trigger file reads, even though they don't display content.Proposed solution
Phase 4 of the Index/Map Architecture:
_fields, WP_Query withfields => 'ids')posts_fieldsfilter: WordPress fires this filter on WP_Query — we can detect when content is excludedquery(), resolve it inthe_contentfilter or when$post->post_contentis first accessedImpact
Low priority — file reads are ~0.1ms each. For a listing page with 20 posts, that's 2ms total. But for admin pages with 100+ posts, it adds up.
Context
Phase 4 of the Index/Map Architecture (PR #41).