So what do you do in this senario when dependent site functionality is not working correctly? Do you (1) patch the plugin or customize it, or (2) replace it?
The right answer is (2). The plugin is out of date is isn't working correctly, it needs to be removed and all dependent code updated to use something that does work.
I did (1) due to timing. I put in fixes into the plugin, added some clean up code to fix the issues. The fixes were very narrow to the problem scope. However, I still felt dirty.
I realized, in general, I don't ever want to do this. Sure, sometimes you might to just need to get the job done, I've been there. However, the "module" should be self contained and untouched. The module should be used, not embedded in your solution. You need to be able to update it and remove it if needed. If there is truly an issue in the plugin, open a bug on the project page, submit a patch and get the next release. Otherwise, fix the problem outside the module.
These are general problems in Java as well (and everywhere else). We download source JARs, add them to our projects, and then we customize it. Those base JARs are also released with updates, but the base remains.
I then thought, how is this prevented, why don't people update libraries in their projects? Because it's talked about before hand and the "risk" factor is involved. Talking about this out load with senior folks on a project, or with your project manager, and worry will soon come. It's nobody's decision but technical folk to change something like this. Don't involve people who should just be users in the discussion. You will get talked out of bettering your changes, or simply overruled because the impact will seem high and too risky, verses doing the right thing for the long term.
To summarize, don't customize your libraries being used in your projects. Update them regularly or replace them when needed. Seems like simple advice, but I haven't seen it done well in any projects I've worked on.