I’m in the process of upgrading multiple sites to EE2, and a number of extensions obviously need to be upgraded as well. But where’d all the extension hooks go? There are significantly less hooks now, and its making certain functionality impossible. I’m particularly talking about the publish page hooks, but others too. Several of our extensions are dependent on the missing hooks.
Do you have any suggestions of how to get around these limitations? Without them we have a number of sites stuck in EE1 land.
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.
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.
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.
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.
Could you point me in the right direction for achieving this in EE2? @Pascal, if you think @litzinger’s example is problematic, could you help me find a more stable/scalable way?
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 */ '); } }
