WordPress get_query_var Example: Read Custom Query Vars Safely

Last reviewed: May 13, 2026

Developers often assume that any value on the URL can be retrieved cleanly with get_query_var(). That is only partly true. The helper reads query variables known to WP_Query, and custom variables have to be exposed to that system first. Without that step, the lookup silently fails and the code starts guessing.

This guide shows how to read public query vars safely and what has to happen before custom query vars become available through the helper.

Read recognized query vars with an explicit default

<?php
$section = get_query_var( 'vulnwp_section', 'overview' );

if ( ! in_array( $section, array( 'overview', 'timeline', 'evidence' ), true ) ) {
	$section = 'overview';
}

The explicit default makes it clear what the code expects when the query var is missing or not yet registered.

Expose custom query vars before expecting them to resolve

The WordPress code reference is direct on this point: get_query_var() only retrieves public query variables recognized by WP_Query. For a custom query var, add it through the query_vars filter before using it as part of your route logic.

Do not treat retrieval as validation

Getting a value from get_query_var() does not make it acceptable for template branching, database lookups, or access decisions. Just like request input from other sources, the final value still needs allowlisting or type validation.

Common mistakes

• Expecting custom query vars to work without registration. WordPress will not expose them automatically.
• Skipping a default value. The fallback path becomes less explicit.
• Using the retrieved value directly for sensitive branching. Validation still matters.
• Confusing front-end query vars with admin request handling. Query behavior is context-dependent.

Production checklist

• Use get_query_var() only for public query variables recognized by WP_Query.
• Register custom vars through the query_vars filter before reading them.
• Provide explicit defaults at the read point.
• Validate the final value against the expected set.
• Retest route behavior after permalink or rewrite changes.

Related reading

Pair this with the add_rewrite_endpoint guide when the query var comes from a custom endpoint and with the flush_rewrite_rules article when routing changes need a safe one-time refresh.

References and further reading

• WordPress Code Reference: get_query_var()
• WordPress Hook Reference: query_vars filter
• WordPress Code Reference: add_query_arg()