Calling “flush_rewrite_rules” on every page load

Hi, In the includes/Manager/TemplateRedirection.php file of the plugin, on line 43 the following action is being added: add_action( 'init', array( $this, 'kirki_utility_pages_rewrite_rules' ) ); This action calls the following function: public function kirki_utility_pages_rewrite_rules() { $utility_pages = Page::fetch_list('kirki_utility', true, array( 'publish' ) ); foreach ( $utility_pages as $key => $page ) { $utility_page_type = $page['utility_page_type']; $id = $page['id']; $slug = $page['slug']; if ( $utility_page_type !== '404' ) { // Add custom rewrite rule for login add_rewrite_rule( "^$slug$", "index.php?kirki_utility_page_type=$utility_page_type&kirki_utility_page_id=$id", 'top' ); } } flush_rewrite_rules( true ); } This means the flush_rewrite_rules function is being called on every page load (line 115 of the file). Along with the true argument provided to the function, this causes a hard refresh which forces the .htaccess file to be rewritten on every page load. As per the WordPress Developer Resources , this operation can be extremely costly in terms of performance and should be called sparingly. Every attempt should be made to avoid using it in hooks that execute on each page load, such as init. Additionally, this has created a conflict with WPML which is sensitive to repeated .htaccess rewrites. Could you please review this code to see if it would be possible in a future update to avoid doing this flush on every page load? Regards, I have also stumbled upon this other support thread which I believe is very relevant to this as well: https://wordpress.org/support/topic/kirki-causes-500-internal-server-error/ Hi @devoctopix , Thank you for taking the time to investigate and share the code-level details. You are absolutely right in your observation. Calling flush_rewrite_rules() inside the init hook means it runs on every page load, which is not recommended in WordPress best practices due to performance and rewrite stability issues. We have already noted this issue and will inform our dev team this internally so the development team can review this implementation and evaluate a safer approach. We appreciate you highlighting this in such detail. We will update once a fix or improvement is available in a future release. Regards, Srijoni