(15 replies, posted in PunBB 1.2 troubleshooting)

Paul wrote:

#punwrap {margin: 0; padding: 0; overflow: hidden}
.pun {float:left; width: 100%; height: 100%}
* html .pun {width: auto}

Bingo! Works like a charm. Can't thank you enough Paul.

I had tried making punwrap the float, but didn't try it on .pun.

Just a quick question. If the behavior of the above code is less likely to cause problems with a sites layout then the default code, is there any reason that the above shouldn't be default? I don't have a problem updating myself, I was just thinking if it prevents problems from happening for other people in the future, that is a good thing.


(15 replies, posted in PunBB 1.2 troubleshooting)

Paul wrote:

First of all, it's not the clearer divs which cause the problems, its clearing floats. If you get rid of the clearer divs then you will have to find an alternative method of containing floats or your forum will just collapse in a heap (except in IE). The method I'm using now still uses clear:both, it just does it without needing an empty div.

Before I struggle with it on my own, mind if I ask you a quick question?

The problem is, with my site, that before the content of the page there is a nav system that I am floating left. So when punbb clears both, it makes the punbb block that cleared extend the whole height of my nav system, which is totally unacceptable.

I couldn't think of a way to modify my layout (I use to absolutely position the nav, but I had to float it so that the footer of my page would always stop at the bottom of it (with some negative margin and clear magic)) even if the content was shorter, so thats why I was looking at modifying punbb's layout instead.

Its all fine if your just using punbb by itself, but if you are embedding it within your sites design, that can cause headaches. Many complex css layouts use floats to accomplish their magic.

Paul wrote:

As for the markup changes, they are more significant than I first thought. Basically I've been deleting stuff from the markup and adding more css. Yes it will be a headache to update your stylesheets.

Alright. I'm all for improvements, so its OK by me. I figure since by the time 1.3 comes out my actual forum will be running already, I'll just give myself a test 1.3 environment to tinker with till I have it the way I want it.


(15 replies, posted in PunBB 1.2 troubleshooting)

I know that in the upcoming 1.3, Paul has markup changes including the removal of the clearer DIVs.

However, right now 1.3 is not out, and I am putting the final touches on my forum. The clearer divs are interfering with the sites design. I had heard some people mention in the forums they have removed the clearer divs on their own. So I though, before I reinvent the wheel myself, could any of you share your changes?

Also, if you see this Paul, how significantly will the markup changes in 1.3 affect 1.2 styles? Will it be a huge headache to update them?


(2 replies, posted in PunBB 1.2 troubleshooting)

Well, because the pages with the admin forms are completely outside of PunBB.

But, you got me thinking, and by including config.php, common_db.php, functions.php, and search_idx.php, I was able to just straight use them!

So thanks for sparking my mind. That and I guess actually going to sleep helped me think clearer smile

Its all working great now.

PunBB rocks!


(2 replies, posted in PunBB 1.2 troubleshooting)

OK, first off, this isn't a bug or anything with PunBB. This is just something I am trying to do with it.

So here is my situation. I am creating a site where the administrators can add new entrys to the site via easy to use forms (which have nothing to do with punbb). I am working on implementing a "forum robot" that, when a a new entry is added to the site, the robot makes a new post in a new topic in a certain forum on my forums about that entry.

SO, I opened up post.php, and start mimicking what I saw.

Currently, my robot works great. The posts go in, and I have every part of it working BUT these two commands:

update_search_index('post', $new_pid, $message, $subject);

So, I looked at update_search_index, and said "yikes!". So I thought, screw it, the forum robots posts wont show up in searches.

I tried implementing a copy of update_forum, but I just havent been able to get it working yet. I know with persistance I can, but I wanted to ask here first.

Anyone have an idea of an easier way I can call these two functions from an outside script?


(29 replies, posted in PunBB 1.2 discussion)

Paul wrote:

