I don't think restructuring the profile page is a huge job, it's mostly re-shuffling the HTML output. But hey, you're the boss smile

Regarding which options to include, here's my vote:

[] Show smilies as icons

[] Show images in posts

[] Show avatars.

[] Show user signatures
. . . . [] Show images in signatures

So there's 4 options with one "sub-option". I really thnk there should be the capability to turn signatures off entirely. If that option is included, "Show images in signatures" is dependent on whether or not it is set. You could disable "Show images in signatures" with javascript unless "Show user signatures" is set.


[] Open links in new window.

Modern browsers like Mozilla and Opera are all about placing more control of the browsing experience into the hands of users. With respect to opening new windows, these browsers provide several techniques for doing so (context menu, shift- or control-click, etc.) I'd suggest removing this option (and setting links to open in the same window in the PHP code). That lets the user control the opening of new windows on a per-click basis using their browser's capabilities.

Did you see this thread: http://punbb.org/forums/viewtopic.php?id=3543

I don't disagree with any of you remarks & suggestions, except perhaps your initial comment regarding the stats you present:

Rickard wrote:

...What this means is that only a fraction of a percent of all the users in these forums want to hide images, avatars and/or user signatures.

I would argue that it means that only a fraction of a percentage of users:

1. Are aware that capability exists to turn these thing off, and;
2. Have gone looking for a way to turn them off, and;
3. Have decided to turn them off.

A majority of users do not change options, regardless whether it's in a forum profile or a desktop application (e.g. word processor). That's not a reason IMO to remove options -- though obviously Firefox developers might argue smile

It might be interesting to look at the percentage of users who have changed their timezone. For those who haven't, I wonder is it because they live in GMT or because they are not aware that the capability to do so exists?

A great many users, especially less seasoned ones, will tend to not use the profile. In it's current state I think it is too wordy, too long, and not focused -- please don't take that as criticism. I'd like to see it restructured so that it displays in a 800x600 window with no scrolling, and presents a series of checkboxes and textfields organized in  categories. Help for each item would be provided separately in a small popup window.

Which leaves the question (your original question!) of which options to include. Perhaps it might be useful to start a list of potentials, organized by category? e.g.,

- Real name
- Email
- etc.

- Show smilies
- Show images
- etc.

- Show signatures
- Show images in signatures
- etc.


I use ImageMagick a fair bit. Resizing is quite easy, for example,

