I've noticed that in many cases I'm not forwarded to the last post. If I edit a post, or click the button next to the user name that's supposed to take me to the last post, it takes me to the beginning of the thread. This isn't the way it's supposed to work, is it?

[Edited on 4-9-2003 by Satyr]

Satyr

Yes, it does work that way.

William has explained it as a pagination issue - users can specify # of posts per page, and that affects the location of the last post somehow.

I suggested turning off that user flexibility in order to speed up the process of locating posts.

It's also an interesting phenomenon when doing undercover work, locating all of a unique user's posts... you are always directed to the start of the topic in which he or she has posted.

Yeah. It's tough to find posts in long threads. You're right. What's this user flexibility though? Something I'm not seeing in settings?

It is nothing whizbang, you can just reset the number of responses you see per page, and it is that flexibility that appears to make the link to the final post of a topic not feasible...

DOH!!! I thought I might've figured it out, but realized XMB is a bit different than vB.
You probably just have a $variable missing somewhere. Whatever adds the page number to the line in that particular template.

&page=$page ?

[Edited on 4-9-2003 by Satyr]

"XMB Support" ... he he he ... that's funny.

The author of most of what is XMB is a snot-nosed 17-year old elitist PHP programmer (uh... right) from Norway. His attitude is, if you don't like how it works, use something else.

The problem a forum like this has is the long legacy of content is valuable. Our nearly 200,000 posts attracts new members and makes us look like a content gold mine to Google. Converting that giant legacy to a better board is not impossible... but hard.

Then, add all our extras into the mix. While many of the extras aren't hard to replicate in another system... there are dozens of small bits of extra security and performance enhancements that would be lost. Not to mention that for all it's functional flaws, I still think XMB is the board that offers the most creative (design) flexibility.

As for the problems... you're looking at "post id" (pid) and trying to convert that to "post number" which is incorrect. There are many posts that have been deleted... the the pid field is a unique auto-increment field that doesn't reflect "the number of posts".

The problem with taking you to your last post is more complex that it looks. Page location is one problem (as mentioned) and XMB is the other. At the point in the code where you post or edit is completed, there have been no queries and calculations to predict where in the sequence of posts, your edit or your post appear... this would have to be redone... which isn't hard, but takes time (and CPU cycles to execute). And how many times, in a busy thread, do posts appear while you're making your post? Add another variable to the mix.

There's a short list of nagging problems I'm working on, but this is near the bottom of the list. A much more important problem is performance enhancements. XMB does not use any type of built-in efficient session handling features of PHP 4.x, so every page load includes a significant number of datbase queries to confirm you are who you are... in addition to loading your personal settings and forum settings. Normally, not a problem for a small board... but for us... huge. If you know anything about PHP session and application variable handling, we should talk!

I realize that post number and pid are two separate things entirely. I mentioned that above. Maybe I didn't word that correctly. That's what I was pointing out though...that they're not the same. I also took the liberty of checking a few other XMB v1.8 forums, and their last post buttons all seem to work correctly, so it has to be something missing either in your viewthread.php or the template. I'm not familiar with XMB, but I thought I might be able to help. If support is as limited as you say, it may be tough to figure out, but I think I'm on the right track. The only thing missing is the page number, which should be assigned by a variable either in the template or the php file itself. If it's like vB, it's in the template. Anyway, I'll be glad to help if I can. I'm sure you're correct about the edit and post queries, but as I said, I checked a few other XMB forums, and the last post buttons on the homepage do work correctly.
As for performance, what level of gzip comp are you using? Does XMB have a level control, or is that all done in Apache?
As far as PHP session and application variables, I know a little, but I'm still just a hack. vB's sessions are all cookie based. Kind of an annoyance when it comes to timeouts, IMO. I learn most when things go wrong. I'm impressed with all the hacks you have here. Do they have an XMB hacks forum too? I have a feeling it's very similar to vB, just with different template, php file names, and queries.

[Edited on 4-9-2003 by Satyr]

Yeah... there is a section for XMB hacks... but I've not used any public hacks, nor do I share ours... too much potential for hackability.

