Wedge

You could just as easily do all that extra processing when fetching it all, making that determination based on other settings, and it wouldn't be an extra query depending on how it was set up.

lMC does no requests itself, it's part of lMD to get the data, but that's no big deal really.

All of the above.

But if you disable all that stuff, it seems like you're not using all the stuff it's (supposedly) useful for... in which case you might as well not bother and use a separate DNS service.

Well, loading additional data in loadMemberData is not a big deal (it's only one extra field at this point). The cache of fields/positions etc can be pulled from the membergroups table in probably a single query.

I'd argue that for the purposes of displaying multiple groups, you don't actually have to care about primary/secondary, but rely totally on the order specified in the membergroups themselves, for badges that shouldn't be displayed, store their position as 0, for all others store their position as 1+ to indicate the position, then just query the table WHERE position > 0 ORDER BY position, and you get that information pre-sorted too.

It wouldn't necessarily *require* a cache but I'd cache it.

Hmm. Would it really be so bad not to have the subject every post? I find the concept of juggling {re} around a bit much. If there's no title, we assume {re} Topic title, or just not display anything unless a title was actually set...

(3 files, 2KB)

Revision: 1605
Author: arantor
Date: 03 June 2012 03:03:54
Message:
! SMF bug: The anti-spam tests should be properly case-insensitive, not partially, i.e. should be UTF-8 aware when lower-casing. (Subs-Editor.php)
! Provide a more meaningful default for timezone than 'the first on the list' and if there's an error at registration actually remember the one the user picked when re-displaying the form. (Register.php, Register.template.php)
----
Modified : /trunk/Sources/Register.php
Modified : /trunk/Sources/Subs-Editor.php
Modified : /trunk/Themes/default/Register.template.php

Different kind of meta information, but yes, I suppose. Compared to general tags, we're talking about (probably) one tag applicable per topic from a set list, and it will be displayed in the message index, where tags would not normally be listed.Oh, I like it. I'm just thinking that I'd probably provide proper prefixes as discussed here as a full plugin.That's the thing about using full-on prefixes is that you never have to battle with the response-prefix in the subject because it's entirely separate.I'm not sure what the logic was supposed to be, something to do with making sure you got the right one based on something else's language or something >_>Actually, a better solution would not be to worry about it at all. If we were to juggle things so we didn't actually have the title sorted expressly every post, we could just use response-prefix as necessary. There's a lot to do but I think it'd be worth it not to store every single subject every post.Neither, really. On the one hand, you have the ability to create what amounts to a form, asking users for content, validating it and then dumping it into a post. Some roleplay forums use this to handle 'clan entry application forms', for example.

On the other hand, you have the ability to insert pre-defined blocks of content. I did something similar in SimpleDesk as 'canned replies' where the admin could create a bunch of templates of content that could be inserted into the post in a few clicks, which is useful in a support context as it were. But both have other uses too. Just neither of them are things I personally want in the core, especially as the dev effort for creating them as a plugin is virtually identical.Which brings me back to the answer I originally gave; that is one very good reason why none of the major forums have implemented this feature in the core. I'm not entirely sure we actually *need* it, I was far happier implementing this as a plugin personally, but we could probably make it a core feature - yes it would have to be handled through the attachments system because that's the only way I'm remotely happy of allowing it at this stage.Here's the problem, on the one hand you have people who want lots and lots of details and on the other, you'll have people who want very little.

Actually, what he's thinking of is not the same thing you were - in his (and my) view, thread prefixes are a way of selecting a prefix from a dropdown, e.g. what I did on whatsthatgame.co.uk in particular in http://whatsthatgame.co.uk/index.php?forums/aralander-discussion/A posting template system can take two forms, either it can be for having one or more predefined blocks of content that can be easily inserted into posts, or it can take the form of being an outright form that users have to fill in to generate a post out of it, e.g. for application forms for certain things.

Both would be good to have as plugins, but I'd argue they should be done separately as plugins.That might be useful. But there are good reasons to leave it in.That's half way towards what he's talking about, incidentally.Then it needs to have less content in it if it's going to be done without tables; right now a table is the correct semantic item for it because it's tabular data.