326

(17 replies, posted in PunBB 1.3 troubleshooting)

Matt: You're right, that's the likeliest reason. smile
kierownik: Do you ever access the RSS/Atom feed?

327

(56 replies, posted in PunBB 1.3 troubleshooting)

No cookie info is extracted. If the RSS reader uses the browser cookies, than the authenticated user's cookie is sent and their information is used. Otherwise, no cookie is sent and the user is treated as not logged in. Tell me if I misunderstood what you were trying to say.

328

(2 replies, posted in PunBB 1.3 troubleshooting)

Thanks for the report, but this was already fixed in SVN a couple months back. wink
http://dev.punbb.org/changeset/1502

329

(56 replies, posted in PunBB 1.3 troubleshooting)

MattF wrote:
Smartys wrote:

As opposed to cookie authentication for logins, which is what we use? wink
The idea is simply to use the login cookie as the authentication mechanism. That means nothing changes for regular RSS readers, but those which are integrated with a browser can view the RSS feed with the permission of the logged in user.

That cookie authentication part is a bit of a misnomer though. The cookie, in essence, doesn't mean diddley when the user isn't logged in. Plus, what's the point of a feed that you can only access once you're logged in? And if the auth mechanism contains some form of system whereby you don't have to be logged in to view it, then again, that comes back around to my original point. Security.

I'm quite willing to be corrected on my viewpoint if I've grabbed the totally wrong end of the cluestick, btw. big_smile

lol tongue
The idea is fairly simple. Instead of having the code force guest permissions, it just uses the permissions of the logged in user. No security issues there, since the authentication is done via the same cookie that PunBB uses. Now, only RSS readers that are integrated into the browser would be able to take advantage of this.

Query on m.posted, although it doesn't look like that would really help much here.
And the number of rows in the column is how many it looked at, I believe.

331

(20 replies, posted in PunBB 1.3 troubleshooting)

StevenBullen: Just a quick question, are you sure PunDemo is updated to the newest revision? It seems to be missing revisions that are almost a month old.

332

(20 replies, posted in PunBB 1.3 troubleshooting)

Jérémie wrote:

Why not set an appropriate meta description? Dynamically, based on what's on the page (thread view, forums, view, etc.)?

That would be the next step (or an extension) if this works. Page title / site description would be the fallback default.
The problem of course is that we have to make assumptions about what variables are available to us for use (and I have a feeling that the code for generating the descriptions would be long).

333

(56 replies, posted in PunBB 1.3 troubleshooting)

I just glanced through and it shouldn't be an issue: all the queries are done via the query builder and are properly hooked. However, you should be the one looking, since you're the only one who knows what hooks you need. wink

334

(20 replies, posted in PunBB 1.3 troubleshooting)

http://googlewebmastercentral.blogspot. … ption.html
http://www.google.com/support/webmaster … swer=35264

Well, we'll see tongue

335

(20 replies, posted in PunBB 1.3 troubleshooting)

Yeah, I would wait a week or so before making a final determination. The question is whether providing a keyword rich, relevant (as in the text is also on the page, so it's not keyword stuffing) meta description will make Google more likely to use it in place of trying to generate its own.

336

(20 replies, posted in PunBB 1.3 troubleshooting)

I don't think there's a way to prevent it from being indexed: the better question is whether there's a reliable way to get Google to use the meta description tag. I think the answer might be to add more content in it.
StevenBullen: Could you edit header.php (I guess ideally from your POV via an extension) to change the meta description to append the site's description to the end of the meta description tag?

337

(56 replies, posted in PunBB 1.3 troubleshooting)

SuperMAG: It will not be the only feature in 1.4. There is no roadmap at this point for what will be in 1.4, just a few ideas that we've pushed there. When it is released, it will be just as big a change as 1.3: hence bumping to 1.4 instead of 1.3.1.

338

(56 replies, posted in PunBB 1.3 troubleshooting)

As opposed to cookie authentication for logins, which is what we use? wink
The idea is simply to use the login cookie as the authentication mechanism. That means nothing changes for regular RSS readers, but those which are integrated with a browser can view the RSS feed with the permission of the logged in user. It's not a bad idea and it might be worth implementing, except for the fact that we want to do better. We want to provide users with a secure way to view their RSS feeds, one that does not require that the user disclose their username/password in the query string.

If you're using MySQL, yeah.

#1 could be an extension.

340

(55 replies, posted in PunBB 1.2 discussion)

Duplicate key: probably an issue like the one discussed earlier. The fix is here as well:
http://punbb.org/forums/viewtopic.php?p … 39#p104339
If you already applied that fix, try changing the code to this instead

                // Have no id
                if(empty($last) || $last == -1){
                        echo '<script type="text/javascript">window.location="index.php?page='.++$_GET['page'].'"</script>';
                        return;
                }

341

(56 replies, posted in PunBB 1.3 troubleshooting)

pedrotuga: It can be an extension. If we're going to implement a system, it will be a more robust one, one that can be used without needing browser / RSS reader integration. wink
MattF: I don't see what's so bad about the change, other than that the need to login is non-obvious.
SuperMAG: If you don't understand why major versions exist and why we don't have an endless development cycle for 1.3 (although it may seem that way it times wink ), which seems to be the case, please just accept what you have been told in this topic and stop asking about it.

Whoops, sorry Paul.

The "your subscriptions" link also doesn't work if search is disabled.

344

(55 replies, posted in PunBB 1.2 discussion)

The converter was written for 1.2. You should be using 1.2.

345

(56 replies, posted in PunBB 1.3 troubleshooting)

It's a feature we're currently putting off until 1.4.
http://dev.punbb.org/ticket/60
The reason, as the ticket states, is that we need a secure way to allow people to pass their information. Some feed readers support HTTP authentication via including the username and password in the URI, for example: we don't want people accidentally disclosing their username/password by copy/pasting a link.

http://www.postgresql.org/about/news.277

ALTER TABLE can alter the data type of an existing column

That's the release notes for 8.0.0. wink

347

(6 replies, posted in PunBB 1.2 troubleshooting)

kfordham281: http://www.ilovejackdaniels.com/cheat-s … eat-sheet/
It has example rules for redirecting from one domain to the other, it's the exact same idea (except with one domain being www.example.com and the other being example.com)

Uh, the page you linked me to is the documentation for 7.4, which does not have ALTER TABLE ... ALTER COLUMN ... TYPE.

As opposed to here, the documentation for 8.1:
http://www.postgresql.org/docs/8.1/stat … table.html

Alter column type only exists for PostgreSQL 8, I believe.
I do have a solution, you can see it in the patch in the ticket he linked to.

Hmm, it appears you're right. This is one of the perils of developing for a database system you're not familiar with. smile
So for IPv6 we shouldn't have an issue, other than that the column lengths will appear incorrect. However, we still need the ability to add columns to a database table: if such a solution allows us to come up with a setup similar to the way we handle PostgreSQL, all the better.

And yeah, we're still waiting on Trac/PunBB integration unfortunately. wink