And what about the integration hooks SMF has?
Plugin hooks
« on November 10th, 2010, 10:51 PM »
SMF's integration hooks were mostly useless up until 2.0 RC4 wherein they were upgraded to support multiple functions being called at the same point in the execution.
We're keeping most of the existing hooks and adding a lot more of them generally, and combined with SMF's general structure of keeping the current running state in $context (while we'd like to phase that out, doing so is less than trivial),
So yeah, we're not getting rid of them, we're jugging a few around and adding plenty more.
For instance, create a global local array (if I may say), something like $local_array, which we'd global everytime we write a function that offers hooks.
Aaaaand, once again, I'm totally obscure and probably offering to do something that would complicate everything needlessly.
Yeah, $context could be a place to store most of these vars. We could also delete the vars after they become useless, but I don't know, maybe it'd be a waste of time.
Also, rename $context to $cx or something, to make it faster to type?
And we should/would/will try to be open about hook addition requests. Like, "if you add a hook here, I could do this or that without modding the code". If it seems like something that would benefit more mods, then it'll definitely warrant a mod.
Seriously, I think there are many places that should never have been moddable in the first place -- like, adding menu entries. It should be done exclusively via hooks. We just need to educate modders about it.
PS: maybe this conversation should be split into the private area.
Also, rename $context to $cx or something, to make it faster to type?
I'd recommend against it and leave it as a full word so as to be less confusing.Quote from Nao/Gilles on November 11th, 2010, 09:42 PM Also, rename $context to $cx or something, to make it faster to type?
SMC = Simple Machines Core, for things that wouldn't necessarily be strictly forum based but usable in other SM apps; it was in the mists of time actually $smfFunc.
There are other things we can do at this point, more on that elsewhere.
It's an interesting idea but not entirely practical,
mostly because there's already $context, and partly because hooks are there for a specific purpose, not just a convenient place in time; the actions hook for example is there specifically to be used with modifying the list of actions.
Really, pushing things to a 'global local' function is bad juju because really one thing I want to do is empty some stuff out of $context rather than fill it up more.
Faster, yes, more likely to collide with new local (temporary) variables but no real issue either way.
Sure :) Though a fair amount will be anticipation as well,
I have a litany of mods in mind that I'm constantly thinking... "how can I make that work without editing the code?" That's really my baseline when I'm thinking of the changes to make.
I'm actually fine with it here, because
I want to not only explain why things won't work but also the rationale behind the level of changes we're doing and the real benefits of hooks - while I'm actively going to be encouraging hooks, I want people to understand not only the 'how' but the 'why' as well. Remember, those modders who migrate from SMF are going to initially want to reuse what they've done before,
and while I'm not planning on pruning the package manager that far, I really don't want to encourage them to continue bad habits.
I want them to learn new ones, better ones, ones that will help them grow as developers, knowing as I do that most mod writers are not professional grade programmers.
$modSettings is for modifiable settings, it contains the contents of the admin panel's options that are forum wide (as opposed to $settings which is theme wide and $options which is user-centric) that are modifiable through the admin panel without editing any files, and is the general home of modification settings too.
But, see, what if the modder wants to do something in that place, but unrelated to the list of actions?
I think modders can start using hooks, as long as we provide them with a dummy mod that would show the correct ways of doing things. (Or some prominent mods start using hooks and they look into their code.)
And as I said earlier, we really should rename the hook functions, too.
Yeah, beginning with $context['user']...
I'm not much of a fan of anticipation, not because it's extra work for us, but more likely because if we start adding hooks in useless places, like at the beginning of every single function, it will waste CPU time for everyone, possibly for nothing.
Maybe for the most important mods, if there are any, we could offer the modder to convert their mods for them.
I think a good policy would be to add a warning when installing a package. In red.
Yes, but it's not very instinctive, see?
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.
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.Quote Yeah, beginning with $context['user']...
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.
Quote I think a good policy would be to add a warning when installing a package. In red.* Arantor likes that idea.
You want SD to be ported to Wedge, don't you...?
Integration is its purpose, but it shouldn't be its definition. Its definition is a hook.
Imagine that instead of calling parse_bbc(), you had to call parse_bbc_into_an_html_string()
Me neither. Probably another example of two vars that developed at pretty much the same time and were favored by one dev or another... Or they wanted to have the "me" equivalent to you's "$context['member']" or something.
Yeah, adding hooks in the main callee is perfectly fine and I would recommend it, too. Just don't add hooks in every Subs.php function, that's all
I'm sure most modders will work into making sure their modifications are all turned into hooks at that point.
(It's that's possible, of course. But right now I can't think of anything that isn't.)
$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,
That's not anticipation, that would just be stupid :PQuote Yeah, adding hooks in the main callee is perfectly fine and I would recommend it, too. Just don't add hooks in every Subs.php function, that's all
A 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.