Wedge

Well, yes I suppose we could introduce mini-skeletons for repetitive items like posts and userboxes but good bye performance. Or we'd have to write a mini rendering system for them as well.

It would be doable I suppose if we did it only for posts. Then in this mini skeleton we add the userbox blocks. At rendering time we provide the contents for each block and they're shown depending on the context. Eg we hide the user box if in the profile area.

And I'd rather not screw performance up...

No, I don't think the skeleton approach is the right one for this. The problem isn't that building the array of the skeleton is intensive, because it isn't - it's at worst a different array and function call per post, but I don't feel it's the way to go.

What is closest to how we do things is to build the list of items in $context, which will be a list of items in memberContext for each user (provided it's populated by lMD and lMC, it's in memberContext) then the template can just iterate through it.

It's still ugly but it's not the performance killer it could be.

But it's harder to customize this way.

Depends what you're trying to do, really, I was more interested in allowing plugins to cleanly extend or alter the list of items, rather than customising it, but appropriate CSS would make a lot of difference.

Apart from that, I'm really, really interested in having a common layout for all places in Wedge where we show posts (including PMs)... I thought we could have the best of both worlds... :P

Here's the thing. There isn't a common layout at present, and I'm not sure that's necessarily a bad thing.

Right now the post and PM layout is similar, but not identical (even in terms of the icons shown etc., e.g. the send PM icon and IP address aren't shown), but all the other places where posts are shown (notably search, recent, unread, unreadreplies) do not have much common ground at all...

But those you mention are similar between them ;)

Post and PM are similar, search is pretty unique, recent/unread/unreplies are all similar but they're not similar to search or posts/PMs, and I don't think they should be.

I'm not sure that putting in the user info would make a lot of positive difference in the search or any of the other areas (other than PM)

I just think the post layouts across the various forum features might benefit being streamlined. And your original idea would have been the opportunity to do it.

OK, new idea.

Inside prepareDisplayContext, the poster's details are pulled from memberContext. What if, instead of that, we did something smarter?

We already have a list of the people who have posted in a topic. Why not build - in memberContext or somewhere else - an array of the stuff we're going to display for them?

Instead of just throwing a reference to the relevant user's memberContext, we create an array for that user (to be referenced in the return from pDC) which has the list of items to be displayed, and in the order to display them.

The markup is already a series of li with classes, e.g. li.membergroup, we just create that in the array as the key, with the li contents as the array contents, then we can just render it consistently, and plugins can reorder it or insert things where they like with array_insert, provided that it's accessible via a hook (which there's no reason why it wouldn't be, hell, I see no reason why this wouldn't be done before the main post-getting query is done, so it would be done before display_main is called)

How does that sound?

Do you think it's gonna be noticeably faster?

Faster than what? Building a separate array instead of calling memberContext? I wasn't planning on doing that just yet, more just leaving lMD and lMC alone and just yanking out the details needed into an array to be used by the template. It would actually be marginally slower than the current solution, with the exception that it's actually much more flexible and wouldn't require any extra hooks to be set up.

Though that would pave the way for overhauling lMD and lMC in the future, of course. I really should sit down one of these days and figure out if all the stuff in lMC is ever used generally or just in the profile area (and if there's stuff only used in the profile, perhaps it should be broken out and put into the profile area)

I think I'll let you think about it because I haven't touched the Display code much these last few months and I feel totally unable to help here... :-/