« first day (4359 days earlier)      last day (884 days later) » 

bosco
bosco
07:36
If there is no other means to achieve a specific result, would it be an egregious hack to dig a third-party hook out of $wp_filter, remove the registration, and add a new one which wraps a manual execution of the original callback with my own functionality? I've used this to enact a temporary patch under heavy restrictions a couple times before - but I have to imagine such a practice would not be considered fit for distribution in a public plugin?
 
2 hours later…
kero
kero
09:10
@bosco Usually I could avoid it by pinpointing the exact point where they add the filter, and use n+1 prio on the same hook to remove it - which feels cleaner than fiddling with $wp_filter manually
But of course this might not always be possible. I would say manually changing $wp_filter is definitely a code smell, but can be defended in code reviews because there are certainly situations where it is not easily possible to avoid it.
As for getting it published in .org repo, I have no idea. You could ask in the .org slack pluginreview channel - best with a code example
Tom J Nowell
Tom J Nowell
if you can't get a reference perhaps because it's anonymous then messing with wp_filter is the only way to my knowledge, otherwise add_action and remove_action are doable for wrapping
 
6 hours later…
bosco
bosco
14:52
@kero @TomJNowell thank you very much - I really appreciate that input :)
Tom J Nowell
Tom J Nowell
15:05
if you can avoid messing with WP global objects and do it by calling API functions it'll be more stable in the longterm
bosco
bosco
15:15
Definitely! It always felt dirty to me. One scenario was exactly as you described. I couldn't fork or modify the plugin, but I needed a reference to a class instance which was unobtainable outside of the hook's callable.
kero
kero
And: be nice and ping the devs to ask if if they can make their code more customizable. I once had an issue with a map plugin, I just could not use standard means to make make it only after opt-in (GDPR). So I had to wrap their JS file loading in some other loading. Told them in the support forum and a couple of versions later it was much more easy to integrate the plugin into opt-in solutions
bosco
bosco
15:30
Oh, definitely! I had a vaguely similar experience there where a plugin's JS in a closure would DOS the site if left to run in an open tab for many hours... My hack-around was quickly obsolete thanks to their quick patch

« first day (4359 days earlier)      last day (884 days later) »