Skip to main content
Topic: Adding Hooks (Read 2590 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Adding Hooks

What's the general thought on adding or modifying hooks?  I'm looking at 1.1 and all the code edit mods I have to update and hoping new hooks would make it easier but not finding them.  First example I'm looking at right now is I add additional info in the function loadExistingMember which is called from action_login2.  Sure, I could hook onto the end of login2 except I actually check that information to make a yes/no decision on the login and doLogin would already be called.  

So a last hook before doLogin that would allow me to set a failure variable checked before doLogin was called as well as set $context['login_errors'] would be nice.

A lot of the other changes are still in Post and all the is_allowed type stuff.  I haven't checked, but have hooks been added to all those functions to modify their results?

Re: Adding Hooks

Reply #1

Your first example doesn't have many details, but I think the answer could be: use integrate_validate_login, that is executed just before the loadExistingMember call and is designed to let addons check the credentials against other sources (e.g. external databases). And if you want to change the error, you could use trick to change the value of $txt['login_hash_error'].

Post controller is really different from what it was before, it use "triggers" a lot by itself (triggers are another way of extending elk that is a kind of experiment, I like the way it works, but since I'm the one that introduced them it's kind of obvious, there is some documentation in the "a function a day" topic), you should be able to do many things without touching anything (think that already attachments, the calendar, drafts, mentions, polls, anti-spam verifications and some other stuff are all implemented through this way of extending elk and are no more hard-coded into the code).

BTW, I found your suggestions from a couple of years ago and I answered almost exactly like now... lol
For the "new" icon there is a new alternative: set a class for the whole post wrapper and then use css alone (anyway I'll try to add the class in the core and an indicator somewhere, then you can just change the css to have it where you want ;)).
Bugs creator.
Features destroyer.
Template killer.

Re: Adding Hooks

Reply #2

Doing it in the hook you mention requires me to basically copy all of loadExistingMember which seems pointless as I need the user ID which is what loadExisting member does it try the different ways to find it.  I'll just stick with the simple code mods.  Same conclusion I came to on 1.0.  I suspect that will be the case in general in 1.1 as well.

Most of my mods in post are modifications to the allow functions.  None of the cases you mentioned makes me think triggers will help that but I'll have to look into it. 

I do agree the "NEW" indicator in posts should be part of core.

I get the gist though, no new hooks.  That's ok code mods don't bother me much.

Re: Adding Hooks

Reply #3

On the first I'm not sure, I think an additional query wouldn't be too much bothersome (also because it's not a query that is run on each and every page load, but just during the login), but it really depends on what you really need to read from the database.

Quote from: scripple – Most of my mods in post are modifications to the allow functions.  None of the cases you mentioned makes me think triggers will help that but I'll have to look into it. 
From the description you may not have much advantages from that this round, in the next one you may replace entirely the post controller with a custom one and rewrite only the little you need to change (since the pattern is to isolate blocks of code in their own methods, you would be able to extend the post controller and re-implement only the methods you want to change), but it's likely too early to speak about it.

Quote from: scripple – I get the gist though, no new hooks.
I guess you got the wrong one.
I'm trying to understand why the ones present are not suitable to you, and what is the "best" solution (add random hooks is not always the answer, especially when dealing with the login, because you may have to call the same hook in different locations and you may end up calling it with different parameters, like the hook that is causing one of my addons to choke in a somehow random manner).
Bugs creator.
Features destroyer.
Template killer.

 

Re: Adding Hooks

Reply #4

Quote from: emanuele – I'm trying to understand why the ones present are not suitable to you, and what is the "best" solution (add random hooks is not always the answer, especially when dealing with the login, because you may have to call the same hook in different locations and you may end up calling it with different parameters, like the hook that is causing one of my addons to choke in a somehow random manner).
I understanding adding random hooks isn't a good thing.  It's not my goal to create headaches for everyone.  I think a hook after the user ID has been determined and elk has done it's checks but before the login is done could be useful, you don't.  As you said we discussed it a while back.  It's simply not worth an extended argument when I can just modify the code.

Quote from: emanuele – From the description you may not have much advantages from that this round, in the next one you may replace entirely the post controller with a custom one and rewrite only the little you need to change
This is like rewriting loadExistingMember in the hook in login2 right before the call to loadExistingMember.  I already have some code in various places that basically does this.  It copies an existing function for all the parts I need and does one small thing different.  In the end I've found this technique is worse than code edits because it silently fails on upgrade.  In 1.0.8 a small thing was changed in login cookie serialization which changed how the remaining time on the login timeout was read.  My code which copied the existing code to decode this suddenly was reading the login timeout as a few seconds (technically it was failing and getting some super short default I think) and it was causing me to suddenly be logged out.  Had I done code edits the upgrade to 1.0.8 either would have just worked because it updated the code I needed or would have flagged the problem if my edit interfered with the edits 1.0.8 was going to do and I could have inspected the code and made the simple fix.

So when you have people replacing controllers or functions will the upgrade process warn them which ones changed?  That seems to put a lot of extra work on the forum developers if they have to track everything that could possibly break a customized version or the mod developers if they have to read every github commit or remember to diff against everything they modified X time ago.

Given your desire to eliminate code edits and effects like what I just described I'm starting to think it would be easier and safer to do as some others here have mentioned and just keep my forum as a revision controlled code repository and have a "clean" non-public copy of elk against which updates are applied then use the merge tools of the rcs to merge in the changes against my customized version.