Where’d all the hooks go? (EE2)

Tim, I think that is the problem, there isn’t another known way to do this.

If you use the publish_form_channel_preferences($data) hook and var_dump that $data, I believe it shows you a list of fields loaded for that page, so you might be able to remove fields, but adding additional ones before the page load… there isn’t a way to do it, unless the dev are withholding some magical recipe.

I would love to also know what the developers recommend as a non-hack way to do this.

Hey I’m also having issues with hooks - I’m simply trying to put a button on the member list page that calls a function (that outputs a csv) - what extension hook could I use for this? Or is there a better way? Surely its a pretty simple thing to do

I’ve started to just use accessories and jQuery to add custom markup to the CP:

function set_sections()
    {
        $this->EE->load->library('javascript');

        //hide your accessory tab
        $this->EE->javascript->output('$(".my_accessory_short_name_acc").parent().hide();');
        
        if ($this->EE->input->get_post('C') == 'members' && $this->EE->input->get_post('M') == 'view_all_members')
        {
            $this->EE->javascript->output('
                /* do your changes here */
            ');
        }
    }

I have to say that I “upgraded” one site to EE 2…. and I seriously think that I won’t be doing any other sites for a long long time. Personally, I find that using the new control panel to be a huge time waster. It’s taking more clicks to get around to the areas that were clearly visible in EE 1.6._. Then all my templates… things that don’t work… lack of a gallery… what to do with all those images in the 1.6._ gallery? So much “wrong” with this upgrade…. I just don’t see the benefit of wasting so much time upgrading… and for what?

Too bad. I thought this would have been a good step forward. But if the step is this “painful”…. what really is the use?

Thanks for the good times with 1.6._.

otto

Like I said earlier, if “final” is added to various places, EllisLab needs to seriously think about what they’re doing and add some hooks into key placees. For instance, my Custom System Messages extension fixes a serious problem with a, how should I say it, craptastic and lazy way of handling ALL success and error messages. Please don’t take this and other means of extending EE away from us.

Please don’t take this and other means of extending EE away from us.

+1. At least not without alternative ways to do it.

I’ve used the session_start hook with success to add additional functionality into EE which could not have been done with regular hooks. I have already created a feature request for a better way of extending core classes but for now this is all we have.

Adding a final would definitively be a step in the wrong direction here. We need to extend core classes, you may not like it, but it’s sometimes a requirement.

EllisLabs adding final to some classes is a good idea. Inheritance is not the way to go to achieve these modifications to EE. If you were using CodeIgniter and had complete control over the usage and implementation of all code then maybe, but in the case of EE you are going to run into many people breaking other people’s code and causing a support nightmare.

The best solution is for Ellislabs to add more hooks and get rid of the double call to call_user_func_array() for every hook call. That is one of the slowest function calls in PHP and it is called 2 times everytime a hook is called.

Are we currently seeing a support nightmare because of this? People are using inheritance today … you could say the same about hooks.

I think inheritance is vital, but of course it needs to be handled correctly. For instance, EE could provide a system where addons could “override” a core class and then, it it took control over that process, it could make sure there was maximum one override per class.

I think inheritance is vital, but of course it needs to be handled correctly. For instance, EE could provide a system where addons could “override” a core class and then, it it took control over that process, it could make sure there was maximum one override per class.

Just as they do with the Extension “priority” property, developers would just start doing that to make sure that their add-on was the super-addon and that no other add-on would interfere with what it wanted to do.

I’m approaching this from a position of building a specific website - solving a specific case - which means having the possibility to extend core classes, to solve stuff that cannot be solved otherwise.

As we say here in Norway; don’t paint the devil on the wall 😉 .. if you get my point.

Inheritance is not the end all be all means of modifying and extending code in a OO system. Delegation and notifications/callbacks/hooks are usaully better than inheritance for large systems with lots of third party code/plugins.

Hi Derek,

It seems that this discussion about adding “final” declarations is in many ways similar to discussion about “show_full_control_panel_end” hook. In general, both discussions are superficial and unproductive. Developers are saying: “Don’t take away from us our beloved ways of extending EE; these ways are essential in context of our projects”. To this EllisLab people answer: “These ways of extending EE are dangerous; they break things, they generate unneeded support requests, so no more creativity of this kind will be allowed”.

It seems that no party in this discussion will convince the other party. In some sense both sides are right: some ways of extending EE really can break things, but, on the other hand, these same ways are essential for some projects. In some sense EllisLab has upper hand in this discussion - they decide what to introduce and what not to introduce into EE. But significant restrictions on how EE can be extended in the end will lead to the Wiki article “How to make EE2.x as flexible as EE1.x” being written and many respected EE developers doing massive search/replace in EE core files upon each EE installation. Such guerilla warfare is not what either EllisLab or EE developers need.

What both EllisLab and developers need is creative approach to those ways of extending EE which might interfere with EE functionality or with functionality of other add-ons. Perhaps it could be proposed that those dangerous ways of extending EE could be enabled conditionally, i.e. disabled by default but could be enabled by by site-admin perhaps by changing some values in site’s config. Alternatively, or in addition to it upon installation of each extension which uses those dangerous ways an alert might be displayed informing users that something might break. Also such extensions can be displayed in other color, e.g. in red. There could be an option or button to disable all such extensions etc. And when something breaks support stuff can always ask a user either to disable all extensions or to disable those dangerous ones.

Simply removing such ways to extend EE as using “show_full_control_panel_end” hook or extending EE classes is a solution too crude for EE developers. There is much creativity which can be displayed in seeking solution satisfactory for both Ellis Lab and EE developers. Let’s be creative.

Well put, Laisvunas.

Inheritance is not the end all be all means of modifying and extending code in a OO system. Delegation and notifications/callbacks/hooks are usaully better than inheritance for large systems with lots of third party code/plugins.

There is no replacement for inheritance. You can’t have a hook on every line (and in addition passing every conceivable piece of data and using the return values).

Personally I’d be happy just to have the option to extend core classes - it doesn’t even have to be bundled like addons are - just the possibility to extend the core on a project where it is needed, without doing an actual core hack.