Wedge

Yay for regression bugs, confirmed.

Okay thought it was an issue with safari on ios 6

Solved in last commit BTW.

Perfect :)

Losely related, but I won't create a new topic, ah ah...

So, rev 2103 mentions that likes are broken.
I took rev 2103, and reverted it here temporarily, and they still work. Like / Unlike / Like / Unlike... It goes on undefinitely, without a refresh.
Pete, can you tell me exactly how to reproduce the issue you mentioned..?

Also, you may have received multiple notifications for that little game of mine, ah ah... If you didn't, good. If you did, we might want to fix that to keep the notif in the database even if unliked, and then ensure the notif isn't already in there if we're sending a new one...

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.

Okay, thanks for the explanation.
It's just a bit odd that it works in here (and locally for me), but it's probably due to something like jQuery parsing the HREF at $.post time, and deciding to get rid of the 'wrong' characters, or something... :-/

Anyway, I've thought about it, over and over, and came up with a half-better solution. You tell me if you're okay with that.


We established that was bad... Now I'm doing this:


And the function is, obviously, defined as such:


What do you think..? Is it elegant enough to have as a utility function? Do you see yourself using it in future Ajax endeavors?

PS: I don't even know why my return_raw call worked at all, since it added the HTTP header *after* the template was written... Meh!!

Also, you didn't say if you received multiple notifs..?

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...

Your own fix was clean, too ;) I just wanted to make something that could be a one-liner and be used to output small bits that may be called through echos rather than string building.

Oh, thinking about it... I should probably add echo before that call_user_func_array, shouldn't I..? In case the callback function isn't a template at all... ;)Yup, that's the idea...
return_raw() really should be called only for stuff that doesn't contain long text, especially URLs and such... I don't know what got through me. I know I went through several phases when I wrote the return_* functions, and return_raw was added last (it was originally a way for me to more easily output some XML without having to re-read the output buffer handling documentation every time... :lol:), and I changed it from return_text to return_raw, I think, and for no particular reason... :-/Oh, then that's good news, no need to fix anything eheh. ;)

Hmmm, I've had some rum so I feel all warm and fuzzy but I'm thinking:

Then you're covered either way.Because return_text is what was originally used but it doesn't work because the template got echoed, then the buffer emptied, then nothing got returned, as I discovered last night ;)

I don't think testing is important, because it doesn't return null anyway, it returns false or whatever the function returns; and echo false will output nothing, so I think we're protected...

I submit http://codepad.org/JLJdxQBI as evidence.


$var is null. If you have a void function, the result of assignment of function result returns null, rather than null.

That way whether the function outputs something and has no return, or returns a value, it's covered either way.

I don't get why you're doing a var_dump when technically you should do an echo... :^^;:

And echo null, like echo false, returns an empty string...

I like code that explains what it's doing. echo'ing the result of a function that should almost always be a void function is not particularly self-explanatory.