Simple thing! Just add this to your functions.php
:
/**
* This function modifies the main WordPress query to remove
* pages from search results.
*
* @param object $query The main WordPress query.
*/
function tg_exclude_pages_from_search_results( $query ) {
if ( $query->is_main_query() && $query->is_search() && ! is_admin() ) {
$query->set( 'post_type', array( 'post' ) );
}
}
add_action( 'pre_get_posts', 'tg_exclude_pages_from_search_results' );
With or without the:
/**
* This function modifies the main WordPress query to remove
* pages from search results.
*
* @param object $query The main WordPress query.
*/
...which seems like a tad unnecessary many characters for a quick description. In collective amounts, I wonder how much commentary as such bogs down runtime...
Source here.
Comments
The Comment Form
Privacy
Copyright
Sitemap
Statistics
RSS Feed
Valid XHTML
Valid CSS
Standards
© CyberD.org 2025
Keeping the world since 2004.
© CyberD.org 2025
Keeping the world since 2004.
Do comments increase runtime you ask?
Practically? No.
Theoretically? Not when using asymptotic time complexity. Reading comments is a constant operation of O(X) where X is the number of characters to be ignored. Constant operations are eliminated, per basic calculus/limits.
Indeed, a file with 1 GB of comments vs 1 KB worth of comments will noticeably take longer for reading and translating to bytecode on the server. This is just by virtue of having a large file. However, the translation process strips the comments and the code is cached.
So it doesn't really matter.
Also the comment here doesn't look unnecessary. It's concise, and the format of the comment suggests it can be read into a documentation generator.
Ah, a documentation generator, didn't know what was a thing... is the line length/split a part of that too? Or just common width in common commentary praxis?
Well it's not incredibly long, but little things amount, I have maybe ~a hundred of these altogether. Personally, I would've preferred a one-line something like '/* removes pages from search results */'
You already know it's a WP function by where it's included, and you can see what it modifies if you need to via the code itself.
But that's just me, as a not all that proficient coder. Just prefer minimal lines.
Good to know about the runtime! Potential load time would be the only issue then. It seems common practice these days to minify front-end scripts for example just to reduce size, though of course that's load time towards the end user more so than internal load time on server. Maybe it'd make virtually no difference there at all.
How the document generator process newlines would be up to its implementation. By default, I would expect it to process the text as is, including spacing. Other considerations for comment line width include larger, variable font sizes, wide margins, and table of contents panel that are oft the case with documentation/manuals.
You already know it's a WP function by what? The context of the source file it's written in? What if the function is moved elsewhere?
Indeed, you could make a case that the function is self-commenting, but the English is still quicker to read. Moreover, it's there for the sake of documentation, which is just good software practice.
Aha, good to know.
Yes, context of source file - or the file this is intended to be used in, functions.php, a theme file used specifically for WP functions that affect the core/main queries. It wouldn't work anywhere else as is, except maybe embedded in core files that aren't meant to be modified - which is why functions.php exists.
Maybe it is possible to use it elsewhere too, I can't say for sure, wouldn't be ideal usage though.
Mmm, that is a fair point. If it doesn't negatively impact runtime at all, and load time maybe also not at all, there doesn't seem to be much argument against it either. My bad for cracking down on brief commentary that does indeed provide certain benefit.