You are not logged in. Please login or register.
PunBB Forums → Posts by Justin
Rickard: While I normally feel it's important to provide basic customization options, I understand the desire for expedience. In the absence of customization options in the admin interface, it would probably be wise to at least provide customization instructions in the documentation somewhere.
Do you know when you might have something committed to Subversion? If you haven't guessed, I'm eager to help out with testing... 
Great work so far, Rickard. Bravo! 
If I access e.g. /punbb/forum/21/ and the URL gets rewritten to /punbb/viewforum.php?id=21, the actual PHP script is executed just fine, but a problem appears for the CSS includes.
While I'm quite familiar with mod_rewrite from the admin side of things, I know very little about the actual code generation. I'll see if I can get some feedback from those who can provide it better than I.
In Wordpress, you append e.g. /feed/rss/ or /feed/atom/ to the end of an URL to access the feed. Is there any reason why that is preferable to just /rss/ or /atom/ ?
The rewrite rules that WordPress generates are very flexible and will look for any of the combinations you mentioned above. For example, tacking the following onto the end of WordPress URIs will output the following XML feed formats:
/feed/ -> RSS 2.0
/feed/rss/ -> RSS 0.92
/feed/rss2/ -> RSS 2.0
/feed/atom/ -> Atom
/rss/ -> RSS 0.92
/rss2/ -> RSS 2.0
/atom/ -> Atom
As for how PunBB presents the links, ideally this should be configurable, such that the admin interface presents two options: no directory preceding the feed format, or a custom-entered directory name (feed, feeds, newsfeeds, xml, etc).
For your reference, I'm including below some rewrite rules that were generated by WordPress 1.5. The way this works is that you specify what you want the URI structure to look like in the admin interface, and then WordPress generates the rewrite rules corresponding to the entered template. For the purposes of this illustration, I used /forums/ as the base URI and entered the following as the URI structure:
/post/%post_id%/
WordPress then generated the rewrite rules below. While this obviously doesn't apply directly (WordPress isn't for forums 
), hopefully this will be of some use as a reference point. Let me know what you think.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /forums/
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [S=35]
RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?&feed=$1 [QSA,L]
RewriteRule ^(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?&feed=$1 [QSA,L]
RewriteRule ^page/?([0-9]{1,})/?$ /forums/index.php?&paged=$1 [QSA,L]
RewriteRule ^comments/feed/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?&feed=$1&withcomments=1 [QSA,L]
RewriteRule ^comments/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?&feed=$1&withcomments=1 [QSA,L]
RewriteRule ^comments/page/?([0-9]{1,})/?$ /forums/index.php?&paged=$1 [QSA,L]
RewriteRule ^search/(.+)/feed/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?s=$1&feed=$2 [QSA,L]
RewriteRule ^search/(.+)/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?s=$1&feed=$2 [QSA,L]
RewriteRule ^search/(.+)/page/?([0-9]{1,})/?$ /forums/index.php?s=$1&paged=$2 [QSA,L]
RewriteRule ^search/(.+)/?$ /forums/index.php?s=$1 [QSA,L]
RewriteRule ^post/category/(.+)/feed/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?category_name=$1&feed=$2 [QSA,L]
RewriteRule ^post/category/(.+)/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?category_name=$1&feed=$2 [QSA,L]
RewriteRule ^post/category/(.+)/page/?([0-9]{1,})/?$ /forums/index.php?category_name=$1&paged=$2 [QSA,L]
RewriteRule ^post/category/(.+)/?$ /forums/index.php?category_name=$1 [QSA,L]
RewriteRule ^post/author/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?author_name=$1&feed=$2 [QSA,L]
RewriteRule ^post/author/([^/]+)/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?author_name=$1&feed=$2 [QSA,L]
RewriteRule ^post/author/([^/]+)/page/?([0-9]{1,})/?$ /forums/index.php?author_name=$1&paged=$2 [QSA,L]
RewriteRule ^post/author/([^/]+)/?$ /forums/index.php?author_name=$1 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/feed/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?year=$1&monthnum=$2&day=$3&feed=$4 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?year=$1&monthnum=$2&day=$3&feed=$4 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/page/?([0-9]{1,})/?$ /forums/index.php?year=$1&monthnum=$2&day=$3&paged=$4 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/?$ /forums/index.php?year=$1&monthnum=$2&day=$3 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/([0-9]{1,2})/feed/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?year=$1&monthnum=$2&feed=$3 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/([0-9]{1,2})/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?year=$1&monthnum=$2&feed=$3 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/([0-9]{1,2})/page/?([0-9]{1,})/?$ /forums/index.php?year=$1&monthnum=$2&paged=$3 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/([0-9]{1,2})/?$ /forums/index.php?year=$1&monthnum=$2 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/feed/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?year=$1&feed=$2 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?year=$1&feed=$2 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/page/?([0-9]{1,})/?$ /forums/index.php?year=$1&paged=$2 [QSA,L]
RewriteRule ^post/date/([0-9]{4})/?$ /forums/index.php?year=$1 [QSA,L]
RewriteRule ^post/([0-9]+)/trackback/?$ /forums/index.php?p=$1&tb=1 [QSA,L]
RewriteRule ^post/([0-9]+)/feed/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?p=$1&feed=$2 [QSA,L]
RewriteRule ^post/([0-9]+)/(feed|rdf|rss|rss2|atom)/?$ /forums/index.php?p=$1&feed=$2 [QSA,L]
RewriteRule ^post/([0-9]+)/page/?([0-9]{1,})/?$ /forums/index.php?p=$1&paged=$2 [QSA,L]
RewriteRule ^post/([0-9]+)/?([0-9]+)?/?$ /forums/index.php?p=$1&page=$2 [QSA,L]
</IfModule>I understood Rod's point of view much better before the "book" analogy. You've already made the "I want multiple windows open" argument, and we've already debunked said argument (several times) by pointing out that you can already do what you want without forcing new windows on people who don't want them.
Then you shift gears and decide your argument isn't about books and dictionaries, but about trying not to "loose" your site viewers. As I suggested previously, it's sad that some site developers consistently put their own interests ahead of site users, all the while maintaining that it's for the users' own good.
I suggest we simply agree to disagree on this topic.
Rod: While using Javascript is preferable than target=_blank, it seems you are missing the point. The consensus of many veteran web developers is that users should not have new windows foisted upon them without their consent. Clearly you disagree, as is your perogative.
The W3C is not infallible, but as Connorhd pointed out, your example stinks. The IFRAME should be taken out back and put out of its misery. And just because the W3C decided to cave and allow it to validate does not mean developers should actually use it. So to answer your question: No, it's not funny.
You're probably right about most people not knowing how to cmd-click a link to open it in a new window. So what? The link opens in the same window, as it should. If they want to look at two windows simultaneously, they can take a few moments to learn how. I think it's silly to suggest we should baby this subset of users by spawning new windows; why should everyone else have to suffer?
It's not the W3C which gives the way : but the user.
This is indeed about the user. And, thankfully, the W3C is one of the few organizations that actually puts users first, which is more than I can say for many self-serving site developers.
But that's just my opinion. I could be wrong. And on that note... have a great weekend! 
Justin...I 'll see your Ugh and raise you an Um? Are we still talking about a link opening up a new window?
Yeah, last time I checked.
That's all? Not cars fuelled by water, world peace or female adult movie stars not having that annoying tattoo above their bum? (so I've been told)
Uhh, sure dude. Whatever you say.
Please define "responsible 'Net citizen" for me, if you could be so kind.
Sure, although this really should be obvious by now. In the context of what we're talking about, it means site developers should simply let users have the choice of whether to spawn a new window or not. Taking away that choice is, in the opinion of many influential folks (including the W3C), not behavior becoming of a responsible 'Net citizen.
As to the top 10 link...I said it looked crappy....I didn't say that the content shouldn't be considered valid. My apologies if you didn't understand that...I just thought it rather funny that the page didn't look very well designed
No worries. It sounded a lot like:
Site looks crappy -> author doesn't know much about design -> ergo, the suggestions aren't valid
I understand your perspective, but note that we're not talking about subjective aesthetics here. We're talking about site functionality.
Andy: I agree. Linux on the desktop just isn't there yet. Then again, looking at MacOS X, neither is Windows really
Hehe... Couldn't have put it better myself!
Mac is pretty and stable, but hardly offers the plethora of applications that Windows does.
More != Better. Yes, there are more software applications available on Windows than for the Mac platform. But that's usually only a problem if one requires niche vertical market software packages (e.g., risk analysis for oil drilling). For most people, including power users, there are very few cases where equivalent (or better) software tools aren't available on Mac OS X.
It's also worthwhile to point out that, in my experience, the quality of Mac software applications is far superior to those developed for the Windows world. Your mileage may vary.
Perhaps a point in favour of Rod is that it's his forum on his site, so it's his choice as to whether links should open in a new window or not.
So if Rod figures out how to implement a "feature" that bypasses past your pop-up blocker and spawns 86 windows full of epilepsy-inducing Flash advertisements, you're cool with that, right? Or how about a feature that grabs all your personal data from your hard drive? After all... It's his forum on his site, right?
Just because it's your site doesn't mean you shouldn't be a responsible 'Net citizen.
(If you don't like the analogy... tough. That's why it's called hyperbole.)
Oh....and the Top Ten Mistakes of Web Design linky...mmm...sorry to be blunt, but it's a bit of a crappy looking site really...not the best of advertisments
Ugh. So because you don't care for the design, the content contained within shouldn't be considered valid? Moreover, I don't think that page looks crappy -- it's just not flashy or stylish. It's not designed to be.
If you want more ammunition, no problem. There's also a bunch of related links at the end.
The consensus at Mozilla at the moment is that the security risk outweighs the benefits of IDN support. I speak Japanese fluently and love the idea of international domain names, and yet I agree with Mozilla's assessment.
Don't get worked up over this. This is a short term step for them. They plan on re-enabling IDN support in future releases, assuming they can devise a solution to the spoofing problem in the long term.
You're missing the point, Rod.
You already have exactly what you want, even without having links open up in new windows by default. Right-click on the link and choose "Open in new window," or simpler yet, hold down a modifier key when clicking on the link (command key on Mac OS X -- don't know whether it's ALT or CTRL on Windows). Your "problem" is solved.
The concern about losing (not "loosing") viewers as they browse external links is, in my opinion, completely misguided. If they don't click the Back button to return to you, then you probably weren't offering much of interest in the first place.
This is a problem of accessibility. More importantly, it's a question of choice. If I don't want a new browser to open, that should be my choice. Period. It sounds like you don't want people to have that choice.
But don't take my word for it. Number 2 on the Top Ten New Mistakes of Web Design? Surprise, surprise: Opening New Browser Windows.
Opening up new browser windows is like a vacuum cleaner sales person who starts a visit by emptying an ash tray on the customer's carpet. Don't pollute my screen with any more windows, thanks (particularly since current operating systems have miserable window management). If I want a new window, I will open it myself!
Justin: I'm no longer considering it, I've decided to implement it. It won't show up until PunBB 1.3 though.
Very excited to hear that, Rickard. I would love to help you test this as soon as you are ready. I have no fewer than three site launches that are on hold until I can implement the above-mentioned URI permanence for them.
I have to honest though, I have never ever played with URL rewriting so my knowledge of what's possible is very limited.
That shouldn't be a problem. Once the PunBB code outputs the custom link URIs, the mod_rewrite rules are just a few lines of regular expressions and shouldn't take more than an hour or two to write (if that). As I mentioned before, I highly recommend taking a look at the WordPress 1.5 code and re-write rules. They did a great job. That said, maybe you should take a crack at it first and then compare; you might come up with an even more elegant solution.
I hear what you're saying regarding forum URIs and I will consider it. However, in my experience, people don't link directly to individual forums that often. Almost all links to a forum or within a forum are links to individual topics or posts. Don't you agree?
Yes, you are quite right -- most people link directly to individual topics or posts. I just thought it would be a nice option for some folks, but by no means as valuable as the other points under discussion.
Looking forward to receiving the first bit of code to test...
maybe its better to let the idea that your going to have "idless" URIs die
I can understand the argument that ID-less URIs for topics and posts imay not be realistic, which is consistent with what I already wrote above. For forums, however, I can think of no reason not to provide the admin with the option to use a unique string in place of the forum ID.
adding a extra pointless bit to the end is pointless
1. What is pointless to some may not be pointless to others.
2. Semantic URIs improve readability and may improve search engine index relevancy.
3. Semantic URIs for topics and posts are, as I mentioned above, more difficult to implement. That's why I added that as an aside instead of including it in the main thrust of my post. The idea was to bring up what might be possible in the pursuit of more semantic URIs. The main portion of my post is where I believe the most valuable suggestions lie. The aside was more along the lines of "food for thought."
what happens when people use "dodgy" characters?
They get sanitized or discarded. End of problem.
Hi Rickard. I think it's fantastic that you're seriously considering this important topic, and your proposed solution may indeed work well. As you point out, search engine indexing should not be an end goal, since nearly every search engine already indexes URIs with parameters in them. The true goal, as GUI already pointed out, is future proofing.
If future development needs require, for example, a switch to a Python or Ruby-based solution, the presence of the script names and extensions becomes yet another legacy hassle to support (see Rickard's sig ). Much preferred would be agnostic, forward-looking URI structures such as:
http://punbb.org/forums/forum/40/
http://punbb.org/forums/topic/6254/
http://punbb.org/forums/post/34299/
In addition, it would be nice if an optional custom URI function were available for the places that make sense. For example, an additional field in the forums table called "forum_uri" could store the bit to append to the forum URI. Using this option would, for example, produce forum URIs that look like:
http://punbb.org/forums/forum/news/
http://punbb.org/forums/forum/reports/
http://punbb.org/forums/forum/requests/
http://punbb.org/forums/forum/troubleshooting/
...etc.
I would like to also take this opportunity to mention what I believe would be one of the best bang-for-buck feature additions to PunBB: ubiquitous feeds. Both per forum and per topic, in RSS and Atom. Following the same URI philosophy noted above, these might look like:
http://punbb.org/forums/forum/40/feed/rss/
http://punbb.org/forums/forum/news/feed/rss/
http://punbb.org/forums/topic/6254/feed/atom/
The "price" to implement this should be very low, both in development time and code complexity. It would add enormous functionality without adding any bloat.
Of course, if extern.php already has the ability to generate per-topic feeds (it doesn't appear to, but I could be wrong), then all that would be needed is to perform the same URI magic as the forum, topic, and post URI structures.
If you would like to see where this has been done extremely well, look no further than WordPress (incidentally, WordPress 1.5 was just released today). WordPress has ubitquitous feeds in a clean URI structure: just tack on /feed/ to almost any URI to produce an XML feed. Brilliant.
Thanks for listening. I look forward to your feedback!
Justin
Aside:
It's easy to see the sense in allowing for semantic URIs for forums. Creating semantic URIs for topics and posts (without any IDs), on the other hand, would probably be difficult due to the need for them to be unique. But semantic data could be appended to the end of the ID if a "slug" field were available to folks when creating new topics or posts, producing URIs such as the following:
http://punbb.org/forums/topic/6254/clean-uris/
http://punbb.org/forums/post/34299/permanence-is-key/
In this scenario, the code would display -- but internally ignore -- the appended slug, grabbing instead what it needs from the preceding information in the URI (e.g., "topic" and "6254").
PunBB Forums → Posts by Justin
Powered by PunBB, supported by Informer Technologies, Inc.