Wedge

Return by callback is cool. clean_output ensures ob_sessrewrite gets called too, so the URL rewriter gets called and everything's magic and wonderful.

Also, no, I didn't get multiple notifications but at the same time the original one was still unread...

It's quite simple: unwind to before r2103, click like and before you do anything else (like going off the page), click the what-is-now-an-unlike button and it'll fail. Not the same bug, but it puts a lovely error into the Apache log.The like template outputs a <URL> for the current post, except of course, return_raw wouldn't parse that into the $scripturl format. It also wouldn't apply pretty URLs to it either.

The answer is to call the other return_ functions or call clean_output so that the relevant buffer gets called. Or, I suppose, calling the main ob_sessrewrite buffer directly but I'd rather not. The problem as outlined in the changelog is that you can't call clean_output because it clears what's already in the buffer and in our case that would be the contents of the like template since it doesn't return anything, it outputs it.

Now, I suppose, you could rewrite the likes template to return its content rather than echoing it (and then alter the places where it's called to treat it as a returned value rather than something that will output things.

The only reason I noticed it was because I was testing the likes notification after I moved the file into the notifiers folder, and it was failing on me.

It was funnier when you had people with the developer badge that weren't even using 2.0.

The reason why they use it to ban instead of actually using a ban is because only admins have the ban power and using the warning system in SMF to mute users is cheaper in performance terms than using the ban system itself. (Coincidentally, using an infraction to actually ban a user is cheaper in Wedge than using the ban system to ban a user is too. And for a similar reason.)

The warning system is useful, though I'll admit not as powerful as it could be.

I've always wanted more options for the editor. I like users not having to write mods for something I can reasonably trivially support in the core. This has made the editor code slightly bigger, haven't benchmarked it in terms of size.

I'm planning to offer up the whole editor thing itself being organisable, but just this for now.

I spent an hour futzing with it and farting with variable scope. JS is a tool I can use but it doesn't mean I like it...

Because I had to do something with it. The original suggest objects were contained inside the wePersonalMessageSend function as properties and thus not accessible outside of that object.

I dunno, it just felt slightly more natural to do it the same way as other stuff does it. *shrug*

Well, it's also a core feature so when Nao updates the site to current SVN, you'll no doubt get to try it. ;)