.htaccess with mod rewrite or Wordpress-plugin?

URL rewriting, better choice on the long run

[deeper]

Hi,
let's say you have to solve a little issue with URL-rewriting for a relaunch on Wordpress. It has to do with file extensions like .php or .htm, .html ect.

Let's say there are two working ways, which would you choose, considering "the long run" of the site, i.e., causing few playground for future issues and change necessities, dependancy:

-one of the available Wordpress plugins which do a more or less small rewrite-action within WP, supplementing the usual dynamic URL-creation

-redirecting the URL by mod_rewrite, server internal, without 301 (relaunch with WP doesn't actually change URLs, i.e., domain.de/bla.html --> domain.de/bla.html)

Considering the long run and not wanting to be faced with more or less "usual" issues like Plugin/WP-Updates, htaccess seems to be preferable?
Dependance, security, speed? htaccess again better, I suppose?

I'm not only faced with a certain site, it's more like a key question and basic issue for me, concerning other sites in future too.

Thanks,


deeper

[not2easy]

Is this an existing static .html site that is being migrated to a WP install on the same domain? I ask because that is what it sounds like but to be sure before offering suggestions it is important to know that. If so one little rewrite is all you would need. BUT because you mentioned "without 301" it makes me wonder if you plan to do something not obvious in the question. A 301 lets search engines know "this page used to be here, now it is over here" and the alternative is a 302 (Temporary change).

IF the URLs are not changing, you just want the .html extension to be .php or (nothing)?

[lucy24]

redirecting the URL by mod_rewrite, server internal, without 301

If there's no 301, just server-internal activity, it isn't a redirect. It's a rewrite. This leaves you vulnerable to Duplicate Content if you've got an old URL (rewritten) side by side with a new URL, and both lead to the same page.

No matter what you want to do, there almost certainly exists a WP plugin to do it. But there's a cost: WP-internal redirects involve heavy server resources and database calls, because it essentially builds the whole page before saying "Oh, oops, I guess I'm supposed to issue a 301 instead." Coding your own redirects manually in htaccess allows you to bypass the whole page-building process. Your users won't notice the difference, but your server might. Especially if you become popular :)

[deeper]

Yes, for me, the user and Google a static .html site should keep all its URL exactly as before:
domain.com/page-abc.html --> domain.com/page-abc.html
domain.com/page-xyz.html --> domain.com/page-xyz.html

Therefore "here" and "over here" is the same. Software and technical way of creating pages will change (static --> dynamic), but URLs, content and static look (no blog) won't change. Not a case for 301, just a case for fixing a technical issue.

Permalink-feature of WP is not able to create .html-URLs for pages, only for posts. So I have to solve this, appending .html by any extra step. Unfortunately I "must" take Wordpress and pages. So there is no way around it.

[deeper]

@lucy24:
O.k., let's call it an "internal rewrite", just done by the webserver and WP.

Due to my intention described in the last post, there is no danger of DC, right?

There are several plugins with different codes, leading all to the same goal of appending .html. I can't judge the quality of the codes what way they go and how perfomant they are. But if you want I can give you a link to a forum, where I introduced three codes wihtout getting an answer.

As far as I know they don't create performance issues.

As I tried to explain, the most important issue is staying "tuned" on the long run. Independency and expectating few necessary usual or unusual actions...
You know, URLs are quite critical. It's not like searching for a plugin giving nice fonts or other fashion matters.

[omoutop]

Although i cannot offer any solid advice on this matter, my 2 cents: if you want to go independent, build your own stuff. You cannot rely on a plugin that may or may not work in the future, that its developer will make it compatible with newer versions of wp in time or for any other reason.
Ignore the plugins. Do the rewrites in your htaccess, alone.

[deeper]

Hm, yes, that's what I think too.

Probably there will always be a way to solve such things, for example by finding a different plugin or creating my own plugin (let someone else create it).
Don't think I'm lazy, but then I will be forced to struggle with these technical things again... Because of some (partly private) reasons which reach in the future and which I cannot explain, I'd like to have a clean, stable, simple and independent way, as much as possible.

Even if the code of a plugin is simple it will be less performant than some mod_rewrite code in the .htaccess and less safe? I don't say
that a plugin is a big security issue and slows down heaviliy, but compared with the htaccess?

[omoutop]

again my thoughts, since i am amateur programmer, and my English inst perfect.

Your htaccess is safe as long as your root folder is safe and your apache server is safe.
That being said, it is my opinion that, its far more easy to hack your site and highjack your forms, sending spam emails for example, than to hack your site and highjack your htaccess, changing your rules and causing havoc.

Other than that, some rewrite rules in htaccess may seem a bit confusing, but they stay there unchanged for years (until you update/upgrade your apache configuration at least, in which case you just run some tests to see if anything has stop working).

On the other hand, a plugin in WP (or in any other cms system) will need constant updates/upgrades to work with newer versions (an you need newer versions simple to be updated in security). After each such action, you must test everything again to be on the safe side.

On performance, i find htaccess to be far superior to any plugin.
With htaccess, your scenario will be something like this:
user: show me example.com/pagea.htm
server: receiving request
server: checking htaccess
server: pagea.htm has some rule, requesting pageb.htm
wp: load modules, load templates, load everything, start rendering page
user: gets to see example.com/pageb.htm

With most plugins your scenario will be something like:
user: show me example.com/pagea.htm
server: receiving request
server: loadind pagea.htm
wp: load modules, load templates, load everything, start rendering page
wp: oops, there is redirection rule here - load pageb.htm instead
wp: load modules, load templates, load everyting, start rendering page
user: gets to see example.com/pageb.htm

The server process times are in some milliseconds, while most cms systems need a couple of seconds to load everything a page needs, to decide if there is a rule and load proper content (based on records on database of course - with too few records there is no significant differences in speed, from user point of view)

[deeper]

I guess, the process you described (regarding performance) is the same what lucy24 meant as "performance cost" and "bypass" and it makes no difference, if it's a 301-redirect or "internal rewrite without 301"?

Thanks for explanation, which is at least "3 cents" :). My database may be not huge, but - on the long run - you never know what will happen. May be in 2 years I will add an onsite-blog, posting every day. THEN the efficient bypass is useful and does its job.

