I’ve been using MT since early 2003 and have been irritated from the outset by the behavior of the MTComments container, in particular its inability to produce a list of blog-wide comments no matter the context.
No matter whether it’s an individual entry or a category archive, I’d like the sidebar to always show the last N comments, but that’s not possible with that container.
I’ve worked around this by producing a blog-wide comment text file that gets used by every template, but that seems a lot of work for a function that I’m guessing most people would want.
Would it be possible with the container to create some sort of MTComments modifier that would provide some flexibility as to whether the results are in or out of context?
<mt:Comments> is a MultiBlog-compatible template tag (links are for your easy access to the docs). If you experiment with the mutliblog attributes, you should be able to load them from all contexts. I don't have time to test it tonight, but you might want to try either doing include_blogs with all of your blog ids or try exclude_blogs and either give it a value of "" or something like "0" or "-1". Exclude_blogs is supposed to start from the basis of "do EVERYTHING but this set of blog ids" so that very well may work for you.
So using the MutiBlog attribute would override the natural behavior of the container tag?
It should. The reason that it doesn't work the way you want it to is because the container tags, by default, are supposed to pick up the context that they're being called in. Multiblog attributes are intended to circumvent that behavior and let you specify a new context.
It should be pointed out here that this is normal behavior across the template language, and is correct. If, for example, you stick an "mt:Entries lastn" block in a category template, you'll get a list of recent entries in that category, not across the blog. And so on for the other containers.
More importantly, what you're describing is bad practice: it would result in that list of recent comments being determined over and over again every single time a page was rebuilt. This is precisely what tags like mt:Include and the newer module caching & SSI options are trying to avoid.
@Mike T: I wasn't aware of that use of MultiBlog. I'll try it.
@Su: I don't dispute that the "normal behavior" is correct, nor do I dispute that it is inefficient for the tag to repeat its work over and over. But I don't think it's wrong to want tags to be flexible, to be able to easily override the natural behavior in a way that might be useful for a significant number of users. And why does MT care if I choose to be inefficient?
It should be pointed out that using MultiBlog for this purpose is a bastardization of its intent, because I would be using MultiBlog for one blog, which is kinda silly. So while it might be a solution -- I don't know yet -- it's not an intellectually elegant one; it's another work-around.
If I remember correctly from when I tried it, module caching produces the same in-context results. My memory sucks, though. There was something about module caching that didn't serve my needs.
The SSI options looked intriguing and looked like they might replicate what I've been doing manually. However, the documentation (at least at that point) was not written for feeble minds such as mine, and I gave up without ever actually finishing a test. I will revisit it, though.
So it sounds like I have several options. But in my ideal world, the MTComments container would retain its natural behavior but give me the option of acting as I would like it to, without having to invoke MultiBlog.
Thanks for the suggestions.
And why does MT care if I choose to be inefficient?
It doesn't, generally. The system will happily let you do lots of inefficient things, as long as you play by the language's rules. Like stick that comment listing in every template rather than an index or cached module.
While you're correct that using the MultiBlog attributes here is arguably a bastardization of intent, it's still perfectly valid use; the language doesn't care(again) that you've chosen the target blog to be the same as the one it's already in. If it were "intelligent," then Clippy might pop up and ask if you really meant to do that, but it would still let you.
So: you've always had a way to do this, and in a more proper(structurally) and efficient(practically) way.
You were essentially making a feature request that is intentionally inefficient even though better alternatives existed, and while MT may not care about that, the engineers do. If you can justify the above to them, then I'm sure they'd be happy to add it.
The request itself was not inefficient, and I did not intentionally request a feature that was inefficient. I merely made a request that others have helped me recognize as an inefficient solution. It might have been a stupid request -- my apologies! -- but with no inefficient intent.
Well, if it worked the way you originally expected, it would make developing templates in a multi-blog environment a pain.
Actually, no. I was simply asking for a modifier that it would allow it to behave the way I wanted.
But ... a moot point.
Su is correct. You should put this code inside of a module that has caching enabled on it. If I were you, I would have the module expire no less than every 10 minutes if this is going to be a module used on a lot of blogs.
@Su @Mike T: The combination of module caching and SSI appears to accomplish what I was hoping for. The documentation on SSI has been much improved since I first looked at (or maybe I'm less dumb today), and implementing the two of them was easy and (so far) effective. Thanks for the help.