All of this stuff's easy, right? *ducks*
- In entry context, there is no way to get at the entry category's description, eg:
<MTEntryPrimaryCategory><$MTCategoryDescription$></MTEntryPrimaryCategory>(from ancient plugin).
- Why does MTEntryBasename ignore
dirifyand force you to use
separator?(I need to go back and confirm this.)
- Better logical functions. Switch has obviously been abandoned and has a couple of irritating bugs.
- A general iterator. Why is there MTCommentOrderNumber and not MTEntryOrderNumber, etc?
- Math(also apparently abandoned).
- Integrated "Expressions" support.
- MTCalendarIfBlank(and any other calendar tags that may do this) to provide date context, cf. Pronet message
- Why does MTLink not have a system-wide
template_idattribute to match
category_id, while we're at it.
Without getting bogged down in the specifics of the examples above, the overall point is that the template language seems to have reached a plateau in its capabilities(as different from features). There's logic, but only basic if/else, it can't count in any significant way, etc. People are building sites that require increasing amounts of "intelligence" in the templates. Also note these things don't necessarily need to go into the core, as they could theoretically get pretty advanced and run off more casual users. I'm perfectly fine with the idea of official plugins.
It would also make me very happy if the template tags cleaned up after themselves on render, so that markup doesn't end up weirdly spaced in the resulting souce code.
- Add DefaultArchiveExtension(or DefaultFileExtension, which would also cover index templates), cf: this forum thread
- HTML versions of everything.
- Also downloadable versions of everything.
- Actively discourage usage of Berkeley in installation guide.
- Are the accesskeys documented anywhere? I don't think I've ever seen.
- Very few people seem to have any idea what the activity feed does.
- mt-wizard.cgi should, if possible, automatically launch mt-testbg.cgi and add the appropriate config directive. (Of course, this brings up the issue of LBT not going well with FastCGI and potentially generating an installation that's essentially DOA)
- It would also be rather neat and convenient if the preview of the generated config file at the end of process were editable, for those of us who will definitely be adding stuff in.
- It would be nice if the system language could be generalized a bit somehow. Not everybody's building blogs, and it confuses clients when I have to tell them to ignore that. Editing the language files results in a global change, which isn't necessarily appropriate, either. Maybe something along the lines of optional blog-level language files, similar to how the alt-tmpl dir works.
- Following from that: relabeling of the entry fields(blog/system admin only). Clarification, since this sounds like an extension of changing language above: I would like to be able to relabel the fields, so that if I'm entering events, the Entry Body field says, "Location"(for example) instead.
- Unless they're so deeply rooted it's just not possible, I still say trackback and comments should be (core) plugins, though with this sort of thing it might be more appropriate to call them modules, I suppose.
- Editor-manageable chunks: If I want to let someone edit a piece of content that isn't an entire page/entry(a daily message, for example), but not give them template edit privs, there's no good way to do it. I currently use single Blogroll items for this, which is pretty hacky.
Like you need to be told...
(Though these are roughly in order, since fields and multiblog have existing plugins, anyway.)
- Multiblog-esque functionality
- Custom fields