Return to main site

Reporting

Partly Messy: Clean urls without mod_rewrite (experimental)

Ok, so here is a somewhat experimental feature (only 4.0.2 and up) for which I am interested in getting some feedback from users that are willing to try it out for a while. This may have some side-effects, so it may not be the best thing to use on a client’s site. And in the unlikely case that this experimental feature clashes with other things, it may be possible that it is dropped in a future update. Also make sure that you have you tried all of the suggestions in clean urls on different hosts.

So, having that disclaimer out of the way, let’s roll. How does it work? Basically it’s an old idea that came up a few times: Use the 404-Handling of the webserver to redirect to textpattern’s index.php. This is how clean urls are achieved for lighttpd (without any problems), and it is basically the same (semantically) that our rewrite-rules try to achieve. But for some reason Apache has this “problem” (or feature) that you loose all POST data when you re-direct via ErrorDocument, which means that comments (and potentially some other features) don’t work. So the user strawberryfusion on the forum suggested that basically the only thing needed to get comments working, was to pass them through messy urls, and use clean urls for the rest.

So here’s how you do it:

Step 1: Your .htaccess file, comment out all mod_rewrite related lines (throw a # sign in front of them), and add the following line to it:
ErrorDocument 404 /weblog/index.php
Note that I used weblog in that url, which assumes you have textpattern installed into a subdirectory called weblog, if it’s installed in the webroot, you would use ErrorDocument 404 /index.php and so forth.

Step 2: Edit your config.php and add the following
define('PARTLY_MESSY',true);
(brilliant naming, eh?). Make sure you add this within the php-delimiters, meaning it should be sitting right next to (below, above or between) the $txpcfg-lines that are there.

Step 3: Now you can go into Textpattern’s preferences and choose one of the clean url schemas and enjoy.

Note: After clicking preview on comments, you will have a messy url during commenting, but are redirected to clean urls when you cancel, submit or click elsewhere. Due to the messy url necessary during previewing/commenting, you are somewhat more limited in how far you can customize comments (only on individual article pages), but I’ve hardly seen any people doing it otherwise anyway. It’s also possible that plugins exist (which create forms of type POST on the public-side) which would not work with this way of achieving clean urls. But other than that I don’t know if it has any drawbacks, that’s why I’m interested in getting some feedback from long-term usage by the brave souls desperate enough to try this out… ;)

---

