[l008com]

Kinda stupid to wait until someone writes a whole reply to a thread, then posts it, then show them this message. Hows about notifying them BEFORE they start typing, that their typing will be futile. Since old threads are essentially locked anyway, why not just truly lock old threads. Which is kind of a dumb idea anyway. I should be able to revive my own threads. But thats a separate issue.

[subego]

Consider this your notification.

Yeah, I got dinged by that too.

[ghporter]

There's a difference between "locked" and "too old to bump," at least as far as the forum software goes. As a general rule, if a thread hadn't been posted to in a year, expect that it's effectively locked. We have it set up this way because almost every thread is time context dependent-bumping a year old thread about iPhones with a comment current today, for example, could make it very confusing.

If you contact a mod (preferably a mod for the forum you're wanting to revive your thread in), they can get it re-opened. You'll also probably get a brief lecture on making it clear that you're posting to a very old thread to avoid confusing other users.

[subego]

If that happens, might not be a bad idea for the mod in question to add something like [Zombie] to the thread title.

[ghporter]

Almost all threads age-out, and locking is a thread-by-thread process. It's certainly way too much work to actively lock so many threads. On the other hand, when someone asks a mod to reopen a thread, the user almost always (without our "brief lecture") make note that they're coming back to an old subject, so marking reopened threads isn't needed.

The only time it's really worthwhile to mark a thread this way is the very rare instance when someone posts on the very last day a thread isn't automatically closed to new posts, thus reviving a zombie. But when this happens, members notice it pretty quickly because it's a new member posting...so again there's no reason to mark it.

Remember, our staff is all volunteers with plenty of other things to do beyond touching up labels and such. Adding to the workload isn't a very good idea.

[l008com]

Ok I think you guys are missing the point though. The issue is that there should be notification that you can't reply to a thread BEFORE you spend who knows how long crafting a reply to that thread (second, minutes, an hour). The way it's set up now is pretty stupid. The "post reply" button simply shouldn't be enabled, if you can't post a reply. If the forum doesn't support a reasonable way to handle too-old threads, maybe there's a mod for it that will help. Nothing annoys forum users more than making them write a reply, then losing it. Either through "we forgot to tell you, this thread is too old!", or through being logged out when you post, so when you log back in, your reply is gone. This isn't really a problem on this forum, I'm just using as an example that, making your users write something and then not remembering it, is very infuriating.

[Oisín]

I agree. I don’t know if it’s possible to hack in an extra announcement on the thread page itself for the Quick Reply box, but I would think it should be possible at least to have one for the actual posting page. If the forum can figure out that a thread is too old to bump and serve up an error message based on that, it should also be able to figure out that the thread is too old to bump before you enter the posting page, and give a preemptive warning based on it.

Should. As in, in theory. You never know with vB.

[andi*pandi]

Are you able to harvest your post to make a new one? Or does the error load a new page and wipe out your post?

[l008com]

Wipes it out.

[seanc]

I've often found with Firefox, if something happens to move the page on, you can go back and the text fields you've filled out will still be populated, so you can retrieve the data.

[l008com]

That doesn't usually work with forums. Since the browser recognizes it as dymanic contents, back, usually reloads from the server, not from cache. I lose so many forum posts on PHPBB forums this way, because i log in, write a long entry, and when I hit submit, I'm logged out and my post is gone. Modern web browsers should have a system of remembering content you enter into text fields, so worst case, you can go back into the browser's records and get it back. BUT at the same time, a forum should never discard a huge post you send it. Even if you submit and your session expired while you were writing, the submission page should see the huge blob of text you are trying to submit, and should echo that text back to you on the error page, so even though you're not logged out, you haven't lost all of your data.

[besson3c]

For a quick and easy fix, why not just make the default text in the Quick Reply textarea to read "this thread is too old to bump"... i.e.

<textarea>this thread is too old to bump</textarea>

[Oisín]

Originally Posted by l008com 

That doesn't usually work with forums. Since the browser recognizes it as dymanic contents, back, usually reloads from the server, not from cache. I lose so many forum posts on PHPBB forums this way, because i log in, write a long entry, and when I hit submit, I'm logged out and my post is gone. Modern web browsers should have a system of remembering content you enter into text fields, so worst case, you can go back into the browser's records and get it back. BUT at the same time, a forum should never discard a huge post you send it. Even if you submit and your session expired while you were writing, the submission page should see the huge blob of text you are trying to submit, and should echo that text back to you on the error page, so even though you're not logged out, you haven't lost all of your data.

Try Opera—it seems to be far better at ‘force-cache-reloading’, rather than reloading from the server, even with dynamic content.

[l008com]

Yes but opera sucks as... everything else BUT that.

[besson3c]

Originally Posted by Oisín 

Try Opera—it seems to be far better at ‘force-cache-reloading’, rather than reloading from the server, even with dynamic content.

AFAIK all browsers should respect the HTTP headers which dictate how caching should work, e.g.:

Code:
?php
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
?>

[subego]

Originally Posted by ghporter 

so marking reopened threads isn't needed.

A user catching the note is dependent on them reading one specific post in an arbitrarily long thread, from someone who could be on your IL. A title change makes it clear before you even read the thread.

[Oisín]

Originally Posted by besson3c 

AFAIK all browsers should respect the HTTP headers which dictate how caching should work, e.g.:

Code:
?php
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
?>

Yes, but that’s only relevant for page reloads, right? The difference between Opera and pretty much everything else is that Opera doesn’t reload the page at all when you go back with the history button, it shows you the cached page as it was before you left it. That’s why I always used it back when I was on a 128 KBit connection: for sites like forums, where you always come back to one page and click new links from that page, it meant about 80 per cent less loading time than all other browsers.

Of course, when you reload the page (automatically in most browsers, manually in Opera), it respects the cache settings.

Originally Posted by subego 

A user catching the note is dependent on them reading one specific post in an arbitrarily long thread, from someone who could be on your IL. A title change makes it clear before you even read the thread.

Not a post inside the thread: a big marker in red just above the text entry box.

[subego]

Originally Posted by Oisín 

Not a post inside the thread: a big marker in red just above the text entry box.

I think we're talking about different things. My post referred to "closed" threads which had been reopened by a moderator.

[Oisín]

Ah, sorry, you’re right—I misread (or, well, ‘miscontexted’) you.

As it doesn’t happen all that often, I don’t think it would be a problem for the mod who bumps the thread to also add something like “[Bumped thread]” or “[Zombie]” to the thread title. Well, I can only speak for myself, of course, but I’ve only been asked to bump a zombie thread once or twice over the past six (?) months since I was abdu--recruited.

[ghporter]

Originally Posted by l008com 

Ok I think you guys are missing the point though. The issue is that there should be notification that you can't reply to a thread BEFORE you spend who knows how long crafting a reply to that thread (second, minutes, an hour).

I would tend to agree that it's currently not terribly friendly the way it is. But there are three different ways one can post to a thread-through the "Quick Reply" box, through using the "Post Reply" button (at the top of the thread's page-I never use that one), and through the"Quote" and "Quick Reply" buttons in a post. This is a big deal because we'd have to hack the forum software to make it obvious in ALL situations that the thread is not going to accept posts. In other words, doing "something" about this issue is quite non-trivial.