$imginfo = exec("/usr/bin/identify $imagename");
$dimensions = explode(" ", $imginfo);
$dimensions = $dimensions[2];
$dimensions = explode("x", $dimensions);
$width = $dimensions[0];
$height = $dimensions[1];
if ($width > 60 || $height > 60) {
  exec("/usr/bin/mogrify -resize 60x60 -quality 80 +profile '*' $imagename");

-resize : sets the maximum height or width, preserving the aspect ratio;
-quality : sets the jpeg image quality/compression;
+profile '*' : strips out any header information stored in the image. For example, a photo from a digital camera will contain headers that add about 10kb to the image filesize and will be kept even in a tiny thumbnail if you don't strip them.

Needless to say, you have to adjust for your path to the ImageMagick binaries (/usr/bin in this example).

Maybe there's a simpler way of getting image dimensions with ImageMagick, dunno. I know it's easier with the GD library, but (IMO) ImageMagick produces much better quality results on resizing than GD.


(4 replies, posted in Feature requests)

After removing the Moderator column you may also want to re-adjust the percentage width of the remaining columns, to suit your preference and so that they total 100%.


(38 replies, posted in PunBB 1.2 discussion)

I find Wakka Wiki to be quite nice -- http://www.wakkawiki.com/WakkaWiki

Lightweight, very easily set up and customized. See my own installation here: http://www.labradorstraits.net/wiki/

You can easily incorporate add-on things (PHP coded) like for example the download section on this page: http://www.labradorstraits.net/wiki/MozillaBuild

The "Username" field could be a bit confusing or off-putting for some Guests. Perhaps it could be labelled "Your Name" or simply "Name" for guest posting? In other words, a separate (new) item in the language file and accompanying code to switch between  displaying 'Username' and 'Your Name' (or whatever). Just a thought.


(18 replies, posted in Feature requests)

GMT+3:30 Tehran, Iran
GMT+4:30 Afghanistan
GMT+5:30 India
GMT+6:30 Cocos Islands
GMT+9:30 Darwin, Adelaide
GMT+10:30 Lord Howe Island
GMT+11:30 Norfolk Island
GMT-3:30 Newfoundland



(18 replies, posted in Feature requests)

It's designed specifically to give local Internet IT developers a 1/2 hour jump on the rest of North America. wink


(7 replies, posted in PunBB 1.2 discussion)

So much faster smile

We'll see if there's any reaction from other users here.


(18 replies, posted in Feature requests)



(18 replies, posted in Feature requests)

Not sure if this is a feature request or a bug report smile

My timezone is not included -- it's GMT -3.5 hours (-2.5 hours during daylight savings time).

It was easy enough to modify the forms in profile.php and admin_options.php to add options for GMT -2.5 and GMT -3.5, but the database field where the timezone is stored also had to be changed. It's currently an integer; I changed it to floating point (3,1).

Also in register.php, line 159 had to go:

$timezone = intval($_POST['timezone']);


(7 replies, posted in PunBB 1.2 discussion)

No, I'm not saying those headers are useless. Quite the opposite; they are extremely effective. What I'm saying is that (again, my opinion) browsers should ignore these headers when going Back/Forward. But mainstream browsers IE and Mozilla don't ignore them.


1. I visit http://punbb.org/forums/index.php
2. I click the link for "Pun discussions" and go to http://punbb.org/forums/viewforum.php?id=40
3. If at this point I click the link "Home" to re-visit http://punbb.org/forums/index.php then yes, the cache headers should cause the page to be re-checked and re-fetched. But if I simply click my Back button, then the page should not be re-fetched -- but it is.

The other four header lines in header.php are quite sufficient to ensure that people are not getting stale pages:

header('Cache-Control: post-check=0, pre-check=0', false);
header('Last-Modified: '.gmdate('D, d M Y H:i:s').' GMT');
header('Expires: Thu, 21 Jul 1977 07:30:00 GMT');
header('Pragma: no-cache');

None of these headers interfere with "normal" navigation using the browsers Back and Forward.

Opera's caching options are different from IE and Mozilla. Instead of "automatic" or "per session" settings, cache settings are based on time (5 minutes, an hour, 5 days, etc.) Alternatively you can opt for "always", which is what I do. This doesn't mean that pages are always re-fetched, it means that pages are always checked for changes. Only if the server reports change is the page re-fetched, otherwise it s loaded from cache.

I have a login on my website with a meta-refresh page and it works fine with Opera set like this. Not with Netscape 4 though, but that's another story, best forgotten smile

In a nutshell, I think "header('Cache-Control: no-store, no-cache, must-revalidate')" serves no useful purpose (when bundled with the other cache-limiting headers), and in fact hinders browsing for people on low bandwidth / high latency connections.


(7 replies, posted in PunBB 1.2 discussion)

Opera will always ignore the "Cache-Control: no-store, no-cache, must-revalidate" headers on back & forward. It'll load the requested page immediately from memory cache. There is no way I know of to change that (smart design I'd say!) Of course it honours those headers when a page is re-requested, say by clicking a link or loading a bookmark. This is the way it should be (IMO).

Mozilla and IE 5 & 6 will check/re-fetch on back/forward. I haven't had an opportunity to check with other browsers.


(7 replies, posted in PunBB 1.2 discussion)

I've noticed that several recent BB releases (including punBB) are setting a series of no-cache headers. For punBB these are set in headers.php and consist of:

header('Cache-Control: no-store, no-cache, must-revalidate');
header('Cache-Control: post-check=0, pre-check=0', false);
header('Last-Modified: '.gmdate('D, d M Y H:i:s').' GMT');
header('Expires: Thu, 21 Jul 1977 07:30:00 GMT');
header('Pragma: no-cache');

The result is that when using the "Back" or "Forward" functions in a web browser, the browser will re-fetch a page from the web rather than load it from cache. I realize that this is personal preference, but for me this is a PITA. I'm on either a low-bandwidth dialup or a high-latency satellite connection, and this re-fetching make navigating a BB really slow. (VB3, with it's many graphics, is a particular nightmare.)

I've experimented a bit with these no-cache headers and found that just one of them causing this re-fetching on Back or Forward. I've disabled it on my punBB at http://www.labradorstraits.net/forum/ :

//header('Cache-Control: no-store, no-cache, must-revalidate');

The purpose of no-cache headers is to ensure that the reader sees most recent content. However, I would argue that re-fetching a page on Back or Forward is wrong, as that is not the intent of these functions. When I hit "Back" I want to go back to exactly what I was looking at previously, not "back" to a now-revised copy of that page.

New post markers and cookie updating work just fine on my board with the above cache header disabled. And I can flip back and forth between pages without re-fetching from the web each time.

I'd be interested to hear any comments others may have on this.

One small issue: the converter choked on importing forums with an apostrophe in the Forum Name, e.g., John's Discussions.

In _forums.php I changed line 18 to read:


and then the conversion worked like a charmed.



(3 replies, posted in PunBB 1.2 show off)

I've been looking for punBB for years smile

Lightweight, easily customized, and works a treat. Thanks.

I spent yesterday writing a converter for an ancient XMB board. I think I finally got it: