Support » Requests and Feedback » WordPress's .htaccess file is suboptimal

  • The .htaccess file that WordPress generates during installation is suboptimal.

    The primary issue is that, “out-of-the-box”, the .htaccess file functions properly only when the location of the WordPress installation does not change.

    In a collaborative, version-controlled environment, it is unreasonable to expect that every developer places every WordPress project in his Web-server’s document root. However, the .htaccess file at the root of the installation seems to be generated with this expectation.

    I hardly ever use WordPress, so I can’t speak to the evolution of this issue, but I seem to recall WordPress including the .htaccess file in the actual source package at some point in the past (as opposed to the file being generated dynamically during installation). If my recollection is correct, perhaps the fact that the file is generated dynamically now is in an effort to address the issue I’ve outlined herein.

    The following issues are at the core of why clean-URLs are not accessible when the WordPress installation is not at the Web-server’s document root:

    a.) the leading / before index.php in the last rule (RewriteRule . /index.php [L]); and

    b.) the RewriteBase / directive

    Again, I don’t know enough about WordPress to know whether the proposed adjustments will “break” other functionality, but it seems that two simple adjustments would alleviate this problem entirely.

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . index.php [L]
    # END WordPress

    With these two changes, I am able to move the WordPress installation to any subdirectory of the Web-server’s document root and clean URLs continue to function as expected.

    As a related corollary, the above changes do not address the fact that WordPress stores core configuration directives in the database, so the developer will still need to adjust the ‘siteurl’ and ‘home’ values in the wp_options database table whenever the installation is moved.

    P.S. This forum software is inserting HTML markup into my post (specifically, between the code tags) whenever I edit the post.