Comment

  1. I assume this is for those who the default clean URL stuff doesn’t work?

    — Eric D. Burdo · Nov 3, 04:23 PM · #

  2. Hi Eric,

    the default .htaccess achieves clean urls with mod_rewrite. This post shows how you can achieve clean urls without mod_rewrite.

    If the default .htaccess does not work, it can have many reasons and many solutions.

    — Sencer · Nov 4, 10:06 AM · #

  3. Sounds like a really nice method for making clean-urls work. I’m wondering what all the advantages of this would be over mod_rewrite? faster? less configuration? Could you elaborate on why this would be a better way of handling the URLs than the current method?

    — Philip Ashlock · Nov 5, 11:15 PM · #

  4. @3: i guess this wouldn’t replace the mod_rewrite method when that method is available

    — cs · Nov 6, 04:58 AM · #

  5. Sencer, does it mean that when using this method you can’t have custom 404 error pages?

    — Jaro · Nov 6, 09:29 AM · #

  6. Philip: If you have the choice, meaning of both approaches work, you’re better off using the mod_rewrite method that is by default included with textpattern. Just because it’s better supported.

    Jaro, it depends on what you mean. You can always use the 404-error-pages functionality that is offered by Textpattern. Does that answer your question?

    — Sencer · Nov 6, 12:35 PM · #

  7. Well, I think I understood the whole idea wrong then. I thought that every 404 is redirected to the index.php . But that is obviously not the case because you say that you can have a custom 404 page without it being redireced to the index.php. Do I get it right now?

    — Jaro · Nov 6, 12:41 PM · #

  8. I think the problem here is the ambiguity of “404”.

    I thought that every 404 is redirected to the index.php

    With mod_rewrite-method and with the method described here, the following happens: When apache cannot find a file or directory that matches the request, it will call textpattern’s index.php and let textpattern handle that request.

    Textpattern will check incoming requests for whether they match anything that’s defined in textpattern, and will show the corresponding pages – if it can’t find anything, it will send a 404 page to the client, the 404 page was “hard-coded in 4.0.1, and is customizable (within textpattern) in 4.0.2. Therefore I said:

    you say that you can have a custom 404 page without it being redireced to the index.php.

    Yes, but a 404 page defined in textpattern, not in the webserver’s configuration or .htaccess files.

    — Sencer · Nov 6, 12:48 PM · #

  9. Ah, thanks for the explanation!

    — Jaro · Nov 6, 03:35 PM · #

  10. It’s pretty nasty, but have you considered passing the POSTDATA via $_SESSION?

    — Roshambo · Nov 8, 02:23 AM · #

  11. I got a client site on a server, that does not have mod_rewrite. But I really wanted to have clean URLs.

    Works great, thanks very very much!

    — Simon Zirkunow · Nov 13, 02:19 PM · #

  12. Tthanks for the explanation!

    — Adrianne Curry · Nov 18, 06:25 PM · #

  13. The major downside (for me at least) with this method is that it gives a 404 Page Not Found status header with every request, which sucks if you’re doing any thorough analysis of your logs. But if that doesn’t matter and you don’t care about the status codes then it’s a great solution.

    — Justin · Dec 27, 11:30 PM · #

  14. Hi Justin,

    No, it doesn’t send a 404 response. It sends a 200. You can control this from PHP, and we are doing it. The logs will show a 200 as well. I have tested this with apache and lighttpd.

    — Sencer · Dec 28, 03:49 PM · #

  15. I am interested in using this method on a client’s site (with Txp 4.03). Do you have any more feedback on the method and/or if it will be in a future version of Txp. Thanks

    — Clive Walker · Mar 28, 02:19 PM · #

  16. I have been using it successfully on some sites, but I have’t gotten enough feedback from other people to really say much about it. We’re very likely not going to drop the functionality, though I can’t say for sure, if we’ll ever offer this as an official and supported feature.

    — Sencer · Mar 28, 07:15 PM · #

  17. Many thanks. Can you just explain whether I will need to change anything in order to get the 200 response.

    — Clive Walker · Mar 28, 07:36 PM · #

  18. We have tried this out but there were some problems using the Wilshire One rss_live_search plugin (presumably as you alluded to because of form data POST submission?) on non-home page sections and in articles. We did not do exhaustive testing on this. In the end, we have gone with messy url mode for now. Thanks.

    — Clive Walker · Mar 31, 01:51 PM · #

  19. It works fine here as well. Thanks.

    — Yannick · Aug 9, 03:39 PM · #

  20. really its a nice thing.

    — dizyn · Oct 30, 01:34 PM · #

  21. This would be a very useful feature, especially for web servers other than Apache without rewrite support. Unfortunately this behavior is web-server dependent.

    Tested locally with txp 4.0.4 using the Xitami (2.5c2) and Abyss (2.3.2) web servers. Didn’t work at all in Xitami. In Abyss, the article page displays (w00t!), but found the following issues:

    1. The comment form action URL is ‘http://.../txp/?id=...’ (no ‘index.php’).

    2. Invalid URLs cause the site home page to be displayed instead of the 404.

    3. The HTTP response code is 404.

    Issues 1 and 2 could be corrected with some code tweaks (although care would be needed to retain web server portability). Issue 3 is probably in the web server.

    I’d settle for “almost pretty” links ala WordPress.

    — Jay · Jan 1, 06:55 PM · #

  22. this works great for me, thank you. i created a website for a client who hosted with strato (they dont allow mod_rewrite). i used this and it works great.

    — Anja Schirwinski · Jan 8, 02:44 PM · #

  23. actually, it didn’t work in Internet Explorer. I mean it worked fine but downloads were broken in IE only. cant figure out why and would like to solve this problem but til then i will go back to messy urls. thanks for this anyway :-)

    — Anja Schirwinski · Feb 14, 03:17 PM · #

  24. Thanks for this fine article. However, I couldn’t get a clear result on Pardus Linux+Apache2+Php5+MySQL5 but eveything is ok in WinXP.

    Any ideas how I can fix it on Linux?

    — zinan · Apr 21, 07:03 PM · #

  25. Ran into this issue with earthlink, so far your fix works. Thanks!

    — billy · May 7, 07:45 AM · #

  26. Thanks mate! Worked like a charm!

    www.elnormo.net -> Studies -> CakePHP with out Mod_rewrite

    — Norm · Sep 25, 08:52 AM · #