Wedge

I'm sure there are multiple ways to do this... There should be a hook with the message content somewhere, so you might be able to simply add something to the body that says it's the OP...
If you want to add something somewhere else, I guess we'll have to add hooks for per-post templating. But that would be a good thing, of course. Not sure how to deal with themes that wouldn't follow them, though... (Their loss?)

Or maybe something could be done at template rendering time... I remember I wanted to add a mini-template just for posts, so that you could add a template_after or template_before etc that would apply to EACH post... I don't think it's possible for now.

Per post templating is one of the things we've not touched for the obvious reason of keeping it lean and not sure how to do it without it being a total mess.

Oh... I don't know. I'm sure it's not that complicated. I wrote most of the needed code I reckon.

For instance, the skeleton system has no problem running a sub-template several times, like the linktree code. It just needs two different arguments -- <linktree> and <linktree:bottom> in our case. There's nothing preventing us from having a <message:0> entry where the message numbers are indicated in the skeleton.
Of course, this would all have to be done through wetem::calls rather than skin.xml editing because it's a skeleton that needs injecting inside the main area of a single template. But it's all done I think...

Haven't had time to look into it, though. I'm hungry.
What do you think? (About this. Not that I'm hungry. You silly.)

Well, it's complicated to do nicely.

Essentially running a subtemplate several times is the way to go, provided that the sub template can be run with injecting $message into it in some fashion.

Remember, the template itself (yes, ugly I know) gets the $message and all the information for it from prepareDisplayContext. This would also solve a bunch of other stuff if we can do it, because it would allow easy extension of the poster info in a nice way, or replacing likes with something else in a post.

It isn't just the post template I'm curious about, just any template in general.

Can something like hook tags be added to the templates which are replaced by HTML added by hooks during the buffer rewriting, where you also process the <we:cat> etc[1]. Add a bit more pre-defined templates (similar to <we:cat> etc) and theming cannot be a complete mess.

EDIT: The above idea is potentially stupid for contextes where data processed in the template is required....

Second EDIT: This above idea is actually pretty stupid in almost all the cases, this is almost same as adding a call_hook to templates and that can actually pass data.

1.	Not entirely sure, but I believe it's done around buffer rewriting part of the process?

<we:cat> is down to the skin itself, as is <we:title> and <we:title2>. The skin defines what they are meaning that the skin can provide whatever markup it likes for them.

It would be possible to add more, sure - but what? Replacing the we:cat/title/title2 were the big ones.

As far as other templates it really depends on what - the main structure of plugins has been to allow plugins to add new subtemplates - they can replace entire subtemplates in the skeleton too.

Everything else we'll take on a case by case basis.

Yeah, I almost realised the mootness of my post as soon as I hit the submit button. It's just that there isn't (and pretty sure there really won't be since it's fundamentally a much harder thing to do than modifying source files) a good way to modify templates freely.

And there's the rub: free template editing is very liberating but it's also very fragile - and this applies to even systems like XenForo that have a templating system with its own meta markup.

I'd rather just flat out deny that and figure out reasonable compromises in the meantime.

True that.

While we're on topic, can I ask a core feature request to indicate whether the poster is the OP? :P...

You can request it :P

On a more serious note, what did you have in mind? I've thought about adding CSS classes to the post container for things like topic starter, whether the person is an admin and so on.

I'm open to suggestions for other layout issues (and to me, this does seem more like a plugin candidate than a core feature)

It definitely is a plugin candidate, but it's not an easy plugin to create currently (although perhaps hooking into prepareDisplayContext and modifying member's entire link HTML can be done, not sure). I basically wanted an indicator (something like [OP] next to the poster's name) to notify that this person created the thread. In forums where discussions can go on for hundreds of pages, it becomes harder to track who actually started the thing. Classes isn't a bad idea either, but they're not entirely clear cut indicators for new members.

Well... here's the thing, if it were done with a class, you could use ".root.starter .mime a" as a selector for the name and add something with the before pseudo thingamajig.

If there were some ability to set up the post template as a skeleton it would be even easier to do with conventional layer injection.

Oh and yes, there is the facility to inject into prepareDisplayContext already.

Oh classes should be added for contexts, they can provide good theming opportunities if nothing else.

Wow, too many posts...
I'm not going to answer anything, I'll just reiterate a few things and ideas, mostly for my own benefit because I'm a bit confused right now...

- I think that message lists are an excellent candidate for a 'special case' where we inject a mini-skeleton into the game. This doesn't have to be complicated... Something like <post:id><post_wrapper:id><post_author:id><post_body:id></...></...> where id has the list of posts... Then we inject that into the skeleton. Probably through wetem calls as I said, so it doesn't need to rebuild the skeleton, or as an actual skeleton if we offer users the ability to redefine the post skeleton in skin.xml or something. Then at rendering time, Wedge just calls the blocks as expected. I don't really see any show-stopper here. Is there...?

- As for hooks, Wedge already has _before, _after and _override blocks available for anyone wanting to add some template code to an existing block. I don't see anything that can be done through hooks but not through block overrides...? However, it might be a possibility to add a call_hook on a dynamic hook based on the template name. That might give plugin authors the ability to use whatever they like best, i.e. either a block or a hook to insert.

- I'd love to be able to say "we can also print a block to a temporary output buffer, then send it to a hook for post-processing, then send that buffer to the proper output buffer". It even makes a lot of sense, come to think of it... But I'm afraid that performance might be hurt by this process, especially in the Display pages (if we end up implementing the mini-skeleton.)