-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate wplf_{$form->ID}_* and wplf_{$forms->post_name}_* actions and filters #169
Comments
All filters from #167:
All actions:
Gathered with |
All in for getting rid of hook IDs that rely on variables. Rather have the form identifiers available as callback arguments instead. The following is a sensible approach and I think it is quite common in WP core as well:
If we cannot pass a full form object 100% of the time, I would consider using the form ID and providing a helper function similar to |
While it was a good idea at the time (#52), it's cumbersome to add new filters and actions. I think I implemented it the way I did, because I heavily dislike this, probably because I've been bitten by it more times than I can count:
I've no clue why WordPress chose to add the $accepted_args parameter, when they could've just passed all available arguments to the function like a normal person, but what is done is done and that ain't changing anytime soon. Probably some prehistoric reasons that I don't know of. I looked at call_user_func and call_user_func_array, and there's zero indication of having to know the amount of parameters.
Nevertheless, I propose that we start doing this instead of creating 3 filters / actions every time we add a new one.
I don't know if we have access to full $form post object everywhere where we have these kind of filters, if we don't, then we should just get the full post object. I don't want to do this.
I suggest that we use _deprecated_function (or create our own equivalent, because you know...) and deprecate all filters and actions that are like this. I don't want to remove them in 2.0, but I certainly don't want any new projects using them either.
Although naming things is hard, it should be pretty easy to create equivalent filters and actions that follow the new style. I wouldn't just do them without thought though, but instead make a list of all of our available actions and filters and figure out a consistent naming scheme for all of them.
v3.0 would remove the deprecated things completely. 3.0 doesn't have to include huge amounts of new features, it's just to indicate breaking changes. Practise what you preach, use semantic versioning and so on.
Pinging @rask @luizbills @ironland @libreform/maintainers and everyone else that might care.
The text was updated successfully, but these errors were encountered: