No solid roadmap for this, but its on the list, I’m wary of causing issues for people using the plugin with custom styles who have replaced the default stylesheet though.
Okay, no problem.
I figure if someone upgrades the plugin that changes the enqueuing, you could always print out a notice at the top of the admin panel saying that the code has changed and to update their remove_action code.
If they are already replacing the default stylesheet, then their level of expertise pretty much says that they have enough knowledge to update that piece of code.
You could also offer to run a script to rewrite the functions php file using a little regex and something like this:
http://stackoverflow.com/questions/11146626/editing-a-php-file-with-another-php-file-using-fwrite
thanks. I wouldn’t want to be responsible for a script editing a theme file on sites though – I can imagine that would generate a fair amount of blowback from people running certain security plugins.
I am one of those guys that would be upset! Not that i am not knowledgable in that arena, it is the inconvenience to have too when i did not make the request. Furthermore, when you have clients doing their own updating who is not inclined with the know how, they contact me, then i have to charge them more, when after all i was the one who recommended the plugin. Creates too many problems on a already functioning not broken plugin.
Salty, sorry you’re upset about this.
I just want to make sure that my proactive changes won’t get overwritten in the next release of the plugin.
It’s not the end of the world to stop updating my local copy of the plugin or to plan a reasonable schedule of maintaining this change on my sites. I’m just trying to keep ahead of the deprecated core WP code and make my sites future forward compatible meanwhile taking on any benefits that come from future upgrades on the plugin.
Maybe there’s a way to incorporate both implementations based on which call is made to deactivate?
