WordPress's .htaccess file is suboptimal

Hi, Jan, thank you for the prompt and courteous reply. Rest assured that I am not “complaining”; quite the opposite. I hope to make WordPress a better platform and to alleviate some of the issues that developers (I know; not WordPress’s primary target audience, historically) face while working with version-controlled code and local copies of the WordPress installation.

Thanks for clarifying the important point that the .htaccess file is generated whenever the permalink settings are saved, and not during installation. This is a pleasant surprise.

That said, it is not possible even to log into WordPress, no less access the Permalink Settings, when the ‘sitehome’ and/or ‘home’ values, as defined on the wp_options table, are not accurate. This is a separate but related issue.

In other words, whenever we “publish” a WordPress installation (that is, perform a “build” on our development server and copy the files into a staging environment and eventually production), we can’t log into WordPress at all. We have to go into the database and change the aforementioned option values manually before even being able to log-in.

So, to answer your question, no, there is no harm in letting WordPress generate the .htaccess file whenever the Permalink Settings are modified, but the values that are written to .htaccess appear to come directly from ‘siteurl’ and/or ‘home’, so unless those values are accurate, the .htaccess file will not be effective.

When WP isn’t in root, and you don’t want to run it ‘from’ root, like example.com/wp/, you just put the .htaccess in the /wp/ folder.

This doesn’t work (unless the Permalinks Settings are updated to be accurate, in which the .htaccess file is updated accordingly). It works for the homepage, but clean-URL links to other pages yield 404 responses.

I have a WP installation at http://localhost/project (the fully-qualified path to WP’s index file is http://localhost/project/index.php). The WP files are stored in a “real” location on the filesystem, and relative to Apache’s document root, the path is /project (again, the index file is located at /project/index.php). So, this is precisely the setup that you describe, yet only the homepage is accessible.

If you want it to be in root, you can change the rewrite base to /wp/ and it works fine.

Are you addressing configurations in which WP is installed in the Web-server’s document root, but should be accessible at a different URL, e.g., /wp/? Or configurations in which WP is not installed in the Web-server’s document root, but should be accessible at the root URL (e.g., http://localhost/)?

In any case, the impetus behind my initial post was that I would like for WP installations to be “portable”. That is, I would like for a given WP installation to function identically whether it is installed at the Web-server’s document root or not, and whether the URL at which the WP installation is accessed is / or not. Further, I would like not to have to manipulate the database manually any time the FQDN for the WP site changes.

My gripe with having to manipulate the database manually has more to do with using WP in a collaborative development environment than anything else. In my organization, the WP database tables are version-controlled, so that each developer is working with the same data. The fact that WP stores critical URL-related data in the database means that each developer has to change the siteurl and home option values every time he updates his local working copy. (I realize that these values can be overwritten using WP’s update_option() function; more on that shortly.)

I understand that my “ideal implementation” is not possible without some kind of a configuration file. WP already has wp-config.php, which seems like a far more appropriate location in which to store core/critical configuration directives (the WP installation’s fully-qualified URL falls into this category) than the database.

In other words, I would prefer that WP store the siteurl and home values in wp-config.php, as opposed to the database. If this were the case, our development woes would be solved, as wp-config.php is added to each developer’s “ignore list” within his version-control client.

To summarize, it seems that WP would be far more portable and better suited to collaborative development environments if:

1.) The proposed changes are made to .htaccess (provided that no security risks are introduced as a result); this would also eliminate the need to modify this file whenever the Permalinks Settings are changed.

2.) The siteurl and home are moved into wp-config.php. Alternatively, the WP installation documentation is modified to include examples of how to overwrite the values in the database using inline definitions, e.g.:

update_option('siteurl', http://localhost/project);
update_option('home', http://localhost/project);

The latter option is less desirable, however, due to the associated overhead (writing to the DB every page-request). A possible improvement would be to wrap the above snippet in conditional logic such that the update_option() calls are not executed when the values in the DB already match those specified inline.

If I install at http://example.com/wp/ all my URLs work just fine, no 404s.

Ditto if I install it in http://example.com/wp/ but use http://example.com/ as my front facing URL. All my posts will be http://example.com/2011/postname and so on.

Right, you are installing WP to these locations. You are not installing it to another location and then attempting to get WP to function again when you move the installation to a completely different server that has a completely different FQDN and a different URL to the WP installation.

If that’s the case, you screwed something up. I have a WP install also at localhost/tester, and it works just fine. All my pretty permalinks work perfectly and they always have.

Again, you are installing WP to a specific location, so the values in the wp_options database table are accurate, and the values in your .htaccess file are also accurate. Of course everything “just works”. I am talking about moving existing WP installations here.

Also this statement is 100% incorrect:

this would also eliminate the need to modify this file whenever the Permalinks Settings are changed.

You misunderstood my statement. I am not talking about modifying the .htaccess file manually after changing Permalinks Settings. I am saying that WP’s internal logic would not have to modify the .htaccess file when Permalinks Settings are changed, as it does presently. Trust me, WP attempts to modify .htaccess any time you click “Save” on the Permalinks Settings page (even if nothing is changed, if I recall). Jan stated this in his post above, I tested it, and he is correct.

That’s the thing, it DOES exactly that. Obviously the URLs are different, but that’s really how it works.

Again, you are fundamentally misunderstanding the entire premise of this thread. I am not installing WP to a specific location and wondering why it doesn’t work. I am moving WP installations around and annoyed with the manual labor that is involved each time.

That’s something else entirely and highly unlikely. Look at how WordPress stores links and images. They’re all using the full path. http://example.com/2012/postname

That’s not going to change.

How is that URL not going to change if I migrate the WP installation from example.com to different-example.com? Of course all of the URLs are going to be different (and therefore the values in the DB need adjusting).

Andrea_r, thank link looks to address my concerns, in part if not in full. I will read through the information, digest it, and post back on Monday if I have any questions. Thank you.

John P. Bloch, by making the modifications I have described, the same .htaccess file works just fine for everyone on our development team who is working locally, despite different hostnames and WP paths, which is largely the point of my post.

For example, I don’t want the caching rules from W3TC coming down into my dev and test environments.

Right, which is exactly why we don’t store those settings in a .htaccess file; we store them in Apache’s virtual-host configuration file for the virtual-host in question. There are plenty of reasons for this approach, not least of which is performance.

Your statements seem somewhat contradictory; you suggest not keeping WP’s .htacess file in version-control, but at the same time suggest learning how to write a vhost entry (something with which I am perfectly familiar, by the way).