[buddypress-trac] [BuddyPress Trac] #6448: Unconditional set of $wp_rewrite->use_verbose_page_rules = false breaks flush_rewrite_rules()

[buddypress-trac]

#6448: Unconditional set of $wp_rewrite->use_verbose_page_rules = false breaks
flush_rewrite_rules()
--------------------------+-----------------------------
 Reporter:  chherbst      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  API           |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+-----------------------------
Changes (by boonebgorges):

 * milestone:  Awaiting Review => Future Release


Comment:

 > As the problem only appears when flush_rewrite_rules() is called after
 BP has set use_verbose_page_rules to false I don't see how your suggestion
 to run flush_rewrite_rules() even later (with priority 999) should help
 solve the issue.

 Yes, you're right, I was confused. The "solution" would be for BP to do
 its own maneuvering later.

 >  This issue definitely also happens with other plugins

 If you come up with examples, please share them. I don't have access to
 LearnShare, and I'll need a reproducible example to think more clearly
 about a solution.

 In any case, I maintain that it's unwise, bordering on a bug, for plugins
 to flush rewrite rules at 'init'. It's not just because of the overhead.
 It's because plugins often register post types, taxonomies, and other
 rewrite-related content at 'init', and flushing the rewrite rules on the
 same hook can cause all sorts of race conditions like the one described in
 this ticket.

 I'll put this ticket in Future Release in the hopes that you or someone
 else can provide a freely available plugin that demonstrates the problem
 reliably.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6448#comment:4>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac