Wedge

Did you truncate the table or empty it board by board?

I wonder why we place so much importance on these numbers that, in the scheme of things, really don't make that much sense.

I find it interesting that WordPress does not keep a view count per article. Or if it does, it's not actually shown in their ACP anywhere I can find. I wonder what the logic of not doing so is.

There are certainly cases on sm.org of threads having obscenely high view counts unnaturally quickly (rising tens of thousands inside an hour)

Sure it is. We just rename the classes, declare an autoloader, and do a loadSource on the name if it fits our normal naming convention (or the file exists with the right name). We just get to stop doing loadSource() explicitly everywhere, which is kind of nice.They're obscure, sure, but they contain a *lot* of information in a small space, which is why they're obscure.

As for notifications, @Dragooon is probably the person to ask.

Um... kind of. Let me walk you through what an autoloader actually does (and it's irrelevant whether it's __autoload or spl_autoload_register)

An autoloader is something that does the loading of a class when it's called for without explicitly loading it. You just say $var = new Classname(); and if it is already loaded, fine, if not the autoloader function is called, and given the Classname and essentially expected to figure out how to load it.

__autoload is the simple version, one function, application-wide, that will receive every call for a class that doesn't currently exist. spl_autoload_register is the swish version, which lets you declare multiple functions that act as __autoload functions. They will be called in order and attempt to find the class name. Bear in mind plugins may well want to declare autoloaders. I'm strongly thinking of making SSI auto-loader driven rather than including every function every time it's used.

Short of having a list of names to files (e.g. wedit => Class-Editor.php), there's simply no way to do it. If we're going to do *that* we might as well not bother with an autoloader in the first place.I was actually thinking per installation myself.There are surprisingly few cases where every AND criteria will be matched on a single index, at least not when you get multi-table queries going. Part keys can be useful too.I'd be inclined to leave it out for this purpose but perhaps include it for newsletters. Technically, though, if you include both versions (which IIRC you're actually supposed to do for specification compliance) it seems less likely to be misread as spam. But then you're including two copies per email which is not cheap (and the poor mail queue gets hammered even more by it because the bulk insert can't do so many per cycle)[1]

1.

For those not familiar with how the mail queue works, it does something unlike every other insert in SMF/Wedge. Most inserts, even those with bulk lines to insert, are never going to get anywhere near the query packet limit, but the mail queue insertion is potentially very likely to do so. So the query is built bit by bit and then thrown as a single big-ass query, typically around 800KB in length, into the queue table. I have to admit I was impressed when I first saw it because it's showing an awareness of a problem most people don't even know exists.

class Likes_Notifier for example... you'd declare new Likes_Notifier and Likes_Notifier is going to be the information made available to the autoloader. Normally, in autoloading cases you'd have the filename (notifiers/Likes.php) match the class name (Likes_Notifier), which it doesn't.

And an autoloader wouldn't help in wedit, wezip, westr, wesql or similar cases (but most of those aren't dynamically loading) or any similar 5-letter class naming scheme because there's no way to derive the filename from those class names.

And in any case, an autoloader is going to be largely screwed if you want plugins to use them because the plugin folders aren't part of the autoload list. (XenForo solves this aspect by essentially expecting plugins to add to the master Library/ folder so then you have Library/Author/System/Component deals, giving you classes named Author_System_Component, which IMHO is hideously long) And plugins will want to declare their own notifications at times.I wouldn't ditch them. I'd make it an option. There are times ratings will be useful. There are times likes will be useful. There are times when both are unnecessary.Sort of. When you're going through and adding clauses in MySQL, you generally want them to follow the ordering of the indexes.

In hindsight my index suggestion was probably naive but I'm kind of thinking on the hoof a bit here. If you have two clauses in a WHERE, MySQL is going to run them in that order. That means if you're doing two WHEREs on table contents, the WHERE clauses should follow the index.

This is kind of a chicken/egg scenario, the query should follow the index but the index is for the query's benefit. What is ideal is the characteristic of selectivity. The more selective something is - i.e. the criteria that lets you select a suitably useful subset of rows with the fewest characters - the better the index will be.

I suggested notification then what the notification is about, because that's logically the direction of selectivity, but I suspect on profiling it, putting the index on id_object then the type of notification (but making the index cover both fields in all cases) would be even better. It's still selecting the same rows, still selecting the same data, but the way it goes about it (which is what EXPLAIN will tell you) is faster. If you have to go through something row by row, better to have the fewest rows possible first.Do you still want to do it? Most of the licensing issues aren't really issues - the outstanding issues are Exifer/Exifixer/Exifier and JWPlayer. Everything else for that just isn't a problem.

And I suspect it wouldn't be such a big deal to do the replacement - the real issue is doing it for *here* at this point in time. Though I'd suggest refactoring Aeva's code at this point so that action=media itself might still delegate tasks everywhere but it doesn't need to load hundreds of KB of code to do so every time (for busy galleries it can actually hammer a server, to the point where one 'firewall' mod for SMF typically considers it a DOS risk)

If you like, it's something I can tackle when I'm back?I asked Dragooon about that a while ago. Basically, he wanted to just objectify it because that's how he likes working. There's nothing wrong with that, and it does have some certain conveniences in terms of keeping everything together; it implicitly namespaces everything related to notifications and to a point I'd sort of like to do that with some of the other subsystems in Wedge, e.g. mail sending.

Of course it would also encourage standardisation of the naming system like you wanted to do.Yeah, I know that feeling. Related, please add my last commit (to Who's Online) to this site... the lack of debugging information is proving a little awkward, especially as I'm fairly sure I've seen two new malware bots hanging around... :/

I do have some of the changes fixed for the /e modifier deprecation but I'm not yet ready to commit them for a similar sort of reason

Yeah, see, that makes sense to me.

Very tempted to agree.I wouldn't say that. Just need to be careful about what we do and how we do it.

Of course, one methodology of nailing that is simply to strip nesting of quotes so that when you quote a post you're only quoting that one post so you wouldn't get crazy amounts of notifications. So that when a post is quoted, only that post's owner gets notified.