CODEWITHSUNDEEP
phpapachemod-rewriteurl-rewritingfriendly-url
anon
anon

Reputation:

Is it better to handle friendly/clean/pretty URLs with mod_rewrite or a language like PHP?

I'm developing my first decent-sized PHP site, and I'm a bit confused about what the "right way" (assuming there ever is such a thing) to handle clean/friendly/pretty URLs in the application.

The way I see it, there are two main options (I'll use a simplified social news site as an example):

1. Use mod_rewrite to handle all potential URLs. This would look similar, but not identical, to the following: 

RewriteRule ^article/?([^/]*)/?([^/]*)/?([^/]*) /content/articles.php?articleid=$1&slug=$2
RewriteRule ^users/?([^/]*)/?([^/]*) /content/users.php?userid=$1&username=$2
RewriteRule ^search/?([^/]*)/? /content/search.php?query=$1

2. Pass everything to some handler script and let it worry about the details: 

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) handler.php?content=$1

Clearly this is all untested "air code," but you get the point.

Upvotes: 9

Views: 1810

Answers (5)

Crozin
Crozin

Reputation: 44386

Use option #2 - why? RewriteRules in .htaccess are powerful tool, but they're some kind of static. I mean you cannot easily manage then using PHP (or whatever you're going to use). Also .htaccess doesn't provide so much flexibility, but has some advantages (for example: it's a bit faster).

Option #2 also need .htaccess as you noticed, but in most cases RewriteRule takes the following form:

RewriteRule (.\*) index.php

Where index.php is your front controller.

The biggest advantage (IMO) of this soultion is that each route is described in PHP (or whatever you use) so accessing these routes, modifying them is much easier. Furthermore these routes can be used then not only for changing URL into set of variables, but also in opposite way - to create URL from set of variables.

I think the following example (from Symfony framework) will explain what I am talking about:

// apps/.../config/routing.yml - Describes routing rules
post:
   url:          /read/:id/:slug
   params:       { module: blog, action: index }
   requirements: { id: \d+, slug: \w+ }

// apps/.../modules/blog/templates/indexSuccess.php - template for index action
<?php echo link_to($post['title'], '@post?id=' . $post['id'] . '&slug=' . $post['slug']); ?>
//creates: <a href="/read/123/my-first-blog-post.html">My first blog post</a>

Now whenever you change your rounting.yml file and change /read/:id/:slug into /:slug_:id all your links in application will turn into /my-first-blog-post_123.html.

Doing such and others things when you use option #2 is much easier.

Upvotes: 2

Ben James
Ben James

Reputation: 125207

Really this is the "are frameworks worth using?" question in disguise.

Using mod_rewrite to define your URL routes is quick and easy (if you understand regular expressions...) but your application code is oblivious to the URLs unless you duplicate the information somewhere.

Usually, people duplicate this information many times without thinking about it, by hard-coding URLs in the links in their views, or in redirects. This is really messy, and will one day cause pain when you decide to change the URL structure of your site halfway through development. You're bound to miss one and end up with a 404 somewhere.

Using a routing component in your application (such as the one in Symfony) means you can attach names to your routes, allowing you to define your URLs once and re-use them many times:

# apps/frontend/config/routing.yml
homepage:
  url:   /
  param: { module: default, action: index }

This makes it really easy to link to pages of your site without repeating yourself:

<?php echo url_for('@homepage') ?>

Upvotes: 4

therobyouknow
therobyouknow

Reputation: 6800

Clean pretty URLs appear to be provided by PHP-script-based popular content management system Drupal using a combination of modrewrite rules in .htaccess and plug-in PHP Drupal modules such as path and pathauto.

Given the success and popularity of this tool - and its ability to run on the most modest of shared hosting, I think this would be your answer.

Upvotes: 1

Pekka
Pekka

Reputation: 449605

As far as I can see, any possible performance differences between those methods are really minuscule and relevant only for really, really high-traffic sites.

I think there is no "best practice" as such, both methods are equally often used. If your project structure allows it, and you're more at home with parsing the URL in PHP (where the rest of your project is), put everything through one controller file, and let your application handle the rest.

If performance is really of the essence, I suspect that having Apache handle the addresses is faster, because there is no interpreted language in between. (I have no hard data for this, though). But as I said, you're probably best of choosing whichever is going to be most maintainable for you in the long term.

Upvotes: 1

Pascal MARTIN
Pascal MARTIN

Reputation: 401132

Option 1 (.htaccess and several .php files) was often used "in the past" ; now, I see option 2 (every request going through one .php file) used a lot more.

The main advantages I see with option 2 are :

  • you can add / modify any kind of URL without having to change any physical file like .htaccess
    • which means the format of the URLs can be configured in the admin section of your application, for example
  • you only have one entry point to your PHP code.
    • which means everything goes though index.php : if you need some code executed for all requests, put it there, and you're sure it'll always be executed.
    • That's used a lot with MVC frameworks, for instance.


A couple of years ago, I would have gone with option 1 ; now that I use MVC and Frameworks, I always go with option 2.

Upvotes: 5

Related Questions