I'm also not using the final release of XMB 1.8 as the basis for this forum... so the exact code of the last post feature might not be complete.

But again, these are minor annoyances when compared to some of the performance problems I'm trying to address. The authors of XMB admit they never considered anything more than 200 posts a day for a discussion board.

It's not a bad board at all. They all have a few annoyances. I wish I knew php, so I could write my own hacks, or at least understand them better. Luckily, vB is very concerned with security, and there's always a crapload of people testing it.
Yeah, I did notice that there's an SP-1 update for v1.8, eh? I know what a pain updates can be if you have a lot of hacks, though. I usually use Araxis Merge when the dastardly deed must be done.
The reason I asked about gzip is because it's the single most helpful performance enhancement, but only on level one. Anything higher can hurt performance badly. Many people think, more compression, faster forum, but it just ain't so. But if you write your own hacks, you probably know this. I could probably learn more from you!

Compressing the output is really only 10% of the battle, at best.

With the number of posts, and number of people looking at posts we have, the underlying forum code becomes the major problem. There are 12 queries and 4 cookie checks on each page load just to establish if your a member or guest, and what forums are active, and which are not.

Very sloppy... but each time I make adjustments... other related problems crop up.

Whoa! That is kinda heavy on the queries. I haven't even checked how many queries my forum uses lately, but speed isn't a problem yet. It's pretty low traffic so far, and I try to keep hacks that add more queries to a minimum. Speed is most important to my members. Do your cookies have a timeout? Why does it have to check so much? I think vB only does it once per session, and session is adjustable. 15 mins. by default. The only problem I see with that is, the Mark Forum Read indicators time out if you don't read the entire board fast enough. They also reset themselves sometimes. It's sort of a sh*tty way to handle that feature, IMO, but at least it's light on the queries.
What would make the biggest difference is decreasing the size of avatars. The new background images probably aren't going to help either, unfortunately. I know people would probably scream bloody murder, but I've seen avatars alone kill performance on message boards. I limit mine to 65x65.

[Edited on 4-9-2003 by Satyr]

The reply redirect thing might work now... I think I found an easy way to do it.

I was entertained by skimming the last few instalments even after my programming knowledge fell well below the prerequisites for engaging in disciplined critique.

Cool! I posted the last post thing at the XMB forum. One of their dudes is looking into it for us. Maybe he can tell ya what to check and make it easy.

So now when I post to a thread with multiple pages, I am not brought back to anything but a grey screen. Would that be because I prefer to view 50 posts per page as opposed to the default 25???

Here's what XMB Supporter of the Month had to say.

You could try upgrading to 1.8 SP1 - it's possible that would fix this with the new version's files - If you do upgrade you will have to add your hacks back into the files.

I also notice that even tho you are running 1.8 - you have no Super Administrators - just Administrators.

Did you upgrade from 1.6?
The upgrade should have changed all Administrators to Super Administators. And, at that time, did you replace all your files with the 1.8 files?

I'm guessing, but if you didn't replace viewthread.php when you upgraded (if you upgraded) that's probably the problem. Actually, I found a v1.6 board and it has the same problem, so yeah...although you upgraded, you may be operating with v1.6 files? It does seem to be a characteristic of v1.6.

I would guess that 40% of our code (or less) is actual original XMB code.

I've seen how they handle thread/page/post count in a more current version and it's awkward. My solution seems to be working... but there might be a couple bugs.

As for staff rights... my code assigns staff rights based on username and password combinations... not simply status assignments in the database... to easy to spoof.

Hmmm, I'm not sure how XMB handles that, but I know vB's passwords are all encrypted. I can't even read them, although I think there is a hack that can reveal them. I've never found a reason to need to know anyone's passwords. I do know there's probably(I won't say there is no one, since I'm sure there is some extremely good hacker somewhere that can) no one who could get my password, even if they hacked my server and accessed my database, which is also password protected.
It does get tricky to update files when you have alot of hacks. I've been there many times now.
The redirection after posting does appear to work fine. Nice work.