On the other hand, watching the date of the last post (before your about-to-be-epic post, of course) and noting whether it's at or past a year ago will save you all that effort in crafting the worlds most awesome post. This is already in place, and only requires the user to read the date of the last post before composing a new one... Not terribly "amazingly helpful," I concede, but it works.

[seanc]

I don't know if we can make vBul lock threads older than a certain date and append a tag to the front of the title.

Something like:
My cat is a genius
to
Retired: My cat is a genius

[l008com]

Clearly vBul needs to implement a full on "time-locked" thread status. Blocking at the last second is about the least user friendly thing they could do. The way it's set up now, it's basically invisible locked threads.

Or maybe you could exclude old threads from search results. But then the forums of the world would have to stop yelling at the forum users of the world to "search before you ask" so that will never happen.

[seanc]

I believe our current method of disallowing bumps is a vB mod.

This makes you tick a checkbox before you can post to an old thread, but doesn't stop you:
Prevent bumping old Threads - vBulletin.org Forum

This second mod will auto-lock threads of a certain age, but it seems to be depreciated now:
Expired Threads (Auto Close Threads) - vBulletin.org Forum


If you're feeling adventurous, you can write your own mod, l008com.

[l008com]

I've given up on managing a forum. It's just not worth the effort.

[reader50]

Zombie threads were most often bumped by bots, so I built the current hack to make life harder for them. It also helped with google visitors who would bump a years-old thread, urgently asking for iTunes codes from the Pepsi promotion. So today they hit the Report button instead, because it still works. The staff has been asked for Pepsi codes at least 4-5 times that I know of, probably more.

