XF 2.2 We can't extend the new ThreadViewData through XFCP?

[cmpe]

Ultimately I am trying to pin a post to a thread that is not the first post so I thought I could just extend ThreadViewData with a class extension but it doesn't seem to be working through XFCP.

Is that by design?

 

[Mike]

That class is essentially just a data container, so extension is not really expected.

If you want to pin an additional post, you should probably be doing it through the highlighted posts system, which can be controlled via thread types. (If you really do need to extend the object, then you can also do that by overriding the method in the thread type system.)

 

[cmpe]

That class is essentially just a data container, so extension is not really expected.

If you want to pin an additional post, you should probably be doing it through the highlighted posts system, which can be controlled via thread types. (If you really do need to extend the object, then you can also do that by overriding the method in the thread type system.)

Thanks Mike, I try to "chase" the XF2 codebase to try to figure out how it's implemented in the core and try to mimic the core usage in my addon. Your comment helped me narrow down how to implement what I needed to do with highlightedPosts.

However, now I'm kind of confused about how applyPostListFilters function is supposed to work. Because I want to remove the hightlighted post from the main post list. Shouldn't the $postList be passed by reference here so I can manipulate it?

I'm certain I'm not understanding this fully so tips appreciated, thanks again!

 

[cmpe]

Oh wait, nevermind. $postList is \XF\Finder\Post.... mistakenly assumed it was an array(collection).

 

[Mike]

Because I want to remove the hightlighted post from the main post list.

I'd generally advise against doing this, though you may have very specific reasons to. The reasons to not do it are pretty significant. I know because this is how question solutions were going to work and we kept running into unexpected problems, eventually scrapping the approach entirely. For example, it can cause pagination issues (giving a page that is potentially blank) andcan significantly break the automatic "go to unread" system (or at least cause some very unexpected behaviors). There are probably other issues that I've forgotten about just now. Moving to the approach where the highlighted post is a reference to the original post in position essentially solves all of these issues.

 

[cmpe]

I'd generally advise against doing this, though you may have very specific reasons to. The reasons to not do it are pretty significant. I know because this is how question solutions were going to work and we kept running into unexpected problems, eventually scrapping the approach entirely. For example, it can cause pagination issues (giving a page that is potentially blank) andcan significantly break the automatic "go to unread" system (or at least cause some very unexpected behaviors). There are probably other issues that I've forgotten about just now. Moving to the approach where the highlighted post is a reference to the original post in position essentially solves all of these issues.

Hmm, thank you for the tip, that's interesting. Definitely ran into giving a page that is potentially blank issue and ended up using applyPostListFilters() to filter out the hightlisted post with $postList finder. Is that not what the post list filter is designed for? I am now curious what application applyPostListFilters() is designed to provide.

 

[Mike]

That method is really designed for an explicit filter system, like what you see on forum view, so it's used in conjunction with getPostListFilterInput. The code takes different paths depending on whether filters are present. As an example:

if ($effectiveOrder == 'post_date' && !$filters)
{
   // can only do this if sorting by position
   $postList->onPage($page, $perPage);
}
else
{
   $postList->limitByPage($page, $perPage);
}

$totalPosts = $filters ? $postList->total() : ($thread->reply_count + 1);

You might now think "ok, I'll just return a filter from getPostListFilterInput in all cases and that'll work". And you'd be somewhat right, but there are other cases that may still fall over. Notably, things like the page-specific links on thread list items (forum view); you'll have at least one situation where they will say there's a page X but with the automatic filter, there's only X-1. That would probably get sorted by an automatic redirect, so that might not be a huge deal. However, all of the code that jumps to a specific relies on determining the page based on the post's position, and that won't necessarily be correct for anything after the pulled-out post. You could potentially override XF\ControllerPlugin\Thread::getPostLink for your case, though this doesn't necessarily override some of the more UI-based issues with how it affects "go to unread"...

Of course, the other caveat of always applying a filter is that it ends up violating other assumptions, like how we can trigger read marking, since that's based on saving the date of the last read post. And if there's a filter, we can't know if there are posts that aren't being shown, so we simply can't trigger the read marking system.