7 comments

1. The best place to flush rewrite rules is on plugin activation/deactivation.

   function myplugin_activate() {
       // register taxonomies/post types here
       flush_rewrite_rules();
   }
   
   register_activation_hook( __FILE__, 'myplugin_activate' );
   
   function myplugin_deactivate() {
       flush_rewrite_rules();
   }
   register_deactivation_hook( __FILE__, 'myplugin_deactivate' );
   

   See the codex article

   Apologies in advance, I didn’t make it all the way through your question, so this is a bit of a cookie cutter response.

2. Hard to tell what’s wrong, without seeing your code. But after saving some settings it’s practical to hook into admin_init like shown below to flush your rewrite rules.

   Code:

   add_action('admin_init', 'wpse_123401_plugin_settings_flush_rewrite');
   function wpse_123401_plugin_settings_flush_rewrite() {
       if ( get_option('plugin_settings_have_changed') == true ) {
           flush_rewrite_rules();
           update_option('plugin_settings_have_changed', false);
       }
   }
   

   You have to set the option some where at your settings page or to be exact some where in the process of saving the settings. Doing it without the option is bad, because you don’t want to flush the rules every time.

   Note: untested

3. I had a post types class file which was responsible for reading the plugin’s option settings, and creating the necessary custom post types based on the user specified settings.

   This post types class file was loaded on the hook init.

   I figured all I would need to do then was update the plugin settings, then flush the rewrite rules. Since the post types class was already loaded based off the plugin settings. But with administration pages, they’re loaded AFTER the init hook.

   The post types were never actually registered, because the settings weren’t actually set yet. The post types registration class ended up terminating prematurely with no post types registered.

   The solution was:

   1. Update the plugin settings.
   2. Load the post types class file ONLY one time here so that the new
      rewrite rules are created.
   3. Flush the rewrite rules.

   (Previously… step2 was missing — As mentioned above…)

   From now on, post types will be loaded on the init hook, and will have settings specified already, allowing post types to be created and paired with appropriate rewrite rules.

   For what ever reason, I had to add a JavaScript call to redirect to the current page, after performing the above three steps.

   I also had to add a call to flush_rewrite_rules(); on the plugin’s administration settings page.

   So for the sake of ensuring everything is flushed…

   Step 1) Navigate to plugin’s administration settings page. — Initial flush.

   Step 2) Update plugin settings. — Second flush.

   Step 3) Page redirects to plugin’s settings page. Causing the … Third and final flush (same as initial flush — Done automatically when plugin’s settings page is visited)

   I’m not saying this is a practical solution, but it worked for me. Very strange issue and most likely has to do with my coding infrastructure.

4. I was having exactly the same problem. In my plugin, I have post types that are dynamically created. They can therefore not be registered via register_post_type() in a static method during the activation_hook and are therefore not yet active when flush_rewrite_rules() is run during this hook (which is normally the recommended way of flushing rewrite rules).

   The cleanest solution I could come up with in the end was to flush the rewrite rules after registration of the post types, but of course only if such flushing was actually necessary (because the operation is slow). In my case I actually have several custom post types that inherit from a single base class and so it was desirable to implement the code that does the flushing there.

   Whether flushing is necessary can be decided by looking at the output of get_option( 'rewrite_rules' ):

   class MyPostTypeClass {
   
   public final function register_as_custom_post_type() {
       ...   //do all the setup of your post type here     
       $args = array(
                     ... //populate the other arguments as you see fit
                     'rewrite' => array('slug' => 'slug-of-your-post-type')
                    );
       register_post_type('post-type-name-of-your-post-type', $args );
   
       $rewrite_rules_must_be_fluhed = true;
       foreach( get_option( 'rewrite_rules' ) as $key => $rule)
           if(strpos($key, $args['rewrite']['slug'] ) === 0)
           {
               $rewrite_rules_must_be_fluhed = false;
               break;
           }
       if($rewrite_rules_must_be_fluhed)
           flush_rewrite_rules(true);
   }
   }
   

   Drawbacks:

   • Relies to some extent on which exact rewrite rules WP generates during register_post_type().
   • Checking whether flushing is necessary during each page load also creates some overhead.

   Advantages:

   • Fully encapsulated in the class representing the post type.
   • Only flushes the rewrite rules if really necessary.

   Only use this if you cannot register your post type in a static function that can call during both init and the activation_hook!

   The dependence on how the rewrite rules generated during register_post_type() look like can be mitigated by replacing the test if(strpos($key, $args['rewrite']['slug'] ) === 0) with something more elaborate, i.e., a regular expression.

5. @tazo-todua this worked for me too when using multisite.

   add_action( 'wpmu_new_blog', 'set_my_permalink_structure', 11, 2 );
   
   function set_my_permalink_structure( $blog_id ) {
   
       switch_to_blog( $blog_id );
   
       global $wp_rewrite;
       $wp_rewrite->set_permalink_structure( '/%postname%/' );
       $wp_rewrite->flush_rules();
       $wp_rewrite->init();
   
       restore_current_blog();
   }
   

6. If you want to flush_rewrite_rules when ANY plugin is activated or deactivated

   add_action('init', function(){
   
       // Get the path of every plugin installed
       $pluginsInstalledPaths = glob(WP_PLUGIN_DIR . '/*', GLOB_ONLYDIR);
   
       foreach ($pluginsInstalledPaths as $pluginPath) {
           // Get all PHP files available in the plugin root directory
           $files = glob($pluginPath . '/*.php');
           foreach ($files as $file) {
               $contents = file_get_contents($file);
               // If the file contains "Plugin Name" it is the main plugin file
               if (preg_match('//**[^/]*?Plugin Name:/', $contents)) {
                   add_action('activate_' . plugin_basename($file), function(){
                       flush_rewrite_rules();
                   });
                   add_action('deactivate_' . plugin_basename($file), function(){
                       flush_rewrite_rules();
                   });
               }
           }
       }
   });
   

7. MY found SOLUTION WAS:

   global $wp_rewrite; $wp_rewrite->flush_rules(); $wp_rewrite->init();
   

Comments are closed.