[wp-trac] [WordPress Trac] #12324: Broken .htaccess File Created By WP 2.9.2

[WordPress Trac]

#12324: Broken .htaccess File Created By WP 2.9.2
--------------------------+-------------------------------------------------
 Reporter:  magblogapi    |        Owner:  ryan    
     Type:  defect (bug)  |       Status:  reopened
 Priority:  normal        |    Milestone:          
Component:  Permalinks    |      Version:  2.9.2   
 Severity:  normal        |   Resolution:          
 Keywords:                |  
--------------------------+-------------------------------------------------

Comment(by kevinB):

 Okay, no hard feelings.  If I am overly defensive it's just because I've
 put an enormous amount of time into a plugin that has thousands of users
 but only one active technical advocate.  Despite developing and supporting
 a broad layer of features, I am perpetually vulnerable to the anonymous
 and non-descript "broken" vote whenever a single feature malfunctions (or
 appears to malfunction) on any WP configuration.  This is the context of
 my protest at the "may be doing more damage" comment.  I'd like to develop
 more of a team-like relationship with WP core contributors, but haven't
 attained that yet.

 magblogapi sent me some info on his configuration.  It looks like in this
 case there is another plugin which calls $wp_rewrite->flush_rules()
 unconditionally at plugin init.  So my theorized sequence of events, when
 2 or more site accesses occur simultaneously, is:

 1. other plugin triggers .htaccess update at every site access
 2. Role Scoper hooks the mod_rewrite_rules filter to append its custom
 rules
 3. WordPress function '''insert_with_markers''' checks contents of
 .htaccess midway through another pending update process.  Since .htaccess
 is partially written, BEGIN / END markers are not found so the content is
 appended redundantly instead.

 So this is not so much a multi-threading issue as a multi-access issue, as
 described in #11903.

 It doesn't really matter to you '''which''' plugin is calling
 $wp_rewrite->flush_rules() on every site access.  I've done it before, and
 might make that mistake again in the future.  The main point is that if
 the WP API is right, simultaneous / redundant calls to
 $wp_rewrite->flush_rules() should manifest as a performance hit or a
 temporary 500 error, not a permanent 500 error.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/12324#comment:12>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software