Like you I'm not native english speaking, but I understand you well, don't worry.

[lucy24]

it makes no difference, if it's a 301-redirect or "internal rewrite without 301"

Right. If both are happening in htaccess, no difference. And omoutop's description of the htaccess-vs-plugin difference was much more eloquent than mine :)

Someone hereabouts-- possibly incrediBill, but that may only be because I always think of his name first-- counted up the number of separate database calls involved in rendering a typical WP page. It wasn't just two or three ("Get such-and-such article text, and such-and-such linked material specific to the URL, and...") but something absolutely jaw-dropping like 20 or 30. And that's for, essentially, a static page.

I say: If you know how to roll your own, do so.

[deeper]

It's not your lack of eloquence, but rather my need for explanations :).

Speed is always welcome even if it's not a problem at the moment. Regarding a certain SINGLE page and its necessary database calls, a typical page of me is big and has a bunch of elements which may become more: pics, videos...
Furthermore a dynamic built page never is a fast as a pure static one and caching is said to be effectiv only (?) for big sites.
Therefore a short bypass is welcome.

O.K., so the buttom line is that regarding security, speed, potential for future troubles/work, independancy, the .htacess wins 4:0 against plugin. Though a plugin still is a possible way to go.

There may be one further adantage of the htaccess, dependant on the code of the plugin: The htaccess code is easy to remove, without leaving any fixed prints in WP or database. So it is flexible too.
Not sure if plugins can claim this too.

[deeper]

Okidoki. So I will take the .htaccess.

Could anybody give me the .htaccess-code covering my case, as described above, i.e. keeping exactly the URLs like before with .html, though in WP this extension has to be dropped when creating the pages?

I will create the pages without .html in Wordpress, for example www.domain.de/page-abc. Therefore the "custom structure" of the permalink-setting is used: /%postname% (without trailing slash).

Now the htaccess should rewrite www.domain.de/page-abc.html --> page-abc (or vice versa? omoutops example shows both URLs with .htm?).

At the moment my htaccess has only the common standard code to redirect non-www to www:
RewriteEngine on

RewriteCond %{HTTP_HOST} !^www\.domain\.de$
RewriteRule ^(.*)$ http://www.domain.de/$1 [L,R=301]

Should both codes be combined or separated?

[edited by: phranque at 1:40 am (utc) on Aug 11, 2014]
[edit reason] unlinked URL [/edit]

[lucy24]

