[wp-trac] [WordPress Trac] #11884: mod_rewrite optimization

WordPress Trac wp-trac at lists.automattic.com
Thu Mar 10 00:06:32 UTC 2011


#11884: mod_rewrite optimization
-------------------------------+-----------------------
 Reporter:  Denis-de-Bernardy  |       Owner:
     Type:  enhancement        |      Status:  reopened
 Priority:  normal             |   Milestone:
Component:  Optimization       |     Version:  3.0
 Severity:  normal             |  Resolution:
 Keywords:  close 2nd-opinion  |
-------------------------------+-----------------------

Comment (by jvleis):

 Replying to [comment:11 sivel]:
 > In the only public example I have to show currently,
 http://paste.sivel.net/embed/24.js is not a real file.  It is generated
 similar to the way a post is.  The request comes in, the file doesn't
 exist so it is sent to index.php and processed.  WP_Rewrite has a regex
 pattern looking for this type of URL, and in the end gets the request to a
 custom template file within my theme, based off of internal query vars the
 same way that a post is rendered.  In this case I send the correct HTTP
 headers for a JS file, and output some JS.
 >
 > I have other applications built off of WP which are not publicly
 accessible which generate documents, css and images in this manner.
 >
 > So basically yes, requests to non-existent files such as image files,
 PDFs, JS are rewritten to index.php via the current .htaccess, which then
 processes the request using custom rewrite rules via WP_Rewrite, and
 delivers back the expected type of content.
 >
 > Adding rewrite rules to exclude images, js, css, etc would not permit
 this to work.
 >
 This argument seems to be the one that prevents more optimization of
 htaccess.  If one of the proposed modifications significantly improves
 page load times and decreases server load, then I ask you to consider this
 logic:

 1.  90%+ of WP users are likely not aware of htaccess, much less how to
 regenerate .js or .css files depending on conditional statements.
 2.  Those users who do understand how to do that are highly skilled in
 htaccess.
 3.  Therefore Sivel is arguing that millions of users run slower WP
 installations because a small minority of programmers, (a very small
 minority I suppose) do not wish to change an htaccess file they are
 already changing to make their modified systems work.

 I would ask the participants of these tickets to consider the foundational
 customer.  If WP can work out of the box at significantly less cost to
 hardware and reduced load times, then that should be the default.  It must
 be the responsibility of sophisticated programmers to alter that baseline
 scenario, not the other way around.

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


More information about the wp-trac mailing list