Wedge

Well, on my todo list is the ability to do true AJAXive quick reply, as in submit the post, get the post in full display mode back and inject it into the page itself.

Problem 1: deferred events
Answer: for code requested via AJAX, don't defer the events. It uses slightly more bandwidth but since everything on the page will already be available, it's not like we're waiting for dependencies like jQuery.

Problem 2: menu items
Answer: When the post is retrieved, drop all existing mini-menus, splice the new post's items into the existing menu definition and re-call it. The returning fragment should deal with this rather than having it already in every page load (since not everyone is going to do this)

Problem 3: payload
Answer: It actually doesn't really matter whether it's JSON, XML or HTML in a light wrapper. As long as it comes through and can run scripts or whatever, it's fine.

You mean like this? (10 minutes work)

OK, it isn't pretty, it doesn't have a magic language string or anything for the menu item but that's probably for the best...

The logic behind 'notify' is that it (currently) enables an email to go to you when there are updates. It's a passive thing. Following implies something more active.

If we had some interface for showing you just the topics you're following (separate to 'unread topics' and 'unread replies' as we currently have) it would make even more sense to rename it.

This should now be correct for any move-topic notifications generated with r2165.

Nah, there's no real need to delete it :)

Gotta remember also the longevity involved in this stuff; SMF 1.0 had print page - back in 2003-4. I kind of want to speculate that even YaBBSE had it (which puts it back to 2001-2) but since YaBBSE's own site is actually running SMF on the sly[1] back when the intarwebs were a very, very different place.

For example the notion of a 'print friendly CSS layout' as suggested in that thread just didn't exist.[2] So it was needed in the application rather than some kind of catch-all.

I don't even think the code has significantly changed in SMF in that time, thinking about it. Other than the necessities (db_query -> $smcFunc) it is probably the same or almost the same. I might if I get bored do a comparison.

So yeah. I think this is another vote for 'getting out the bone saw'.

1.	Yes, it's actually running SMF these days though SM LLC allowed SleePy to modify the footer to not say SMF... this is back in the pre-BSD days where altering the copyright was a no-no. But since Lewis Media handed the rights to the LLC, it was allowed.
2.	CSS 3 didn't exist. Neither did HTML 5. Hell, Firefox was only just emerging back then. I still remember Netscape Navigator upon which Firefox was originally based. Those were the days.

I dunno. I did it with SimpleDesk and while I liked it (especially since I folded own/any into it), I don't think it would work for us. Partly because deny wasn't actually an option in the UI. Partly because we can't actually fold own/any into the dropdowns (since there are situations you'd need to give permissions separately and because there are some fubar moments in terms of any overriding own but the UI doesn't cover that aspect)

Though I don't know why we wouldn't just use a standard selectbox and be done with it if we're going to do it. The | option to add text after an item would cover that well enough.

Ultimately I don't think it's the solution to this problem.

I don't let my browser save passwords in the first place, so no idea, sorry.

I guess I could write a plugin that you can use here to trigger it that only requires a GET session check rather than a POST session check and let you put it in the main admin menu?

Oh crap, I know why that is. It's one more thing that needs to be fixed up after I gave custom fields their own set of access rules.

I'm off out in a minute but I'll fix it when I'm back.