Where’d all the hooks go? (EE2)

tyler.egeto,

Hooks have been added over time from the very first beta but yes you are right there are less. A lot of extensions for EE are now not needed for EE2.x as the functionality already exists.

Are these your own extensions? What was there functionality and what hooks did they originally use?

I have the same problem, at present there is a distinct lack of hooks for EE2 and this makes it impossible for us to upgrade a number of client sites that we are working on. I really don’t understand why you would ever want to remove hooks… if anything there was demand for more hooks in EE1 to give developers even more flexibility in how they work with the CMS.

I was kind of hoping that the release of 2.1 would see these hooks re-instated but this obviously hasn’t happened and I’d like to know from EllisLab how they expect developers to migrate extensions which rely on these now non existant hooks?

I was really expecting the full complement of hooks for the 2.1 release as well. Are there plans to get them back in there? Is the rationale really that EE2 has every bit of functionality that any developer could have imagined using those missing hooks?

I really want to adopt EE2 fully, but it still seems very beta to me :-(

Since EE2 has an MVC architecture, you can actually extend many parts of the core such as the models and controllers and avoid hooks altogether. Have you done a var_dump of $this->EE when you are on the Publish or Edit page? It’s the controller for each page, so you have access to all the class variables and methods in that controller. Due to how some of the core code is written with 800+ line functions, it can be cumbersome and difficult to maintain if you extend one of those functions. I really wish the core code was modularized a bit, and took advantage of more private functions to break up those ridiculously long methods.

With that said, the only hook I’m missing is the show_full_control_panel_end. Building an Accessory just to modify some HTML rendering, with freaking jQuery no less, is not a good solution.

I don’t think all the hooks should be thrown back in immediately. Give it some time and slowly add them back as they are needed. You can work around a lot of the missing hooks, however, there are a few that tons of add-ons use, such as show_full_control_panel_end, that really can’t be worked around in any sane way.

Hi John, thanks for your reply.

The functionality of our extensions are definitely not now in EE2. We’ve upgrade a number of extensions/plugins already, but we have some major ones that are now impossible. The hooks in this case we were using and no longer exist are: publish_form_start and publish_form_end. Also publish_form_entry_data, which still exists, but has changed in a way to break what we were doing.

Basically we need to be able to modify the publish form. With publish_form_entry_data we were adding additional fields to the page, but this no longer works as they are now controlled by the channel_model.get_channel_fields, and we can’t overwrite/modify this at any point. (The Gypsy extension is a good example)

Obviously systems change with a major version release like this, but its a serious issue for us. Switching the site to use a different implementation would be a major rewrite of several sites.

Any insight workarounds? We’ve implemented a solution on one site, but it meant modifying the EE core, which we don’t want to do for obvious reasons.

tyler, I’ve ported Gypsy, here is how I worked around it:

Use this hook:

function publish_form_channel_preferences($data)
    {
        if ($this->EE->extensions->last_call)
        {
            $data = $this->EE->extensions->last_call;
        }
        
        // Time to get creative...
        require 'libraries/channel_model.php';
        $this->EE->channel_model = new Drifter_Channel_Model;
        
        return $data;
    }

channel_model.php is extending Channel_model, and you override the get_channel_fields method:

<?php 

class Drifter_Channel_Model extends Channel_model 
{
    /**
     * Get Channel Fields
     *
     * Returns field information
     *
     * @access  public
     * @param   int
     * @return  mixed
     */
    function get_channel_fields($field_group, $fields = array())
    {
        if (count($fields) > 0)
        {
            $fields = ', '. implode(',', $fields);
        }
        else
        {
            $fields = '';
        }
        
        $channel_id = $this->input->get_post('channel_id');
        
        $query = DO SOMETHING
        
        return $query;
    }
}

See, just need to get creative 😉

(btw, I’ll be releasing this in the next week or so)

Thanks for the solution litzinger!

That will allow us to work around that issue. Thanks!

I’m still quite concerned about the missing hooks however, and so are others as posted here.

The hooks mentioned in this thread so far aren’t necessary. You can modify the Publish form without those hooks, though you will use different methods and perhaps different add-ons than you did in 1.x. Any hook that required you to find and replace specific markup in EE for instance is gone, and good riddance, honestly.

With that said, the only hook I’m missing is the show_full_control_panel_end. Building an Accessory just to modify some HTML rendering, with freaking jQuery no less, is not a good solution.

I agree, but show_full_control_panel_end isn’t really the best solution either, nor would any solution that reads in the full output expecting you to modify that string.

It’s also important to note that we did not make any of these change arbitrarily, nor without giving developers ample time to modify their work and give us feedback, dating back to the developer preview in spring of last year, and extending to the general public during our seven month beta. Quite a few extensions that we didn’t plan on using in 2.x made it in from these conversations.

litzinger hits the nail on the head: the old ways need to be rethought, as this is a brand new control panel, from the ground up. Extension hooks rely on the operation and logic of the surrounding code, and therefore they are quite version specific. If it helps, think of the control panels as two different products that share similar libraries. If after learning the new APIs and extension hooks you find that some needs are not being met, 2.x is a young product, there is plenty of room and time to continue to mature for third party development.

But it would be a terrible mistake to hack 2.x to awkwardly force removed 1.x extension hooks to work; it would hinder the growth of 2.x and undoubtedly cause support problems both for EllisLab and for third party developers.

Derek, what about an option to hide an accessory tab completely (or does this already exist and I’m missing something?). My beef with using an Accessory to replace show_full_control_panel_end is that the tab is present even if I don’t have any content in it.

Also, is there a way to extend/override some of the theme view files from within an add-on? That could be an easy way to modify the CP without touching the core. If I had an add-on the following directory structure it would override the CP theme file:

myaddon – views —- themes —— content ——– edit.php

I could see this getting abused though, but would be very handy.

I’ve seen the extension trick above a few times now. So I’d like to throw out a word of caution.

Be extra careful when you extend EE in creative ways outside of the documented realm. When an add-on modifies a view or a core object, it effectively changes it for the entire application. Any code that runs after that add-on will need to work with these changes. Not only core code, but also other add-ons. So in the above example, if another extension attempts to use the same trick, one of the two extensions will fail. And finding the cause will not always be easy.

Additionally, with our move away from PHP 4 we finally have the freedom to tighten up our core code to make it more robust. Part of that change will almost certainly be final declarations on core classes and reduced visibility of non-documented class variables. These will break the extension trick.

This is not meant to discourage anyone from dreaming up creative solutions. I’ve certainly enjoy a few of them; they can be quite refreshing. But they need to play nice with others. If your add-on becomes popular it will be used as a learning template by beginners - the code should reflect that.

Lastly, If you feel that a change or addition to our code will help you succeed in creating a successful add-on, then by all means get in touch with me.

Adding final declarations and not adding some popular hooks back… ouch. That is going to hurt.

Adding final declarations and not adding some popular hooks back… ouch. That is going to hurt.

I’d be more than happy to help you find a way to achieve your goals, but the proposed solutions simply don’t scale.

There’s more than one way to skin a cat, as they say.

With 2.x’s API burgeoning along with the new add-on types, I think developers are in a far better position for both their clients and the add-on market than they were in 1.x. And by extension (pun intended), so are end users.

This whole thread deals mainly with custom development, so I’ll simply move it.