vB has an auto-lock feature for old threads, but it just locks them. No change to title, so you can't tell if an old thread was locked because of it's age, or because of mod action. ie - if it was OK to unlock on a member request. Worse, if it did change the title, it would also change the URL. So if you have a thread bookmarked, the URL could go bad after awhile.

Also, I wanted to have different bump windows for different forums, so using vB's blanket lock rule was out. The current approach was a simple one, performing a group-, date-, and forum- check, then throwing a permissions error with a customized message.

A visible warning would be an obvious improvement. I'd have to do a matching hack in at least two more templates, and hope vB provides the needed variables there. I like besson's default text idea.

No promises, but I'll probably tackle it at some point. It won't be a huge project if the last-bumped and forum# variables are available in both templates, but it is likely to be tedious. vB has an odd habit of making unexpected things happen when you try to do something clever.

[l008com]

Originally Posted by reader50 

Worse, changing the title also changes the thread URL. So if you have a thread bookmarked, the URL could go bad after awhile.

Isn't the text of the URLs just mod-rewrite search engine spam anyway? As long as the number is right, the text after it can be anything, it doesn't really matter.

Originally Posted by reader50 

vB has an auto-lock feature for old threads, but it just locks them. No change to title, so you can't tell if an old thread was locked because of it's age, or because of mod action. ie - if it was OK to unlock on a member request.

Well it seems like, given the choice between making it harder for the mods or harder for the users, you picked the wrong one.

[reader50]

I picked the first implementation that I thought of, and yours is the first complaint. The hack has been in play for several years, so it wasn't a bad choice. Low error rate.

I'll fiddle with it presently. And I've long composed long messages in a text editor, ever since UBB (and early vB) had that habit of crashing/timing out. Lost a lot of posts that way.

[ghporter]

For those who aren't familiar with the guts of vBulletin, it is a combination of HTML, CSS, PHP, and probably three or four other things. There are templates, style sheets, and various routines to do all sorts of things, with much of the work done in multiple places that (hopefully) work together smoothly. It always gives me the impression that deep down, someone from Redmond, Washington had something to do with the overall master plan...

In other words, while reader50 has managed to get things to do very cool and wonderful functions, modifying vBull is always a challenge, and always "interesting." I'm looking forward to seeing what he comes up with; I hadn't had the chance to suggest a red banner at the top of any form of reply text box (thinking in terms of a really simple HTML implementation here...), but I guess I've managed to slip that in anywho...

[turtle777]

Originally Posted by seanc 

My retired cat is a genius

Fixed that for ya'

-t

[besson3c]

Originally Posted by Oisín 

Yes, but that’s only relevant for page reloads, right? The difference between Opera and pretty much everything else is that Opera doesn’t reload the page at all when you go back with the history button, it shows you the cached page as it was before you left it. That’s why I always used it back when I was on a 128 KBit connection: for sites like forums, where you always come back to one page and click new links from that page, it meant about 80 per cent less loading time than all other browsers.

Of course, when you reload the page (automatically in most browsers, manually in Opera), it respects the cache settings.

I don't think this is different than any other browser. What do other browsers other than Opera cache then? How does their cache work? If both a reload and forward/back button causes an entire page reload, what reads from the cache?

I *think* that no matter what you do, some sort of comparison is made between the data in the cache and the data served by the site. The stuff that mismatches is reloaded, the stuff that matches is loaded from cache.

It could be that Opera somehow caches complete page renders so that the page doesn't re-render?


The management of this forum has gotten much, much better over the years... I remember things breaking fairly frequently!

[Oisín]

It could be that Opera somehow caches complete page renders so that the page doesn't re-render?

Yes, I think that’s it exactly. Other browsers cache elements on the page, but reload the content; Opera caches everything.

[besson3c]

Originally Posted by Oisín 

Yes, I think that’s it exactly. Other browsers cache elements on the page, but reload the content; Opera caches everything.

Probably into memory, i.e. it is just showing and hiding stuff.

[Big Mac]

I've never been hit by this problem. I really don't go looking to bump old threads.

As for losing your post content, what I have done is conditioned myself to occasionally selecting all and copying my posts that are long, so if they get eaten by forum software I can just paste and try again. Or, for really long posts I copy and paste them into a word processor file before posting.

I did have a pleasant experience posting here from my iPhone recently. I had logged in without pressing the keep logged in check box, so when I posted something I found out I wasn't logged in. And of course I hadn't saved that post. I thought the text was gone To my delight, however, when I logged back in I found that my post had been saved and got posted after all.