Viewing 4 replies - 31 through 34 (of 34 total)
  • content should never be tightly tied to context

    I can not express how wrong that is.

    absolute URLs in the post content makes migration easier, not harder. It becomes a simple search/replace operation to fix URLs instead of a complex regexp nightmare.

    How is replacing: “[site_url]” a complex regex nightmare in comparison to replacing “”. Seems like it’s really obvious simple string replace to me.

    But as we know, using a string replace for the database migration doesn’t work because of the number of dependancies on site_url /home that have been hardcoded in multiple places.

    The issue with hardcoded URLs in the content not being context specific is that it has decided that every link/content-type should be treated in the same way. This is inherently wrong. Images, Videos, Text, Links = all different.

    Take my example above, where we gave all of our media a different shortcode so that we could replace the referenced variable in the config file for a medium (e.g. Video, or images) and point them towards a CDN or a Video Content provider. etc etc. We did that because the hardcoding of urls required complex regexing when we only wanted to change something content-specific.

    I think your point is actually one of my/other-cms-folks great disconnects with WP. Every square peg is hammered into the round hole of “posts” with no regard to the actual context. Custom Post Type rather than Custom Content Object.

    Context is really where we’re failing as a CMS.


    My point is this, and yeah its the same drum I’ve been banging for the last 4 years:

    ” Why do something in a way that locks down the code to only work in one situation, when coding it in a different but NO MORE COMPLEX way allows it to be extendable? ”

    Thats a quote from me from the bbPress website in 2008.

    I mean, lets take the fact that comment moderation REQUIRES the ability to edit any content on the website. Although these are two different roles and capabilities, we’ve HARDCODED them to be linked.

    There are countless examples of where we’ve made decisions based on what simply works for the 80%, and we all know thats 50% “.com” and at least 30% “bloggers”. I totally understand that pre WP3.0, but we (supposedly) made the mental shift from blogging to CMS after 2.9 in 2009. I’m not seeing it.

    I’m seeing amazing developers, i’m seeing amazing community, i’m seeing amazing effort, i’m seeing amazing code… but I’m not seeing the mental shift.

    How is replacing: “[site_url]” a complex regex nightmare in comparison to replacing “”. Seems like it’s really obvious simple string replace to me.

    The way I see it, both methods are fairly expensive when it comes to processing. As it stands, post content is filtered minimally for certain shortcodes. Not a big deal, but can become one when you start installing several additional plugins.

    That said, I’d much rather parse content and replace [site_url] than parse and replace It’s a more explicit flag that content needs to be replaced (think of email addresses, for example).

    Using the 80/20 rule, though, the majority of users will never need this kind of flexibility. Much of these users will also be running in an uncached environment, meaning any post processing will add significant server load for every post that includes links.

    That said, I can definitely see the benefit for specific groups of users and would love to see this kind of functionality extended via a plugin. Simply drop the plugin into your site and parse [site_url] like any other shortcode. Also, override the link editor to automatically insert that shortcode rather than the site URL.

    I can see the value for some users, and someone (me, another dev, anyone with interest) should look into coding this out.

    Hi Eric,

    Here’s my issues with that:

    I suppose the thing that gets me, and possibly something that people don’t like about me, is that I’m not big on the unintentional hypocrisy in Software Development (not just in WP by a long shot).

    e.g. I’m all for worrying about processing costs, but then lets not make 32Mb a minimum for a WP install πŸ˜‰

    I’m the same when we talk about putting users first (hello: capital_p) and making WordPress accessible to all (hello: WP3.3’s hover-only-menu means it falls foul of UK & EU accessibility and discrimination laws).

    It’s kind of why 80/20 doesn’t work. We know that 80% are a combination of “” and “bloggers”. So everyone else is always going to be in the 20%. And that 20% is a mighty large number!

    I mean really, who remembers the core-team proposed roadmap where user management (roles, capabilities etc) was next on the hit list after 3.0?

    • In 3.1 it got bumped for Tumblr-esque post formats.
    • In 3.2 it got bumped for Distraction Free Writing.
    • In 3.3 it got bumped for a new flash-free media manager.
    • In 3.4 it got bumped for a new default theme (that itself got bumped to 3.5)


    1. What’s the point of a roadmap?
    2. How are ANY of those helpful to the 20% that aren’t “.com” or “blogging”? (Distraction Free Writing? Isn’t it fracking Notepad?)

    Andrea once asked me why Enterprise folks don’t hang around long in WP and I think this is a good example why.

    Clearly the folks on here are talented, dedicated, and incredibly knowledgable; and I genuinely love shooting the breeze with you all… but WP has a tendency to make short term decisions under the proviso that “it’s Agile and things can change later” (First rule of Agile: Chaos is also agile. Second rule of Agile: The WPtybee plan is about the most un-agile plan I’ve ever seen).

    May I offer exhibit A:

    The issue is we’re either left with things that can’t be changed (Matt blaming a decision in 2002 by B2 for hardcoding everything in 2011), or things that change every release because we didn’t think them through (hello Admin Bar).

    Given that we have a myriad of plugins, and weekly (if not daily) support requests on moving, migrating, setup dev/sandbox environments on the forums and mailing lists; maybe this is the sort of thing that would be a great kick-starter for a different type of conversation. A conversation that starts with “Maybe we got this wrong…”

    I realise I talk less about code, and more about processes and audience segmentation and decision making than all you developer-whizz-kids. I’m hoping this resonates, but if it doesn’t, you have my thanks for listening.

    “failed developer”

    Easy, Kev. You’ve now completely hijacked this thread. (Let me join you.)

    I was rather active in the user management discussions. In fact, I wrote two definitive blog posts on it. The second is almost certainly going to be the spec for when or if we decide to go forward.

    So, a few issues. One, our feature roadmaps and our API roadmaps are two completely different things. Post formats, DFW, drag-drop uploads, and default themes have never affected our goals for development. Indeed, the primary people responsible for the backend code hardly touched any of those.

    Building new APIs and handling complex schematic changes are grueling, and multiple core developers need to decide they have the stomach for it. That is why we haven’t touched it yet. For as good as my spec may be, it is going to be an absolute nightmare to implement it (and certainly would have been even worse before PHP5). The backwards compatibility aspects are going to be one of the hardest challenges we have faced since 2.3. It’s fine that it has sat there for a few years, untouched. One day, in the future, someone is going to dust off that blog post and do something awesome with it.

    There is a huge difference between refining the admin bar β€” again, a feature β€” and trying to reverse 9 years worth of assumptions based on absolute URLs. It’s a hell of a lot of code to rewrite while still keeping compatible. Also, Matt didn’t blame that on b2. Two developers in charge of the backend codebase (me and Ryan) did.

    If I turned around tomorrow and said I’m going to tackle some old, ridiculous “API” and make it better, and then succeed (the important part), guess what, It gets into core. But I need to have the stomach to start rewriting large swaths of the codebase with the hope I don’t break anything else. (You may have already read this mailing list post from me, where I talk about the future architectural patterns of WordPress.)

    And that brings me to the other point β€” in the nicest way possible, patches are welcome. I normally hate that phrase, because it’s a total cop-out. But, countless aspects of awesomeness have made their way into the codebase because one person prioritized writing it, and core developers realized that person had something good.

    My final point is, funny thing, you and I just spent a dozen or more paragraphs talking about user management, when in reality your comments + edit_posts bug has nothing β€” nothing β€” to do with any of that. It’s a small, unrelated bug. We actually did mostly fix this in one of the releases you said we ignored the problem. In 3.1, we introduced an edit_comment meta cap, which gave a lot more power to plugins to make whatever modifications they needed to make to it fit their desired workflow.

    And so all we actually have left is a simple bad cap check. It’s one a plugin could work around, but here’s the ticket for it.

    I’m just saying, not everything is so complicated. πŸ™‚

Viewing 4 replies - 31 through 34 (of 34 total)
  • The topic ‘WordPress's .htaccess file is suboptimal’ is closed to new replies.