Let #… link to the matching reply.

[Zegnat]

Much like how @username links to the latest reply by the mentioned user, see if #n can become a link to reply number n.

Case in point, the #1 in this reply should become a link to the first reply.

I’ll take a look at this in the new year.

[Kroc]

Ooo nice.

[Zegnat]

A problem here is replies do not actually have a canonical ID. If a reply is completely removed somewhere in the thread all others IDs will shift.

Can we use the reply number from ./item/title? It can easily be extracted using something like substr ($title, 3, strpos ($title, ']') - 3). thread.php will have to be modified to match this. This turns it into slightly more work, but wouldn’t need any substantial work.

When I was researching this I saw the following bit of code in thread.php:

    foreach ($thread as &$node) $sort[] = strtotime ($node->pubDate);
    array_multisort ($sort, SORT_ASC, $thread);

This suggests that the item order in the RSS file is not to be trusted? Does this mean the reply number in the title cannot be seen as in the right order either?

[Kroc]

Replies can only be completely removed on the last page of a thread, so there's less likely hood of breakage.

I hadn't thought of using the reply title, but it can't be 100% relied upon as the user could change the title format and you'd have some replies in one format and other replies in another format.

The reply order is descending by date written -- since appending does not update the original post date, it can be relied upon to be in order.

[Zegnat]

Replies can only be completely removed on the last page of a thread, so there’s less likely hood of breakage.

Even by mods? I had never actually needed to test this. But that does help, a bit.

I hadn’t thought of using the reply title, but it can’t be 100% relied upon as the user could change the title format and you’d have some replies in one format and other replies in another format.

I have refactored my code to use sscanf ($reply->title, THEME_RE) so any format should use unless they chose to completely remove the number. Not likely (?).

A change in THEME_RE mid-way would break things, that is true. But a change in FORUM_POSTS would too. I know these two things are vastly different, especially since THEME_RE is part of the language file, bit it is an example of a setting that will break things when changed. Maybe #96 can fix this…

Here is the code I currently have inside the formatText-function:

    /* reply references:
       -------------------------------------------------------------------------------------------------------------- */
    //based on the name reference code.
    if (!is_null ($rss)) {
        //make a list of reply numbers and matching links:
        $ids = array ();
        // xpath ./item[not(last())] and ./item[position() < last()] didn't seem to work.
        $replies = $rss->channel->xpath ('./item'); array_pop ($replies);
        foreach ($replies as $reply) $ids[current (sscanf ($reply->title, THEME_RE))] = $reply->link;

        //find all possible reply references in the text:
        //(that is, any "#" followed by numbers. note that this means that what might be matched may
        //be a number that does not have a matching reply.)
        $offset = 0; while (preg_match ('/(?:^|\s+)(#\d+)/m', $text, $m, PREG_OFFSET_CAPTURE, $offset)) {
            $n = substr ($m[1][0], 1);
            if (isset ($ids[$n])) {
                $text = substr_replace ($text,
                    //TODO: `safeHTML` isn't quote safe
                    '<a href="'.safeHTML ($ids[$n]).'">'
                        .'#'.$n.
                    '</a>',
                    $m[1][1], strlen ($m[1][0])
                );
                $offset = $m[1][1] + strlen ($m[1][0]) + strlen ($ids[$n]) + 15;
            } else {
                $offset = $m[1][1] + 1;
            }
        }
    }

The $offset mumbo-jumbo is all yours, I have no idea if it is really necessary. 😉

The reply order is descending by date written -- since appending does not update the original post date, it can be relied upon to be in order.

So the array_multisort I quoted from thread.php is unnecessary?

[Kroc]

Will review this proper when we have #96 "Republish" admin script.

I have no idea if the sort is necessary; I haven't looked at the code for a year! It would have been there since v1, so it must be there for a reason.