Renaming of hook

Beta
#1

Hi,

I’ve relied on hooks in the theme a lot. I believe the cornerstone-site-body hook in /cornerstone/includes/classes/common/class-front-end.php is renamed to cornerstone-site. Hence, a call to wp_enqueue_script( 'x-modals', get_stylesheet_directory_uri() . '/js/site/x-modals-extend.js', array('jquery', 'cornerstone-site') ); won’t work anymore. Easy to fix for me, but might not be for everyone. I’ve shared the snippet in this script and it has been referenced by support-staff a few times, so there may be more people around using this hook.

May I suggest to provide a backwards compatible way of renaming hooks, so scripts out there continue to work? Saves support of lot of potential questions :wink:

#2

Thanks for mentioning this. There isn’t really a straightforward way to alias that, so I will rename it back to cornerstone-site-body. We changed it because the head and body files were consolidated into one file, so the distinction wasn’t needed internally anymore. Good point here though, whenever possible it’s better if we avoid requiring people to make code changes. I’m sorry you’ll have to make that adjustment one more time after the release.

#3

Renaming the filter in my own scripts isn’t that big of a problem; that’s what beta-testing is for :grinning:

I can totally understand the wish to rename a hook if the name of the hook no longer represents the actual script/file structure. But wouldn’t there be a way to go ahead with renaming the files and using do_action() to preserve backwards compatibility?

#4

It’s no big deal - we’ll just leave it as body. We couldn’t use do_action in this case because this isn’t actually a hook in the traditional WordPress sense. It’s a name of a registered script, which in your case is mentioned as a dependency - this tells your script to wait until the Cornerstone asset it already loaded.

I think the best course of action is to simply leave it with the original name. That still makes sense considering it loads in the body. Thanks again for mentioning this! I’m sure you just saved us a few support tickets, and more importantly helped people’s update experience to be more seamless. :slight_smile:

#5

The WooCommerce team have an elegant approach to this, which allows you to move your architecture forward, but retain backwards compatibility. Check out the class-wc-deprecated-action-hooks.php file…

#6

That’s an interesting approach, thanks for sharing!. @Alexander this might be interesting for you and the other developers; makes maintaining hooks a lot easier.

1 Like
#7

Thanks for sharing that! This feels like a really good direction to help cleanup some of those things. We have some inconsistencies with hooks prefixed differently like cornerstone_ and cs_ which I would like to commit to a direction on.

PS: Just following up on some older threads as we get closer to the next beta. We’re about to start testing it all internally. Keep an eye out a bit later in the month.

#8

Better late then never :wink:
No worries, totally understand catching up older threads. I’m looking forward to beta-testing the new release. By the look of it, based on the status-reports, it’s going an exiting one!

If I may add one more suggestion: wouldn’t it be a good idea to document al those hooks? I do believe that would be highly appreciated by some more skilled developers and save them a LOT of time.

Good luck with the last steps towards the Beta!

#9

Thanks! Yes, it would be great if we had them all listed somewhere. Regretfully, that isn’t high on the priority list at the moment. We’ve got some smaller updates planned after the Layout Builder, then we are going to tackle a bigger update involving adding more global Theme Options. That would be a good time to revisit hook documentation because we’ll likely be adding a whole new set of them.