You need to set those values and remove the cache_config.php file from the cache directory.

252

(8 replies, posted in PunBB 1.2 troubleshooting)

No, upgrade ASAP.

253

(18 replies, posted in PunBB 1.2 discussion)

I think I can generally predict the answers:
Anyone using vanilla PunBB: likely to upgrade the fastest, since the upgrade process should be painless and they'll gain lots of new features
Anyone who has installed modifications, a style from PunRes, etc: they will use 1.2 until enough of their existing features are available
Anyone with special, custom anything (integration, modifications, style, etc): they'll use 1.2 for as long as humanly possible, since upgrading that stuff involves recoding that they have to pay for or do (I know that feeling, I did a Wordpress 2.3->2.5 upgrade the other day where I had a lot of custom integration code that had to be redone).

So, with PunBB-Hosting, I fall somewhere between the second and third categories. I have a lot of custom code for doing the multi-forum stuff which I'll have to rewrite, and I also support quite a few modifications/styles which need to be converted for 1.3. Upgrading the site won't be so bad; I managed to put in UTF-8 support a while back, which made supporting the many languages very simple, so all I need to do is manually apply some schema changes across all forums, which I already have a tool for. The issue will be doing it with minimal downtime. tongue

254

(5 replies, posted in Programming)

Ooh, what an interesting usage smile
Yup, sending out emails to everyone on every post is a modification. Probably in post.php. Putting an if statement around the code that sends them out to exclude a certain forum ID is probably easiest.

255

(3 replies, posted in Programming)

http://www.seoconsultants.com/meta-tags … -after.asp

The revisit-after META tag is not supported by any major search engines, it never was supported and probably never will be. It was developed for, and supported by, Vancouver Webpages and their local search engine searchBC.

256

(5 replies, posted in Programming)

The good news is that all you have to change is one line in your css: .linetop to .linetop td (and remove the width line, and maybe add the border-collapse line if necessary).

257

(5 replies, posted in Programming)

http://www.csarven.ca/tr-border-trick-for-ie
I assume the same issue (IE doesn't put borders on <tr>) applies to IE7 as well, since I have the same issue when viewing your page.

258

(1 replies, posted in PunBB 1.3 troubleshooting)

Yup, needs to be fixed (I'm going to hold off doing so so I don't interfere with Paul's markup commit).

259

(6 replies, posted in Programming)

lol, no problem: it's the least obvious problem you could have tongue

260

(14 replies, posted in Programming)

Well, there's a couple different ways to sort: you specify which one to use.

261

(14 replies, posted in Programming)

You actually can:
http://www.php.net/array_multisort
Check out the third example, sorting database results.

262

(6 replies, posted in Programming)

So all you did was change $result to something else in several of the queries? And before that, the $db->num_rows check for the downloads worked but no rows came out?
You wouldn't happen to have a query called via a pun_include (or via header.php in general) that uses $result, would you?

http://www.punres.org/files.php?pid=329
Apply the modification properly? tongue

264

(6 replies, posted in Programming)

So, what exactly is supposed to be wrong with the code? tongue

265

(8 replies, posted in PunBB 1.3 troubleshooting)

Hmm, fair enough: changed.

266

(8 replies, posted in PunBB 1.3 troubleshooting)

Rules are still allowed to be seen by Guests under those circumstances though. The question is whether we should rethink that.

Because $num_users is never initialized anywhere but you use it in your code as if it is.

You could modify it to do so (to not check against the remote database if the username/password in the local database matches), but I'm not going to support it: it's likely to lead to confusion and breaks down the idea of having one shared account. You get a small performance benefit (you don't have to query against the remote database every time) but at a high security cost (once the first login to PunBB happens, the account is essentially not "linked" externally anymore).

How? Anyone with time and/or search privileges can determine last post time without it being the profile, and all IP address data (including that in posts) is only shown to moderators/administrators and isn't really that much of a privacy concern in any case. I don't really see what you're protecting by removing those things. tongue

New version uploaded, the default email address if you don't supply one is now "invalid@invalid.invalid" as opposed to just an empty string.

Ah: I'll fix that then smile

You're talking about just not storing registration_ip and last_post in the users table, right? Just edit register.php/post.php and you should be fine.

Out of curiosity, why?

You shouldn't NEED it, although it's probably a good idea since PunBB expects that all users have some sort of email address. Did you run into an issue that you're saying you need it (because if so, I know how to fix it).

274

(13 replies, posted in General discussion)

http://forums.bauchan.org/testforum/mod … /index.php
I think you might be better off modifying pdfgen just to take an ID.

275

(20 replies, posted in PunBB 1.2 troubleshooting)

artoodetoo wrote:
Smartys wrote:

...but I doubt anyone is going to devote the time and effort at this point to completely rewriting 1.2's search to use a new system.

Not all punbb webmasters is in ecstasy over 1.3 and it's fulltext search. As for me, fulltext has critical disadvantages.
I'm working on some 1.2 search improvements.

artoodetoo: For example?
And if you like 1.2's search so much, you could probably reimplement it as an extension. I wouldn't spend my time writing a "better" search for 1.2 though, unless you think you'll be using it for a while.