Wedge

I'm not ignoring you - I really just haven't had time to keep up with everything :(

It's a mindset problem. People think mods, they think of modifications under the hood. They won't see it as modules, no matter how hard we try. We need a clean break to be able to get away from that mentality.

Hmm, good question. Not sure right now... need to think about that.

Neither is integrate_eggnog but hey, who's counting?

magic_quotes shouldn't really be needed though (only for those really weird CMSes that do strange mystic things when magic quotes is enabled)

To a point you're getting into the game of second-guessing the developer intent, and without any secondary information, it's hard to be sure.

Remember, the integration functions were originally for linking SMF to a third party app, so reset_pass makes sense there, because what you're doing is when a user changes their password in SMF, you're flagging a routine in A.N.Other system to update the same user's password there too.

I'd argue in that case, there shouldn't be a need for the value to be byref. Other instances, however, yes it should be a byref, particularly if it seems logical for a third party app to want to modify something before SMF has its wicked way with it.

We're sort of taking that idea and expanding on it, meaning that any original purpose is likely now somewhat irrelevant. For each hook, look at where it is, what local variables are applicable and make a judgement call as to whether it is reasonable and appropriate for third party code (of any kind) to be modifying that. reset_pass is one case it shouldn't be necessary, for example.

Well, it's more a rewrite than port given the changes already to the editor component, not to mention the other changes we've already done. More importantly, though, the plugin system would need to be rethought and brought more in line with how RC4 implemented it (which, I have to say, was cleaner than how I did it in some ways)Sign me up :D$context['member'] actually makes sense for the most part since its main use is in the profile area when you're looking at another user's profile, so it is the contextual information for that user. $context['user'] though overlaps mostly with $user_info for no discernible reason.That's not anticipation, that would just be stupid :PA lot of the really little tweaks currently published as mods would be tricky to implement directly because of what they do - rearranging little bits of templates, and realistically, those are not possible to hook simply because of the mess you get into because you'd be adding hooks for every single minor point.

I did that, actually, in a shoutbox I built; as part of the plugin system SimpleDesk had, I did actually add the same hook that the action handler routine has (though calling SD's hook rather than SMF having it), and abused the hook to not only add my action but also to receive the AJAX calls and handle them, as well as manipulating $context at the same time.

Goes back to what I said before - the running state in $context is fully manipulatable, but really there should be no need to abuse such a hook when a better structure can be put in place.Yes :) This is something I'm quite keen on, not only providing the framework for modders but working with them to build add-ons, so not only providing dummy add-ons but full new features as add-ons that demonstrate how to achieve various things.Well, they were designed for integration which is where the name comes in, but sure, we can rename them to be more appropriate.I still have no idea why that exists when $user_info contains virtually everything you'd want to know anyway.I wasn't going to do it that way, I had a simpler plan - once the action handler was known and the index knew where it was sending the user, I planned to add a hook before and after it has run (since some functions don't return back, and some users will no doubt want to expand upon what's already been done). Yes, there is of course a performance hit there, but the increased flexibility more than makes up for it.For the ones that aren't in the core itself, I'll likely put some time aside to sit and implement some of the smaller ones, partly as an example of 'how-to' and partly so we have that functionality available for people. But I'd definitely want to work with mod authors to help them make the jump.Oh, I'm not disputing that :P I'm well aware of the idiosyncratic nature of SMF's code, just explaining the basis for it...

Keep it simple: add-ons