flush_rewrite_rules( bool $hard = true )
Removes rewrite rules and then recreate rewrite rules.
Contents
Parameters
-
$hardbool Optional -
Whether to update .htaccess (hard flush) or just update rewrite_rules option (soft flush). Default is true (hard).
Default:
true
More Information
This function is useful when used with custom post types as it allows for automatic flushing of the WordPress rewrite rules (usually needs to be done manually for new custom post types). However, this is an expensive operation so it should only be used when necessary.
Source
File: wp-includes/rewrite.php.
View all references
function flush_rewrite_rules( $hard = true ) {
global $wp_rewrite;
if ( is_callable( array( $wp_rewrite, 'flush_rules' ) ) ) {
$wp_rewrite->flush_rules( $hard );
}
}
Changelog
| Version | Description |
|---|---|
| 3.0.0 | Introduced. |
User Contributed Notes
You must log in before being able to contribute a note or feedback.
Top ↑
Feedback
This is brilliant! I had to write a rewrite rule where I had to use
wc_get_page_id( '' ), and then run a flush_rewrite_rules, but at the point register_activation_hook() is called, WC isn’t even initialized, so I used your code to run the flush_rewrite_rules delayed enough and still only call it once after my plugin’s installation! Thank you very much for the idea! — By princeofabyss —If you want to flush rules while updating posts based on post type:
Top ↑
Feedback
flush_rewrite_rules() does not work on “save_post”, and instead of doing $_POST.. you can pass as a 2nd parameter like ($post_id, $post) and get $post->post_type — By ahsynv —
This is how you would flush rules on theme activation:
If you’re developing a theme, while building it you can use this snippet of code that will flush rewrite rules when the file containing it is changed, or every 48 hours:
Top ↑
Feedback
“Flushing” the rewrite rules should only happen in wp-admin, see https://core.trac.wordpress.org/ticket/44142. It is possible to do from the front-end while developing a theme or a plugin, but is a pretty bad idea if ever done in production.In that terms I’d add:
if ( ! is_admin() ) { return; }at the top of the above function. — By Andrew Ozz —A relatively simple way to flush rewrite rules on activation and deactivation hooks is not using flush_rewrite_rules() at all. Instead just clear the rewrite_rules option to force WordPress to recreate them at the right time.
Example:
This avoids having to do complicated stuff like registering your custom post types in the activation hook or throwing and catching dedicated db option or transients as suggested in other notes…
Top ↑
Feedback
Not sure why this contribution gets down voted but maybe it needs a bit more explanation… There is one big problem with
flush_rewrite_rules()when not called at the right time: it not only removes the old rewrite rules but also creates new ones, based on the (custom) post types and rewrite rules filters registered registered at that point in time. So if your plugin or theme callsflush_rewrite_rules()on an awkward moment where not everything is in place, wrong or incomplete rewrite rules will be generated. For example: when updating a plugin setting that warrants new rewrite rules, callingflush_rewrite_rules()from withing the option sanitization hook will likely cause problems. Or when calling it on a deactivation hook, without first removing your custom post type,flush_rewrite_rules()will likely not have the desired effect. Others like @nsrw0rk (up voted for good reason) have suggested an elegant solution: save an option to the database that will triggerflush_rewrite_rules()on the next init. But this will not always work, like in case of the deactivation hook (where the next init will be without your plugin) or in Multisite mode where rewrite rules can’t be flushed during switch to blog. So that is why I suggested the less elegant, but effective work-around:delete_option( 'rewrite_rules' ):) — By Rolf Allard van Hagen —This is how you would flush rewrite rules when a plugin is activated or deactivated: