Wedge

Fine, remove the English language pack, I'll just replace it with British :lol:

It's actually not so much of a big deal because in every case where performance actually makes a difference (like thread display), it's using the content id first (i.e. message id), and the primary key reflects that.

The flip side is making it either an enum or some kind of integer which makes it next to impossible to extend reliably.

But in any case, caching will (when implemented) take on the bulk of it workload here.

I didn't find much benefit - but I've been quite careful to set the gradient as strictly downwards, following the motion of the gradient itself.

The JS is used simply to handle shortening in the user-editing area, if it's off, things should still get truncated regardless.

Making it translatable is not a problem.

Consider it this way: is it really that much different to what's in the moderator log or the admin log? All you need to do is record the type of action itself (simple string), which also gives you the lookup for language string, which then just has to fill in the blanks with details.

>_> I just replied on another thread about the scope of changes!

Meh, today has been a grind, need tea and possibly a donut now.

OK, so I took a bit of time out to work on this today.

So far I have the core like behaviour set up, though there's no permission check (any non-guest can like content), and there's a bunch of housekeeping that isn't being carried out either. I have also got the AJAX callback set up as well, so it can AJAXively update and return the new 'x, y, whatever likes this' string.[1]

Anyway, still to do:
* tie up the AJAX stuff so it's called AJAXively and updates as such
* implement some kind of permission
* implement caching

Here's the thing. I did some studying of what goes on elsewhere, and I found that in reality getting the like data is actually going to be very awkward, not to mention unhelpful in other respects.

As it stands, we get the message ids, the poster ids and the post times early on, but bulking that query out to fetch a text field is going to make it expensive, especially if I subsequently throw all the extra ids into the loadMemberData queries, doubly so when you consider that in most cases the names you're loading probably won't be ones you need anything for except the name.

So my plan instead is to cache the list based on a page's worth of messages - I get all the like data I actually need for a page's worth of messages, and cache that as a single unit, so I can reload it as-is. So right now all there is, is the one extra table that stores likes, and nothing else. The overhead is not actually that significant especially since it looks like it's being indexed meaningfully.[2] The only need for caching is simply because it will be queried in its entirety and the information digested appropriately, but the whole point of caching will fix the side issues with that.

1.

Though because I'm doing it through the action=like handler rather than anything else, it got... upset... I had to expressly detect for and start the gzhandler buffer otherwise the browsers all cacked themselves at the content being incorrect.

2.

The table structure is four columns: id-content, content-type, id-member, like-time. This way, likes can be extended to media or whatever else with little real effort in the DB. The trick here is that content-type is a fixed width field, currently 6 characters, which should be enough to be at least representative of content, currently only 'post' is supported but there's the foundation for hooks to be able to extend it arbitrarily. But because it's fixed width rows, with a primary key of id-content/content-type/id-member, and queried that way, it should be pretty lean.