The domain-name-canonicalization redirect is normally your very last redirect. ("Redirect" = RewriteRule with [R=301,L] flag. Internal rewrites generally come after all external redirects.) It covers only those requests that have not already been redirected, because they are exactly right except that the hostname is wrong in some way.

(In general, the second-to-last redirect is the "index.html" redirect for directories. But this can be affected by your CMS.)

Ideally, you want to avoid the !-f lookup ("Execute this rule if and only if the file doesn't physically exist"). So if the rule can be constrained to certain named directories where you already know whether the files exist or not, that's a big help. For example:

RewriteRule ^(onedir|otherdir|thirdddir)/(\w+)\.html http://www.example.com/$1/$2 [R=301,L]

will take any request for filenames in html, and forcibly redirect them to same without html. If you happen to have both html and htm, say
\.html?$
Otherwise just give the form you actually use. Or, Option C, say
\.htm
without closing anchor. This version also covers potential garbage (Path Info is the formal term) after the extension.

---

That's for redirecting from .html to extensionless. I didn't read the question backward did I? :(

[deeper]

Hi lucy24,
"That's for redirecting from .html to extensionless. I didn't read the question backward did I? :( "

I hope there is no missunderstanding. Actually and officially, i.e. for me, browsers, visitors and search engines, URLs should NOT change:
www.domain.de/page-abc.html now (static) --> www.domain.de/page-abc.html as relaunch with WP (dynamic)

Unfortunately WP ist not able to create URLs for pages with extensions like .html. I will have to create the pages without .html in WP, like www.domain.de/page-abc. Up to here, only up to here and only because of this technical inability of WP for pages I have to go extensionless. My site is not a blog, with a blog I could create posts (not pages) in WP WITH (!) .html natively and this whole thread would be needless.

But it's a static corporate site and therefore an additional step must lead www.domain.de/page-abc.html-requests to the right content in WP, which only knows www.domain.de/page-abc.

Basically this can be managed by a plugin or .htaccess. As the .htaccess is preferred I asked for the code. But as it should be an "internal rewrite", not an official redirect with 301, i.e. not realized by search engines, browsers and visitors, "[R=301,L]" in your code doesn't fit?

[phranque]

you must internally rewrite (i.e. RewriteRule without the [R=301,L] and without the protocol/hostname specified) the ".html" url to the url WP uses to generate the pages.

At the moment my htaccess has only the common standard code to redirect non-www to www

in that case, how do your "WP" requests get internally rewritten to the WP script?

[lucy24]

Uh-oh, I did misunderstand :(

i.e. RewriteRule without the [R=301,L]

You'd want to merge it with the ordinary WP rewriting, wouldn't you? So immediately before the index.php?blahblah rule (the one that's the meat of every CMS) you insert one that says something like

RewriteRule ^((onedir|otherdir|thirdddir)/\w+)\.html /index.php?$1 [L] 

-- that is, exactly what the vanilla WP rule says, only you've intercepted your .html URLs.

[not2easy]

This is WordPress generated section that should be in your .htaccess file in order for WP to work, it is auto generated by WordPress during install:

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

# END WordPress

[deeper]

Could I describe my intention in my last post understandably? If not, tell me, what further information you need. Due to my technical and english limitations, it's not so easy for me...

@not2easy:
You are right, I forgot this auto generated WP-code. I guess this is the code lucy24 calls "vanilla WP rule"?

So there are THREE things which my htaccess has to manage regarding "URLs":

-Internal rewrite (.html)
-WP vanilla code
-Common 301 non-www --> www (Google knows this already from my WMT, but this does not redirect visitors, so I cannot drop it, right?)

Is this possible and what is the best way? All three merging anyhow or all three separated? If separated, what order?

Thanks for your patience.

[lucy24]

Here's the sequence, looking strictly at mod_rewrite:

#1 any and all RewriteRules that end in [F] flag (403 response). If you have RewriteRules of this kind, you also need to poke a hole for your error documents. Ask about this separately if needed.

#2 any and all etcetera ending in [G] flag (410 response, if and only if you've got any)

#3 any and all RewriteRules that create an external redirect ([R=301,L] flag). The last item in this group is the domain-name-canonicalization redirect (with/without www).

#4 RewriteRule that intercepts requests for index.php with [L] flag alone (this is one of the two rules in the built-in WP htaccess)

#5 any internal rewrites that you're creating manually, such as the with/without .html rules you asked about here

#6 The rest of your built-in WP htaccess.

All rules using mod_rewrite need to be in the same htaccess file. If you know how to bypass this rule, you don't need us. We need you ;)

[deeper]

Thanks, that's useful even for future issues.

So, in ONE merged code this is correct?:

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.example\.de$
RewriteRule ^(.*)$ http://www.example.de/$1 [L,R=301]
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
RewriteRule ^((onedir|otherdir|thirdddir)/\w+)\.html /index.php?$1 [L]
</IfModule>

It's not possible or advisable to create three separated code "blocks"?

The sequence of #4 and #5 is not contrary to
"So immediately BEFORE the index.php?blahblah rule (the one that's the meat of every CMS) you insert one that says something like

RewriteRule ^((onedir|otherdir|thirdddir)/\w+)\.html /index.php?$1 [L]"

[edited by: phranque at 7:39 pm (utc) on Aug 17, 2014]
[edit reason] exemplified domain [/edit]

[lucy24]

<IfModule mod_rewrite.c>
RewriteEngine On

Delete any <IfModule... envelopes wherever you find them. Not their contents! Just the envelope itself. You either have mod_rewrite or you don't-- and if you don't, WP (and most other big-name CMS) simply won't work.

You also don't need to say RewriteEngine on more than once. It stays on until turned off. (Q: Why would you want to turn it off? A: For testing. It's simpler than commenting-out a whole bunch of lines, since Apache has no equivalent to /* blahblah */)

The sequence of #4 and #5 is not contrary to
"So immediately BEFORE the index.php?blahblah rule (the one that's the meat of every CMS) you insert one that says something like

RewriteRule ^((onedir|otherdir|thirdddir)/\w+)\.html /index.php?$1 [L]"

This rule is part of #5: Internal rewrites that you've created yourself. Essentially it's doing exactly the same thing as the generic WP rewrite, except that you're furtively removing the ".html" part.

Now, in theory you could express the rule as

RewriteRule ^((onedir|otherdir|thirdddir)/\w+)\.html /$1

without [L] flag and without "index.php?blahblah" and then pass it along to the final WP rewrite -- but I could come up with a long string of reasons why this isn't advisable.

Think of it as another case of the basic mod_rewrite principle that says "Specific before general". All page requests will end up being rewritten to
index.php?blahblah
but some of them get special handling along the way.

[deeper]

For the following code I removed
- <IfModule mod_rewrite.c>
- </IfModule>
- the second "RewriteEngine On"
- RewriteRule . /index.php [L] (as it is included by the row with .html-code)

Now everything is correct and "pretty fine" (as Googlers obviously like to say)?

If yes, do you have any idea why it might be reasonable to split this kind of code in three blocks, each standing for his own?


RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.example\.de$
RewriteRule ^(.*)$ http://www.example.de/$1 [L,R=301]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
RewriteRule ^((onedir|otherdir|thirdddir)/\w+)\.html /index.php?$1 [L]

[lucy24]

I'm not sure what you mean by "blocks".

In Apache, each module runs separately, in a fixed order that's generally out of your control unless it's your own server. (Sometimes not even then.) So mod_setenvif does its thing; mod_rewrite does its thing; mod_authzthingwhatsit does its thing, and so on.

Within any one module, rules are executed in sequential order, ignoring any intervening mods. They normally run from top to bottom, i.e. starting with config and ending in the htaccess for the directory containing the requested file. mod_rewrite behaves slightly differently, so try hard to have it all collected in a single htaccess file (or config if available), and don't put RewriteRules inside <Files> envelopes unless you know what you're doing.*

In Apache, blank lines have no syntactic meaning. So put a blank line after each RewriteRule just to make it easier for you to keep track of what's happening. Use #comments liberally; for safety's sake, keep comments on lines of their own. (Partial-line comments are unpredictable.)


* Or unless, like me, you had not idea you're Not Supposed To Do This and just went ahead and did it anyway.

[deeper]

"Blocks" would mean:

#www-redirect
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.example\.de$
RewriteRule ^(.*)$ http://www.example.de/$1 [L,R=301]

#internal .html-rewrite
RewriteRule ^((onedir|otherdir|thirdddir)/\w+)\.html /index.php?$1 [L]

#standard WP-code for permalinks
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

It makes things clearer this way, especially if being a non-coder, looking rarely in the htaccess.

But my question mainly targets something different:
WP creates his vanilla code automatically. As far as I know after using the permalink-settings for the first time. What will happen, if the webmaster "changes" this vanilla code (afterwards or before WP-action) by merging it with for example .html-rewrite, like above?

Will it be overwritten or changed again by WP?

[edited by: phranque at 10:11 pm (utc) on Aug 21, 2014]
[edit reason] exemplified domain [/edit]

[lucy24]

Those aren't blocks, they're just blank lines :) And yes, always keep your rules in functional order-- usually, though not always, from most severe ([F] flag) to least severe ([L] flag alone).

You don't need the RewriteBase line, because you will never write a RewriteRule whose target requires a base. If you absolutely must include the line, put it right after "RewriteEngine on" (which will come only once).

If you're using any CMS and you also need to add things to your htaccess, you'll need to make sure you keep backups of everything. Earlier in this thread I summarized the order of RewriteRules when you've got both. Most of the built-in htaccess is given as #6. Stick to that order.

WP only changes or overwrites your RewriteRules when you install a new version. (Possibly also some skins/mods/flavors/addons, but don't look at me.) It doesn't wantonly throw away the htaccess every time you use the site. If in doubt, glance at the current timestamp on your htaccess file, or simply open the file (the one on your server) and take a look.

Whenever WP does install something, you'll need to do some cutting and pasting to re-merge the WP stuff with your own parts.

If it's practical to do so, maintain htaccess files in two places. One at the highest possible level (userspace or primary domain, depending on your hosting configuration) for almost everything other than mod_rewrite. These rules will be inherited straight down the line. And then the htaccess that WP uses can be somewhere deeper down-- often in a subdirectory, especially if you're only using WP for a blog or similar.

[deeper]

What exactly do you mean with
"when you install a new version" and
"whenever WP does install something"?

There are security updates (3.9.1 --> 3.9.2), automatically done by WP and main updates (3.9 --> 3.10 or 3.9 --> 4.0) which the admin has to do manually.

In both cases I will have to replace the overwritten htaccess with my last htaccess-backup afterwards?

[lucy24]

If you need details, you may get more exact information in the WordPress subforum. (not2easy? You out there?)

The loose answer is: When you do a WP install or upgrade, it overwrites any existing htaccess in the relevant directory. (htaccess files in other directories are unaffected.) That means the entire htaccess file, not just the mod_rewrite sections.

For safety's sake, check your htaccess every time WP has installed/patched/upgraded anything, and always keep a copy. Even if something happens automatically, they will at least tell you they've done it, right? (I'm thinking by analogy of my computer's Software Update. It runs once a week, unasked-- but it then checks with me before physically doing anything to the HD.)

[deeper]

O.K., I will ask at the WP forum.

IF an update wants to overwrite my htaccess, it doesn't make any difference whether using the "one-block" or "3-block-code", i.e., it would be overwritten anyway, in both cases?

My hope was to be more safe with a "3-block-code", because the WP standard code would almost stay unchanged since WP created it. Merging the three issues to one however...

[lucy24]

It definitely replaces your entire htaccess. Blank lines or no blank lines. The part I don't know is how often this happens-- for example, if you've just changed a theme so your pages come out in a different color, would this kill your htaccess? I don't know.

When you keep a copy of your htaccess, make sure you've clearly commented the lines that are specific to WP, so you can compare to the new version and see if anything has changed. There will be a minimum of two CMS lines, both involving "index.php". But in general these won't be changed by WP unless you've installed one of those plugins with "SEO" in the name. Those might result in additional redirects in htaccess itself. (Or, then again, they might not. Worst case, all the redirecting happens within WP. See adjoining thread for concise summary -- not written by me ;) -- of WP redirects.)

[ergophobe]

I haven't followed everything here, but was just going to comment on performance and maintainability.

If you have access to your server config (httpd.conf) you want your rewrites in your server config not in .htaccess because...

1. performance
If you turn off AllowOverrides, the server doesn't have to recurse up the directory tree for ever request and the rewrites are loaded into memory when the server starts rather than read from files on every request.

2. maintainability
It is a common issue with a CMS - you upgrade and it overwrites or deletes .htaccess. Now the site doesn't work. If you have this in server config files, they are safe from WP upgrades.