Whatever you want to call them (for the purposes of this post they are SEF URLs), they’re part of 1.3, so I thought it would be a good idea to talk a little bit about them.If you’ve no idea what I’m talking about then here’s a quick intro. SEF (Search Engine Friendly) URLs means the URL to a page on PunBB takes a form which resembles a more classic (static) website, and may well end in a prefix such as .html, 1.3 is going to ship with the option to use a number of what we are calling “URL schemes” which basically means a consistent style of URLs that will be used throughout the forum, wherever possible. One requirement of these is that apache is used with mod_rewrite enabled and you place a .htaccess file from the extras folder included with PunBB in the root of your forum.
A number of basic schemes will be included with PunBB, these will be firstly simple file and folder stuctures such as
http://forums.punbb.org/forum-23.html or http://forums.punbb.org/forum/23/
for the 23rd forum, it will also include two similar schemes which will also incorporate text from the title of the forum or post into the URL (this is the SEF part), such as
http://forums.punbb.org/forum23-Feature-requests.html or http://forums.punbb.org/forum23/Feature-requests/
1.3 will also come with the functionality to add more schemes simply by dropping files into a folder in a similar way styles or languages are added now.
When creating the URL schemes a number of important considerations had to be taken, first of all as this is PunBB it had to be as fast and as simple as possible for the elements of a link to be converted to a URL, so this is done simply with a list of the different URL formats and how each one should be output. Another important consideration was how permenant a URL would be when admins have the option to switch schemes. This has lead to a “hybrid” .htaccess file being created which processes URLs from all the provided schemes, meaning even if a URL scheme is not currently in use, the URLs it generated will still work (assuming .htaccess still exists as it did).
To round this off, I think we’ve managed to produce a simple but effective way to scheme URLs, and have implemented it in such a way it won’t lead to dead ends (and inevitably poor search engine rankings) in the future, however since this isn’t simply PHP there are a lot more variations from setup to setup than we normally have to deal with, so here’s where you come in. If you are testing 1.3 it would be extremely useful if you could try out the schemes it currently has available, and report back if you have any issues. If you do have issues please give as much information as you can, apache version is critical as well as exactly what kind of error you are having (500 or 404 server errors etc.).
I’m still in this process of testing this with OVH hosting, to confirm it’s on their end and not on yours.
But I have a question: how are you going to handle localized URI scheme? On the PHP’s side it’s simple, but on the Apache’s side, right now it’s a whole different story. A localizer would need to create custom rewrite rules (localizing and writing regexp are two very different skills), but where to put them, so that it doesn’t destroy the vanilla rules?
March 19th, 2007, at 7:28 am #Very interesting. I’m looking forward to trying this out to see how it works.
March 19th, 2007, at 2:35 pm #I think something is wrong with my mod_rewrite, I never got fancys to work in 1.2 and now installing 1.3 I chose them, submitted and all the urls looked fancy, but were dead/broke links when surfing around. Now I can’t get back to change it back to non-fancy.
March 19th, 2007, at 2:39 pm #@Trakman: Are you sure mod_rewrite is installed on the server?
March 19th, 2007, at 3:09 pm #Wow!, this looks great!
can’t wait untill it’s finished!
March 19th, 2007, at 3:17 pm #I hadn’t really thought of localised schemes, are they really important? If you did want to add them you could simply duplicate the current rewrite rules and edit the new set to use whatever words you wanted.
Trakman: You can edit the database and delete your cache files to reset to the default scheme (A script to reset this will probably be included in the extras folder in the release). I’m guessing your host doesn’t support mod_rewrite which is why the 1.2 version didn’t work either.
March 19th, 2007, at 5:20 pm #Jérémie: How do other PHP apps (eg: Textpattern, MediaWiki, WordPress, etc) handle localized schemes?
March 20th, 2007, at 12:49 am #I don’t think WordPress has anything to localize in it’s Permalinks.
March 20th, 2007, at 1:37 am #guardian34: You’re right, by default that wouldn’t affect WordPress.
So scratch WordPress from that list :D
So, to phrase my question a little better: what do other apps with this issue do?
March 20th, 2007, at 1:45 am #We’re talking about localizing words like forum, topic, or admin in the URL, right?
March 20th, 2007, at 2:11 am #Hey Connor
I edited the db. Under the ‘config’ table, I set ‘o_make_links’ from ‘1′ to ‘0′ and deleted the cache and it’s still broken.
March 20th, 2007, at 7:33 am #actually didn’t see there were 2 other pages of fields in phpMyAdmin, set ‘o_sef’ back to ‘default’ manually and I’m cooking with gas :)
btw - ‘mod_rewrite’ is showing as a ‘loaded module’
March 20th, 2007, at 7:50 am #anyone want to take a look at my server?
icq 3361303
update just for the record: my server is sorted now.
here is my friends explanation:
“confusion in httpd.conf between the default (AllowOverride None) and the permission for a specific location (my www-root). this happens to me very frequently, so i just change the default setting to All… not the best way, the adverse side-effects are minimal (and if you’re hacked in some way, it doesn’t protect you…)”
March 21st, 2007, at 9:38 am #A prefix in the end of a word is not a prefix, it’s a suffix ;)
Finally!!
March 21st, 2007, at 7:52 pm #Can’t wait! Great news.
I guess 1.2 will be the end of punbb for me then.
Requiring .htaccess is a bad idea. Enforcing a default configuration to use a feature shouldn’t be.
If you read the Apache performance guide at the apache website you’ll notice they suggest turning off .htaccess for performance. If punbb is a performance app then you just shot yourself in the foot.
I imagine this will be the end of the lighttpd crowd too? I don’t believe they can use .htaccess files and their rewrite is very hard to convert from apache’s rewrite.
In short, why didn’t you guys just use PHP native functions to examine the URL??? I’ve done this on many projects and it doesn’t enforce any strict configuration requirements.
April 9th, 2007, at 5:24 pm #Carl: First of all, the SEF URLs are disabled by default, so we do not require .htaccess.
Yes, the Apache performance guide recommends disabling .htaccess, but the performance penalty of doing so is minimal compared to the overhead of running PHP scripts and querying the database.
Regarding lighttpd. Since we don’t require .htaccess, lighttpd will work just fine. We haven’t looked into it, but it shouldn’t be all that difficult to port our rewrite rules to work with lighttpd.
I’d love to see what you mean by using “PHP native functions to examine the URL”. The only way I’ve seen this done is with an ugly hack such as example.com/index.php/forum/10/
April 9th, 2007, at 7:18 pm #re: .htaccess - you can put .htaccess stuff into httpd.conf if you are so much into performance
re: localization - textpattern creates a kind of 7bit clean version of the article title text. i have experience only with hungarian and slavic languages here, but works very well, and if all fails you have a “url only title” in the advanced settings of the article where you can enter anything your heart desires. it’s very good, i suggest exactly the same, perhaps even borrowing the code, esp. now the txp is going bsd license in the future :)
April 12th, 2007, at 10:11 am #frantisek,
That’s correct. I don’t know what I was thinking when I wrote that - yes, I do put my .htaccess into extra/http-vhost.conf and that does eliminate the performance issue. It may still eliminate the lighttpd guys though. Anyone run lighttpd? From the chatter it isn’t quite stable enough for me yet but I’d like to toy with it.
Rickard,
As far as my “PHP native functions to examine the URL” comment - let me say it has been a while since I’ve done those projects.
I used to work at a large host who did what you are suggesting above and yes, that was horrible. I don’t want to see a .php file toward the front of the url. it is possible to eliminate that .php portion using apache directives (not rewrite) which I believe you can replicate in lighttpd.
ForceType application/x-httpd-php
create a symlink from viewtopic to viewtopic.php
order allow,deny
deny from all
That also eliminates people guessing which technology you are using from the URL. You don’t need to do the symlink but I like the .php for syntax highlighting in my IDE. I don’t know if this would cause problems with shared hosts or not. But yes, from that point you’d need to examine the URL and any arguments passed to it.
As for the structure, certainly wouldn’t use
example.com/index.php/forum/10/
index of course should not be an all inclusive script. forum is not required because you know the structure of the position. 10 could be an encoded id (not raw please) or could be the forum name followed by /index.html or /index.xml or .rss or whatever based on content presented. I would envision something similar to:
example.com/viewtopic/johhny_drives_race_cars.html
Or for a forum index:
example.com/viewforum/news/index.html
or a feed
example.com/viewforum/news/rss.xml
And so on.
I actually spent the morning today working on some rewrite stuff and the flexibility is pretty darn good. I just know from the Drupal community that there is a large interest in those using Lighttpd and trying to get clean URLs to work by moving over the apache rewrite. The directives are so simple but it doesn’t translate well I hear. I don’t want to see the punBB crowd fall into this after the fact. Good to catch this before it starte because some of us are using punbb for the speed and it is always nice to have the option to go further.
Anyone here run lighttpd?
April 12th, 2007, at 6:06 pm #Just found a little blurb about lighttpd at the vpslink forums that may be of interest:
mod_rewrite in Apache is simply much more powerful and flexible than the equivalent in lighty. First of all, you can’t do a condition on whether file/directory exists. You can’t do condition via external helper apps. You can’t rewrite to redirect, proxy or return special HTTP status. There are many open source applications actually “assume” they are behind Apache and assume the existence of Apache mod_rewrite (WordPress for example), and you are on your own to translate generated rewrite rules into lighttpd’s equivalent.
And lighttpd does not have .htaccess.
April 12th, 2007, at 7:02 pm #If by “assume” they meant specifically state that Apache’s mod_rewrite module is needed for an optional feature…
http://codex.wordpress.org/Hosting_WordPress
April 12th, 2007, at 8:24 pm #If you want nice URLs on a server that’s not Apache you will be able to write an extension for it. As long as the server can direct the request to a PHP page you can extract the information from the REQUEST_URI, fill the _GET array and include the required script.
There’s no way the PunBB team can write for every combination of server and database and settings. And it’s not hard to modify.
April 12th, 2007, at 9:11 pm #Richard,
That’s totally the wrong attitude to take. “There’s no way…”
What you are really saying is that “Punnbb will write within the limited knowledge of it’s developers and will not branch out of our comfort zone under any circumstances unless we really really feel like it. Like when lighttpd becomes a possibility for our own personal sites.”
I wasn’t asking you guys to write for every possible option. I was asking that you not enforce a strict configuration requirement to use a feature of your software. Not hard.
April 13th, 2007, at 12:26 am #richardk, when did you join the dev team. ;)
Hey, let’s’ not forget about other web servers and databases! But then there’s still that PHP requirement…
April 13th, 2007, at 2:30 am #Heh, would you rather they write outside the areas they’re knowledgeable of?
What specific thing about PunBB 1.3’s current setup kills the possibility of using the pretty URL feature with lighttpd?
Looking at PunBB, I see two pieces to this pretty URL feature: the `include/url/*.php` files (output) and the rewrite rules (input). Can rewrite rules not be written for lighttpd that will work with a set of URLs output by PunBB (existing ones or not)?
April 13th, 2007, at 3:12 am #Carl: First of all, don’t confuse me with “richardk”.
The only difference between what I referred to as an ugly hack and the solution you posted is the symlink to conceal .php? Come on, do you really think that solution is a good idea for PunBB? There are more people out there with .htaccess and mod_rewrite support than there are with shell access and any kind of idea how to create a bunch of symlinks. What this means is that fewer people would be able to use it and does that not defeat the whole purpose? Not to mention it’s a lot less flexible than mod_rewrite.
guardian34 asked an interesting question. What exactly is it in lighty’s rewrite support that makes it impossible to support? PunBB’s mod_rewrite rules are really simple. As long as lighty supports regular expressions in the rules, we should be fine.
April 13th, 2007, at 7:56 am #I have to agree with Rickard (not “richardk”) and Guardian34. PunBB does not exclude anyone with this *optional* clean URL feature and I can’t understand why lighttpd’s rewrite rules can’t incorporate exactly the same as Apache’s mod_rewrite rules. The syntax may vary, but I don’t believe that these rules are so complicated that lighttpd can’t cope.
April 13th, 2007, at 9:03 am #We did discuss lighttpd and support for their rewrite scheme is being looked at. The problem with lighttpd is that rewriting has to be done server wide so its fine if you’re running your own server but no use in a shared environment. Having said that, most people who are interested in lighttpd are probably running their own server more than likely for rails development.
An alternative is the free version of litespeed which I understand is compatible with apache’s way of doing things. I did actually test out a PunBB installation on litespeed. I thought it faster than lighty and it seemed to use rather less memory. Its also a joy to install and configure.
April 13th, 2007, at 7:20 pm #There we go guys,
First I get the typical programmer response…defensive “because” and not thoughtful….and I feel comfortable with that because that’s my job and if I insult you I insult myself and everybody I work with. So yeah, those weren’t great responses above. Again, for anyone who missed the point, I simply asked if you could find a solution so as not to enforce a strict requirement to use the clean URLs function.
For those that think PHP itself is a strict requirement then you missed the point. PHP is the language. I wasn’t asking you to port to ASP or better yet C, I didn’t ask you to pull support for Postgres or add support for flat files, and I’m not asking you to support TCP over carrier pigeon. I was asking you to sit down as a TEAM and come up with solution that wouldn’t kill the lighttpd group with rewrites, that’s all.
For guardian who said “Hey, let’s’ not forget about other web servers and databases! But then there’s still that PHP requirement…” That is completely irrelevant. PHP runs on many different webservers as long as you don’t enforce strict requirements for each, and ANSI SQL runs on EVERY SQL server as long as you don’t enforce non-ANSI functions - and I don’t think punBB does or they would be doing postgres date translation in postgres, not PHP. What you are saying would be akin to me asking you to port a function from PHP to C.
And with that said, we all spoke from our misunderstanding of lighttpd. Everyone says “I don’t see why lighttpd can’t…” but how the heck can we answer that if we don’t know lighttpd’s capabilities. I run Drupal. Drupal’s clean URL solution consists of….
# Rewrite current-style URLs of the form ‘index.php?q=x’.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
….and from the chatter I read on the net while installing my split bench with lighttpd THAT little tiny configuration is a pain to port. I just expressed some concern about that so maybe the dev team could think about our lighttpd brethren and save them some work!
And along comes Paul….who has the appearance of a real professional. This is the kind of guy I wished I worked with in my job too. So thank you Paul and I’m going to download litespeed free version and give it a whirl with punbb.
To the rest, pardon my candor….I haven’t had my meds yet. :)
April 14th, 2007, at 5:51 pm #Hope you weren’t put off by my facetious replies, Carl. FWIW, I was posting that while compiling lighttpd. :)
April 14th, 2007, at 6:35 pm #If I have in any way insulted you or replied in a defensive manner, I apologize. It was not my intention.
I took a quick look at the rewrite capabilities of lighttpd and it appears that support for PunBB’s rewrite scheme should be a breeze. Lighttpd supports standard internal redirects in much the same way as mod_rewrite does. When we do
RewriteRule ^user[/_-]?([0-9]+)(\.html?|/)?$ profile.php?id=$1
for mod_rewrite, we do
url.rewrite-once = ( “^user[/_-]?([0-9]+)(\.html?|/)?$” => “profile.php?id=$1″ )
for Lighttpd. Mind you, I haven’t tested this, but if I’m reading the manual correctly, it should work. The reason the drupal rewrite causes problems is probably:
“the lighttpd rewrite module does not allow you to pass through file/directory URI when using a global rewrite rule (”^(.*)$” => “index.php?q=$1″)”
That’s exactly what drupal does. It essentially instructs the webserver to pipe any URL into index.php via the querystring.
April 16th, 2007, at 2:42 pm #That’s for your comments both.
I’m going to have to download 1.3 and give it a try I think. I do have a lighttpd on one machine that I don’t want to scrap because it took about a day to setup - I’m 10 years into Apache and it is hard to think out of THAT box. If I get time I’ll have to try it on lighttpd.
Here’s a question. Any thought of database normalization in 1.3? I haven’t delved terribly into the db yet (using postgres) but for some manual updates that I had to make I have gotten in there. I noticed there were some things that aren’t in third normal form.
If you need anyone working on the postgres specific stuff let me know…
April 16th, 2007, at 8:24 pm #crud…first line should read
“Thanks for your comments both” …
not “That’s”
Geez! don’t do this stuff on spare time!
April 16th, 2007, at 8:26 pm #“Here’s a question. Any thought of database normalization in 1.3? I haven’t delved terribly into the db yet (using postgres) but for some manual updates that I had to make I have gotten in there. I noticed there were some things that aren’t in third normal form.”
April 16th, 2007, at 11:19 pm #Out of curiosity, what are you noticing that isn’t in third normal form? I’d be interested in looking into it as long as correcting for it doesn’t lead to slower and more complex queries :)
Higher levels of normalization usually always results in more complex queries, but to the same degree, it easens insert statements because the data is normalized.
To not have a normalized data model can often be premature optimization, in that it usually isn’t required until you experience problems with the model being too normalized in some circumstances. Then you have the option to either de-normalize it, or to transfer portions of the data into a mini-data-warehouse (just a set of read-only tables in the same database).
This is just general mumbling, though, since I haven’t delved deep into PunBB’s data model and don’t know whether it’s well normalized or not. :-)
April 17th, 2007, at 6:48 am #Regarding normalization. Initially, as in way back in the day, the database was normalized in the third normal form, but seeing the performance problems certain other bulletin boards were having (phpBB in particular), I decided to allow for some redundancy in order to speed up important queries. By far, viewtopic, viewforum and index are the most frequently accessed scripts in a bulletin boards and neither of these do any inserts so focusing on select performance over insert performance seems like the sane thing to do.
In general, I think it’s a good idea to have a completely normalized database (in 3NF or even BCNF), at least to begin with. However, I don’t believe there are a lot of high-performance web applications out that work with completely normalized databases. It just doesn’t scale.
Seeing as PunBB is one of the best performing bulletin boards out there and that this is one of it’s main “selling points”, I don’t believe further normalization is the way to go. Sure, if we can find a way to remove some redundancy without affecting performance, I’m all for it of course.
April 17th, 2007, at 9:15 am #That explains that. Denormalizing for important queries is the thing to do once you have some data.
Just curious, do you guys use any of the PHP profiling tools out there?
Also, if performance is an issue and you know where your bottlenecks are, have you thought of writing PHP extensions in C for those parts?
April 17th, 2007, at 2:43 pm #Sounds like you’ve taken the right route, Rickard. Something that can easen the work with a denormalized data model is using triggers or stored procedures when working with the data instead of loosely coupled selects within the PHP code, but since you’re supporting MySQL4, that’s afaik not an option.
I would eagerly look forward to dropping support for PHP4 and MySQL4 if I was a PunBB developer. ;-)
April 18th, 2007, at 6:55 am #Carl: Well, I don’t profile on a regular basis, but I have run the more important scripts through xdebug a couple of times. Before we release PunBB 1.3, I plan on doing a more thorough run-through of the source and also dig a little deeper into our databas queries. I ran into this the other day:
http://www.mysqlperformanceblog.com/2006/09/06/slow-query-log-analyzes-tools/
It’s a pretty good way of getting a grip over what the database is spending most of its time on. The good thing about this is that it can easily be applied to a live environment (which is much more interesting than my development machine).
I’ve thought about writing a PHP extension for all the message parsing, but my ideas never really amounted to anything. This sounds like something that the community could contribute with. Then again, in PunBB 1.3, the message parsing is basically a series of regular expressions so I’m not sure it would benefit much from being written in C. I have never developed an extension for PHP myself, but I guess the process is pretty straight-forward.
Asbjørn: Oh, I’ve been tempted to drop MySQL4, SQLite and Postgres a couple of times. Being able to rely on triggers, stored procedures, MySQL specific features as well as prepared statements with SQL parameters and not worry about database differences would be wonderful. I don’t quite think it’s time for that yet. Most web hosts still run PHP4 and MySQL4.
April 18th, 2007, at 1:22 pm #I just installed the APD extension from PECL and if I get around to running punBB through it I’ll let you know. It is nice because it can create a file that can be run through KCacheGrind which has a pretty nice interface. It basically let’s you know where the script is spending time. Rasmus mentioned not to make assumptions regarding what PHP is doing in the background, which brings me to….
…th extension. Community contributed would be good. It isn’t as easy as it looks from what I can tell. I’ve attempted it a couple times but it isn’t as simple as writing C by itself. PHP uses those symbol tables so everything has to go through a bunch of ZEND_ stuff.
Either way, I’d like to see more open source projects have PHP extensions available but the knowledge to write them seems well kept. Regardless, I’d still like to write some PHP extensions myself someday. Maybe this would be a good project to start with?
Oh, and PLLLEEEAASSEE don’t drop Postgres :) Postgres and performance are my 2 main reasons for running punbb. However, I would like to see some Postgres specific features as enhancements. Maybe you could develop with the idea that you’d have a mysql specific version and a postgres version. You know….
April 20th, 2007, at 3:27 am #I agree to the sentiment “don’t drop Postgres”, although I don’t have access to a Postgres database in a hosting environment myself these days. Postgres is, once it’s set up and properly configured, much more powerful than MySQL, even MySQL5. On a feature-basis, it can be compared to Oracle (the RDBMS, not the bloated application layer on top of it), and it even matches Oracle’s syntax in most areas.
When it comes to database specific “hacks”, I believe that enough abstraction in the data layer gives you the oportunity to “plug in” whatever database engine in the back end you want. Having SQL queries in the PHP files themselves without any abstraction between that and the presentation of the arrays they produce will make it difficult to change the database engine and the logic built around it. Creating such an abstraction is a lot of work, but people have done it before.
There are a lot of ORM (Object-Relation-Mapping) tools out there for PHP, but I’m not sure how they perform compared to how well PunBB performs now. An ORM layer at least gives you the abstraction you need to build the database layer, the object layer and the presentation layer independently. Then you can employ whatever database-specific hacks you want in the database layer without affecting the object or presentation layer. Might be worth a shot, at least in the long run. That is, if the performance is good enough (and I believe it can be).
April 20th, 2007, at 6:03 am #Sorry if I am asking a stupid question, but about PunBB 1.3 - when will it go into BETA? I’d really love to use it right now but I’m concerned if it’s stable.
June 6th, 2007, at 9:25 pm #“When’s it’s ready” has been the usual answer to everyone who has asked in the forums so far.
I often tell people to keep an eye on the tickets and the timeline (apparently there are people who don’t already subscribe to that RSS feed :P).
If you want to test the progress so far, then download the current subversion copy ( Downloading 1.3 from trac).
June 6th, 2007, at 9:49 pm #“Having SQL queries in the PHP files themselves without any abstraction between that and the presentation of the arrays they produce will make it difficult to change the database engine and the logic built around it. Creating such an abstraction is a lot of work, but people have done it before.”
Due to 1.3’s extension system and query builder, you should be able to modify faulty queries through an extension. So you could for example have an extension adding support for Oracle, MSSQL or Sybase.
A little sidenote to Carl: since the rewrite scheme isn’t at all required, I don’t see how support for lighttpd has been dropped. It’s not a vital part of PunBB, and as such isn’t a requirement. It’s merely an option.
June 13th, 2007, at 11:48 am #Hi,
I’ve been playing around with mod_rewrite a bit for FlatPress.
I’ve been hacked many regexes stuffed into my .htaccess and actually I was wondering how WordPress managed the entire thing.
Rickard, you talked about that index.php “ugly hack”, well actually that’s how WordPress works: they just parse the URL to get ‘arguments’ following ‘index.php’ in form of index.php/my/args/
http://codex.wordpress.org/Permalinks
The great thing is that this way the only job here for mod_rewrite is REMOVING the ugly index.php from the http://mysite.com/index.php/my/args/ to make it look like http://mysite.com/my/args/
which
a) makes the regex set trivial (only one RewriteRule)
b) leaves the job to parse the URL completely to PHP, where you have access to all of the users’ settings and sys variables (and a more flexible syntax :) )
the drawback is you’ve got to have a centralized index.php which handles all of the requests (in fact wp-admin is in a separate directory)
I hope this helps
bye
June 24th, 2007, at 9:18 am #NoWhereMan: I am aware of that, but the fact that we would have to pipe all requests through one script will mean a massive rewrite of the PunBB codebase. It should also be noted that the frontend of a blog such as WordPress is a lot less complex than for example PunBB. There’s only so much you can do in a blog frontend.
Maybe in a future version, we will look into doing something similar. Don’t expect it for 1.3 though.
June 24th, 2007, at 10:27 am #Of course I already thought *that* would have been the real problem, and I see the point, so I’m just saying “keep up your great work” :)
I’m looking forward the final 1.3 which already looks great.
Bye!
June 24th, 2007, at 12:26 pm #Wow, no activity on this blog in a while! However, I have an idea that can solve the problem space of having too many rewrite rules and having to rewrite PunBB to support the “one file serves it all” idiology. What you can do is have one rewrite rule that serves all PunBB URL’s to one file (since index.php is taken, just call it rewrite.php or whatever). Inside this file, you can inspect the URL and just require() the necessary files based on what the request looks like. Since this is an optional layer on top of the existing PunBB codebase, it won’t break anything. The only real change needed to be done is the forming of URL’s inside PunBB, but that work needs to be taken care of (and I imagine it already is) no matter how you do the rewriting.
This rewrite.php file can, for a URL like “/forum/19″ include the file “viewforum.php” with the “$id” set to “19″. For a URL like “/topic/2312″, it will include “viewtopic.php” with “$id” set to “2312″, and so on. I don’t think this should be too hard to implement and would make it fairly easy to administer the rewrites in the future.
September 17th, 2007, at 2:00 pm #Asbjørn: I had actually thought of this exact same thing before (I’m not certain, but is this what Wordpress does?). I can’t remember if I ever brought it up, but I’ll look into it again.
September 18th, 2007, at 1:37 am #This isn’t exactly, but close, to how WordPress does rewrites. WordPress can include literal “slugs” in the URL as well (something I wish PunBB could have too), but it’s basically like this.
October 9th, 2007, at 8:53 am #With that mod_rewrite setup, I don’t think adding slugs would be an issue.
October 9th, 2007, at 10:51 pm #