Search options (Page 2 of 5)

The script only makes changes if the array info differs from the markup that the php has generated. So yes, it only bothers to mark unread posts as unread after they've timed out ... since they are already properly marked as unread before the timeout.

Here are the possible states and what the script does about them...

Yes. Though it is possible to extend the persistent cookie expiration time but I've recommended in the install that it be set to mirror the forum's "Visit Timeout" (default: 600 seconds). And I'd be reluctant to suggest turning the expiration time up too much right now as the script treats a larger-than-4k cookie like a buffer over-flow and clears it. But as things stand (with the short time out), the cookie can track at least 250 posts (but probably more like 350+). To exceed the 4k limit, you'd need a forum with several hundred new posts at a time, so this isn't much of a problem with the short timeout and the current pruning.

(I do intend to add large-cookie-friendly pruning in a future version though--to support a more-or-less permanent persistent cookie. But this won't be the default setup.)

No, that's not normal... but I know it can happen if you remove an unread post via the moderate forum link (moderate.php). Doing this leaves an unread mark in the array which turns the indicator on when you view index.php.

If that's not what happened, email me and I'll take a look at it.

That's a good idea. When I was making the script I was concerned about execution time but it doesn't seem to be an issue. I'll use the packer you listed and another one then put the smallest result in the distribution (along with an uncompressed copy).

Updated version...

The new version is available at the same location as before (new_posts.js).

Here are some of the new changes:

- Last-post tracking has been added for posts that haven't timed out. All new posts are now accurately tracked and marked as such.

- A persistent cookie is used to prevent marked-as-read posts from coming back between short multiple visits.

-  To keep things visually consistent, the script generates a [Last post] link using action=last. I wanted to add a genuine [New posts] link for unread-but-timed-out messages but doing this reliably with the given markup just isn't possible.

- The script now also suppresses the update flicker that was sometimes apparent (especially in IE). The style sheet method used to do this should work in all common browsers except Opera. If you have Opera, you may still see a slight flicker as the script re-writes the new post indicators.

Question: One of the last things I need to add is detection for the punbb_cookie. The script needs to determine if the browser is logged in as a user or as a guest. Can anyone tell me what I should be looking for to determine this? I've looked at the unescaped cookie data but I can't readily see what I need to be testing for.

This detection is necessary to prevent odd behavior for users that have turned off the "Save username and password between visits" option.

After this user/guest detection is implemented, I believe the script is pretty much done. If I don't hear of any errors or strangeness, I'll package it up as a proper mod in a week or so.

Question for Rickard:

I'm getting ready to add a [ New posts ] link for timed-out messages but I have a question: the normal [ New posts ] link uses the href: viewtopic.php?id=TOPICID&action=new.

Now when I append &action=new to an old post (e.g. 1.0 Preview) I'm taken to the last message in that topic.

So I see that this works... but can I use this as a reliable way to reach a topic's last post? Or should I use a different method (like building a proper pid=POSTNUM#pPOSTNUM link) instead?

Next Revision Will Include...
- [ New posts ] link for unread-but-timed-out messages
- last-post tracking for messages that aren't timed-out

Yes, it's more of a patch over the current method as opposed to cleaner rewrite...

I was thinking that...
   $by_post_url = 'viewtopic.php?pid=$1#p$1';
      ...could be declared in a single file (like config.php or something).

And the...
   $the_link = variable_rewrite($by_post_url, $pid);
      ...line would be hard coded into each file.

To change the URLs, you'd just alter that one $by_post_url= declaration. I favor the viewtopic.php?pid=$1#p$1 format--with it's dollar-sign symbols--so that it's similar to Apache's rewrite format ... but this is just a matter of taste.

I think we're thinking the same thing basically ... I'm just not familiar enough with PunBBs internal structure to suggest a format consistent with the coding style you've already used.

The PHP code I'm using for the variable_rewrite() is...

function variable_rewrite($string, $one, $two='', $three='', $four='', $five='') {
    if ($string && $one) {
        $string = str_replace('$1', $one, $string);
        if ($two) {
            $string = str_replace('$2', $two, $string);
            if($three){
                $string = str_replace('$3', $three, $string);
                if($four){
                    $string = str_replace('$4', $four, $string);
                    if ($five) {
                        $string = str_replace('$5', $five, $string);
                    }
                }
            }
        }
    } else if (!$string)
        return null;
    return $string;
}

This is certainly possible. Right now it assigns inormal to the DIVs as the messages are read... but a 3rd class could be assigned just-as-easily. Maybe something like ioff. If this is done, the array pruning will need to be modified to make the display operate intuitively... not really a problem though.

I could add an option for this after I'm sure the script works well in its current state. If it is added, the use of a 3rd class will not be the default behavior--I'd like the script to lay seamlessly over an out-of-the-box install of PunBB.

Here's a screenshot...

[Edit: image removed, see the new screenshot instead]

They're very similar but child selectors are more specific. If we're working with the following markup...

<p>This is a <em>test</em>.</p>
<p>This is <i>a <em>test</em></i>.</p>

...a descendant selector like p em { color:red } would make both instances of the word "test" appear red.

But if we use a child selector like p > em { color:red }, only the first "test" would be red. This is because the first <em> is a direct child of the <p> and the second <em> is a descendant but not a direct child (it's the <p>'s child's child).