I would have said B (if I'm wrong a panic attack will shortly ensue)

Hehe, don't panic, I really only needed an ultra, ultra rough time estimate.

Rickard wrote:

I would like to answer A, but I'm afraid if I do, I'll just miss the "deadline" smile It all depends on how much stuff pops up.

No, no, not a deadline! I just wanted an idea.

I'll go ahead and invest some time into customizing my punbb, and just redo it later if I need to. Don't we live for this stuff anyway?

Thanks again you two.

Rickard wrote:

Turns out, the sort order of items returned by the dir class in PHP is system dependant.

Yea, I figured as much.

Rickard wrote:

The call to reset() is not required.

OK, I wasn't sure so I had added it.

Thanks Rickard!


(29 replies, posted in PunBB 1.2 discussion)

Well, sounds good to me. I think moving to UTF-8, if reasonably doable, is a good idea, and I think making the output xhtml+xml is a VERY good idea.

Thanks again for your hard work you two. Oh, and I like both your signatures.

Anyway...I almost hate to ask, I know how working on projects like this is, but, perhaps could you give me an ultra rough guess on the release date for 1.3. Literally choosing between these two would be nice for me to know at this point:

A. Punbb 1.3 might be out in less then two months.
B. Punbb 1.3 will probably take more then that.

Because if its going to be out in a few months or less, I'm not gonna go all out customizing my current install. You don't have to answer though smile


(29 replies, posted in PunBB 1.2 discussion)

If you guys make these changes, do you think they'll make it in 1.3?

I ask simply because if they will I'm not gonna bother with some CSS styling I was gonna do.


(29 replies, posted in PunBB 1.2 discussion)

Rickard wrote:

I have a question. Does sending stuff as application/xhtml+xml affect what happens when a page is not well formed?

A (usually ugly) XML error message is displayed.

Paul wrote:

There is no way I would suggest serving PunBB as application/xhtml+xml for the reason you gave. A non-valid page served as application/xhtml+xml will simply fail to output completely though you might get a polite xml error message.

As much as I hate to say it, I agree here. By DEFAULT punbb should not do content negotiation, because for the people out there who think they are writing xhtml and aren't really when they install punbb and their pages break, they'll blame punbb.

What I suggest is getting punbb's markup to be capable of being served as xhtml+xml. I also don't see a problem with adding content negotiation to punbb, but defaulting it to off.

Paul wrote:

What I was contemplating is auditing the markup and css so that it is capable of being served as application/xhtml+xml...

Speak of the devil, just what I was saying smile. Some of the UTF-8 pages I link to below have some cool functions for converting character references and entities to UTF-8.

Rickard wrote:

I'm seriously considering going all UTF-8 in PunBB 1.3 to avoid the content type soup. This will lead to some problems for people running MySQL 4 and earlier and it will slow some things down a big, but I really have no idea how much.

I am all for full UTF-8 support, I think it would be a great idea.

How were you planning to do it? Why do you think it will have a noticeable speed impact. There is a lot of great info out on the web about converting stuff to UTF8:
http://annevankesteren.nl/archives/2005 … mment-3988

Anyway, the only real pain is the MySQL 4 thing. Many people with shared hosting are probably still on 4.0.x MySQL installations. If you switched to full UTF-8 support, what would happen to those people with older 4.0.x MySQL set ups?

Paul wrote:

As regards UTF-8, my only concern is that PunBB's major selling point is it's speed and I'm sure many people who use it accept the absence of some features only because they think its a good trade off to get a blisteringly fast forum. Anything that lessens that speed advantage really needs to be thought about very carefully.

I agree that anything that lessens the speed needs to be thought about carefully, to a point though. Yes obviously I am willing to not have a PM system (isn't that why we have email?) for a speed increase, but here we aren't talking about a feature, we are talking about the quality (and usefulness) of the code output.

Actually, the 100% proper way is:

        //sort styles alphabetically

I'm not sure how the current order is determined. I'm pretty sure the default styles were in order, and it didn't get whacky still I started customizing it (which involved removing all the defaults and having all my own).

So, if you haven't changed from the defaults, maybe thats why.

Or if you have changed from the defaults, there is always the chance that the random ordering it does ended up being alphabetical for you. Less styles you have, the higher that chance.

Either way, it should still be fixed smile

Well, the fix would take all of several seconds to implement.

Does it matter? I think having it sorted alphabetically makes more sense then no sorting at all. When you start having a decent amount of styles, the list looks funky having no order. The usability is increased with the list being in alphabetical order.

It seems the expected behavior for the styles drop down menu would be for them to be in alphabetical order, rather then the meaningless order they are in now.

I have already fixed it here:


But I figure the change should be made in punbb itself because I think this is a better behavior.


(29 replies, posted in PunBB 1.2 discussion)

Alright. Thanks again for your work Paul.

So in other words, its not sorted by default?

It seems the expected behavior would be for styles to be in alphabetical order.

Its an easy fix. Find this line in profile.php (line 1352 in unmodded punbb):

// Only display the style selection box if there's more than one style available

and immediatly before it add

        //sort styles alphabetically

I'm new here. What is the best way to get bug fixes to Rickard? Does he check these forums regularly? Should I poist in the bugs section? Or email him?


(29 replies, posted in PunBB 1.2 discussion)

Paul wrote:

I write the markup and css.

Cool. Well, well done! Punbb has very slick markup. When I was looking at message board software I was blown away when I found this.

Paul wrote:

I just posted the question because I wanted to see what level of interest, if any, there was in part because I saw a similar discussion somewhere regarding TextPattern. There is no possibility of going back to html. Neither is there any possibilty of content negotiation (unless I'm told different). The notion I was toying with was whether the markup and css should be put into a state where it could be served as xhtml. That way anybody who needed or wanted to serve it as xhtml would still have to mod PunBB but they wouldn't have the tedious job of having to sort out a lot of error generating markup and css as well. Put another way, going from xhtml 1.0 Strict to xhtml 1.0 Really Bloody Strict.

Sounds good. I pretty much figured that was the situation.

Well, count my vote on getting the xhtml working under very strict parsing smile. Have you asked Rickard about it?


(29 replies, posted in PunBB 1.2 discussion)

Okay, I fully switched over to using xml-stylesheets, still didnt fix it. Making the css lowercase helps alot, but the pages still flow wrong. Stuff that should be to the left is not.

I won't post my updated content negotiation code unless I get asked for it. I don't mind though, if its wanted.

So lets get this working in xhtml mode!


(29 replies, posted in PunBB 1.2 discussion)

Found the xml stylesheet stuff. Gonna see if it makes a difference.



(29 replies, posted in PunBB 1.2 discussion)

Oops, I hit reply hours ago and so I didn't pick your edit.

Paul wrote:

The real questions is whether it is worth the bother but fortunately thats not my call.

Whose call is it? Lets get them in this discussion!

Paul wrote:

Of course, what might tip the balance is if IE7 can accept the correct mime type though I somehow doubt that will happen.

I highly doubt that as well. I don't expect much at all in the realm of standards from them. All they've done so far is fix a few css bugs, ones that we had already figured out btw.

And one more thing, there is a reason XHTML 1.1 and the 2.0 draft don't have the HTML backwards compatability clauses that xhtml 1.0 had in its transitional spec. And that is because in retrospect, it was a bad idea that caused this mess xhtml is in now.

And one last thing, after rereading my last post, this is all meant to be positive feed back people smile I LOVE punbb, and thank everyone who has worked on it.


(29 replies, posted in PunBB 1.2 discussion)

Paul wrote:

Thanks but I have it running on a test bed with content negotiation already except I see no reason to change the doctype for IE, just send it text/html.

Content NEGOTIATION goes beyond just sending a mime type.

Take the doctype for example. You know that sending xhtml as text/html causes it to be parsed as html, yet you see nothing wrong with still declaring it as xhtml? Because there is something wrong there.

And saying "well, it works", isnt a good response. The crappy output of PhpBB "works", but obviously you and me would agree punbb's is far, far better.

Your giving a browser xhtml, knowing that it is parsed as html, and still calling it xhtml.

Proper content negotiation involves more then that. First, it involves determining what a broswer PREFERS based on its requests. Not just saying "oh i know i should give browser x this and browser y that", but actually obeying the Accept header.

Second, it involves actually giving the browser what it prefers. Just sending the mime type isn't enough, you must send your document as html, not xhtml. That means taking xhtml (ex: <br />) and making it html (ex: <br>). Sending the "/>" to a browser that is parsing as html is wrong, because it is NOT VALID html. It should be interpreted as "tag terminator followed by a greater-than sign", but most browsers ignore the / and treat it as a >. That doesnt mean we should keep doing it the wrong way.

Try validating an xhtml page as html. Doesn't work, does it?

Proper content negotiation involves giving a browser what it prefers based on its accept header, and actually transforming that content to be the proper media.

Paul wrote:

The reason the stylesheet fails is that its partly uppercase plus the imports might be causing difficulty. It really should be sent as an xml stylesheet as well.

No, imports work fine in xhtml. They have the added benefit of being not supported in old browsers (IE and Netscape 4.x), which are browsers that are not likely to understand even moderately complex css anyway.

As far as "should be sent" as an xml stylesheet, are you sure about that? Does it say that anywhere in the CSS or XHTML specs? I was lead to believe that adding the xml namespace to the LINK attribute was perfectly OK. This may be wrong though. So, ?

As far as uppercase, I just now tried taking a style and converting it entirely to lowercase. That fixed a ton of the display issues, but not all of them, its still unusable.

Paul wrote:

If you have PunBB running successfully as application/xhtml+xml then it is only because the browsers are not being as strict as they should. It really shouldn't work. The good new is that it is quite easy to fix everything.

When I said " forums function just fine" in my post I meant that they FUNCTION fine, they style/layout is not correct. Which you knew smile

So is this gonna be tackled then?

Paul wrote:

BTW: In my view Hickson is wrong.

I wont say sending XHTML as HTML is bad, but I think he has a point. All over the internet are people writing (what they think) is xhtml, and being happy that it works because some validator says it does. But when the day comes that it is actually sent AS xhtml, a strict parser is gonna spit errors at them, and they'll blame xhtml. That's what Hickson was getting at.

The point is, if we are gonna send it as html, then lets write it as html and declare it as html.

If we are gonna send it as xhtml, then lets write is as xhtml and declare it as xhtml.

Anything in between is not correct.

Are you a punbb developer? What happens here? What route is punbb going to take? Switch to html? Obiously using straight XHTML is out (thanks again IE). Or use content negotiation to have the pages be written in xhtml and delivered as xhtml to UAs that prefer it and HTML to UAs that prefer that?

With the above changes I've posted, I've got a great little content negotiation system going. Until I get the xhtml displaying right though, I've got the output forced to html right now.

At the very least, we should get punbb's display to work the same in xhtml as in html. If you don't want to add in content negotiation and keep sending xhtml as html, then that's your priority, but we should at least get it displaying right for those who set it up properly. Punbb has very nice CSS/XHTML output. To get this far, 95%, and say screw it its good enough would seem silly.


(2 replies, posted in PunBB 1.2 discussion)

I just wanted to write a thanks to all have contributed to this project.

I just set up a forum on my site (pixeljunkies.com, site hasnt launched yet though).

I wanted to say thank you because working with Punbb has been an absolute pleasure. You guys have done a phenomenal job.

The thing is so lightweight and fast. I appreciate its "keep it simple" design. Looking at the about page and at the features youve chosen not to implement section, the only thing there I'd like is the advanced formatting controls, and there are already mods for that!

The XHTML / CSS output is very, very good. (although see my post on it not working when sent with proper mime types).

And above all, its been a breeze to customize! Being able to use the simple template files (pun_include = genious) and CSS is great. And the PHP is written very well, and is easy to understand.

So thanks!

And I'm looking forward to future updates. Just saw in a thread that the next version will have search engine friendly urls. That is very cool, and will fit the rest of my site.

I have just added a bunch of new styles to my punbb forum, and the drop down in the profile section has the styles in a seemingly orderless way. Is there a way to make this dropdown show the styles sorted alphabetically?

I havent checked into updating the code myself, I was first going to check if there was already a way I wasn't aware of.



(29 replies, posted in PunBB 1.2 discussion)

Hey, I just came to the forums to post about this. People you can read up on why XHTML sent as text/html is bad here:


Basically, sending xhtml as text/html makes the browsers interpret it as tag soup anyway.

Reasons XHTML is better:
1. It's been the W3C recommendation since 1999, replacing HTML 4.01. Thats 6 years.
2. It's a simple transition to learn as the Web moves toward increasingly more XML.
3. It's far more flexible than HTML with being accessible to wireless devices, screen readers and other devices for the disabled (which helps by leaps and bounds with meeting accessibility guidelines and the U.S. 508 guidelines ).
4. XHTML is a cleaner, more logical markup.
5. XHTML is faster to parse (must faster), and thus display.
6. I like the idea of giving the browser what it prefers.
7. Its extensible in lots of fancy ways none of us need.

And you are right, sending pages as application/xhtml+xml to IE causes it to prompt to download, which is why it is best to use content negotiation.

Content Negotiation gives browsers what they prefer, old browser like IE get html and new browser get XHTML. It not only sends the header, but converts the content.

See here for a nice thing on content negotiation:
http://www.autisticcuckoo.net/archive.p … egotiation

Delivering documents in XHTML causes lazily written javascript to break (due to reliance on innerhtml and document.write, rather then DOM methods like CreateElementNS()) and can cause CSS to be displayed differently.

Anyway, punbb does not work in xhtml mode. The forums function just fine, but the styles are all broken. I dont have the time right now to check out why. I just registered here on the forums to point this out, in hopes it will get fixed. Punbb is claiming XHTML support, but it isn't really smile

Anyway, I don't have too much time right now (which is why I haven't looked through the CSS files myself to find out why they are breaking - something I will attempt later tonight), so I gotta wrap this post up.

Here are some easy steps to add content negotiation to Punbb.

1. In header.php:

After the "Send no-cache headers" add:

$xhtml = false;
    if (preg_match('/application\/xhtml\+xml(;q=(\d+\.\d+))?/i', $_SERVER['HTTP_ACCEPT'], $matches)) {
        $xhtmlQ = isset($matches[2]) ? $matches[2] : 1;
    if (preg_match('/text\/html(;q=(\d+\.\d+))?/i', $_SERVER['HTTP_ACCEPT'], $matches)) {
        $htmlQ = isset($matches[2]) ? $matches[2] : 1;
        $xhtml = ($xhtmlQ >= $htmlQ);
    } else {
        $xhtml = true;
//  Here we can sniff the UA's and override the negotiated value if we want. While sniffing the UA is generaly not a good idea, there are cases where it
// is necessary or actually is a good idea. For example, here I am sniffing the WCC validators, because they do not properly declare XHTML support.
if(stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")     ||
   stristr($_SERVER["HTTP_USER_AGENT"],"W3C_CSS_Validator") ||
   stristr($_SERVER["HTTP_USER_AGENT"],"WDG_Validator")) {
    $xhtml = true;

Find this line in header.php:

<link rel="stylesheet" type="text/css" href="style/<?php echo $pun_user['style'].'.css' ?>" />

and change it to:

<link xmlns="http://www.w3.org/1999/xhtml" rel="stylesheet" type="text/css" href="style/<?php echo $pun_user['style'].'.css' ?>" />

2. Create xhtml.php in the include folder in punbb:

/*  Here we give the browser the XHTML or HTML headers. We also give the correct document type declaration and document type declaration, and language tag  */
if ((isset($xhtml)) and ($xhtml)) {
    $headerstring = 'Content-Type: application/xhtml+xml; charset=' . $lang_common['lang_encoding'];
    echo '<?xml version="1.0" encoding="utf-8"?>', "\n";
    echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">', "\n";
    echo '<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"';
} else {
    $headerstring = 'Content-Type: text/html; charset=' . $lang_common['lang_encoding'];
    echo '<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/DTD/strict.dtd">', "\n";
    echo '<html lang="en"';

3. Edit template files (given stock templates). Take everything before pun_head, and remove it and replace with:

<pun_include "include/xhtml.php"> dir="<pun_content_direction>">

4. Edit footer.php. Write before the end, before "// Spit out the page" add:

// If page is being delivered as HTML, take the buffer and convert it to HTML
if ($xhtml != "true") {
    $xml = array('/>', 'xml:lang=', 'xmlns="http://www.w3.org/1999/xhtml"');
    $html = array('>', 'lang=', '');
    $tpl_main = str_replace($xml, $html, $tpl_main);

Upload these changed files, and now in XHTML capable browsers, the page will be delivered with the correct xhtml headers. On html page, the page will be converted to html (the conversion is all I need, your xhtml app might require additional conversion, although probably not unless you are using xhtml specific extensions like mathml). with the appropriate headers.

If your site is like mine, you will see that the styles of punbb are no longer properly applied.

I like to add a query string that lets me force either html or xhtml for testing.  In header.php AFTER the content stuff we added, add:

/*  I want to give a query string option to override this content negotiation. So, lets check for two force queries and set our output o match    */
if (isset($forcexhtml) and $forcexhtml == "true") {
    $xhtml = true;
if (isset($forcehtml) and forcehtml == "true") {
    $xhtml = false;

That will give you querry strings to force the output either way (if you have register globals off, you'll have to compensate).

So, anyway I gotta run, and I'll look into this more later, but this is the only thing I've ran into with punbb. Hopefully we can fix it so punbb has *real* xhtml support.