Re: One click upgrade
Reply #2 –
My thoughts in general are dropping file edits is a bad idea. Unnecessary restrictions to what can be done so people will just have to resort to other patching tools. You already have one and it works. You already announce on your mods if they make edits or not so people can rate the value / evil of mods and make their own choice.
Re: One click upgrade
Reply #4 –
I understand the theoretical advantages and the goal. I'm not convinced how practicable it really is though. No matter what you do mods will be written and then obsoleted by updates to the forum software. Hooks will change. Database and internal data structures will change. Themes will change. And so on.
Some forums will depend on those mods but the author will have moved on. Those forums will then still be unable to update because they will lose the mods if they do. The same situation as today as anyone could update if they were willing to live without the mods. Sure you can say "but the mods are self contained so it will be easier to update them". Maybe, maybe not. If you're not a programmer it really doesn't matter as it's all opaque to you anyway and you rely one someone else to do it no matter how it was done originally. If you are a programmer you can look at the mod and see the changes it applied and probably not really face much difference in updating it either way. The larger challenge is the non-programmer forum owner finding a programmer interested in helping out, especially for the cost the forum owner is willing to pay which in may cases for a free forum software will be pretty close zero.
And the disadvantages of doing it via hooks and triggers and such is not zero either. Options are limited no matter how hard you try to make the hooks universal. Often even if it can be done it will be done in a less efficient way. Extra database calls to look up which hooks are in use. Extra database calls in the mods themselves that would have been better combined with calls already made in the base code. Extra conditionals around hooks that may or may not be in use. Copying of whole functions just to make a small change to how the function performs. The list could go on.
I've also discussed in the other thread the problem of changes that break mods not being obvious at update time. Changes to the global variables, the passed in or returned variables, serialization formats, namespaces, etc. can all break mods yet at update there is no indication that anything that affects the mod has happened. All kinds of odd behavior and lingering bugs can result.
I once briefly tried to use wordpress. A zillion mods exist for it with various hooks to facilitate them. It was a nightmare though because wordpress did not commit to any given API/ABI etc so each new release would break many mods. The actively supported mods would get updated fairly quickly but many would take much longer. You could wait around for all the mods to declare they supported the new version, drop mods that didn't and update, or update hoping the mods would work with no real idea of whether they would or not because you didn't know what they relied on what was were changed in the latest update.
I've already had mods that didn't do code edits broken by minor point releases of ElkArte because you changed internal serialization and there was no evidence anything would break until I updated and noticed the odd behavior. And this was just a maintenance release 1.0.X not 1.X or X.0. It didn't help win me over to magic of hooks for maintainability. With no stable API/ABI that just doesn't exist
That last paragraph is just to give a specific example for ElkArte. It's not a complaint or judgement. I think you all are doing great work here and I really appreciate it.
Updates to pretty much any software causes problems with mods/add ons. Fortunately with open source software it's usually fixable. However it does seem projects like to make it harder than necessary through arbitrary restrictions and removal of perfectly good functionality. Like code edits.
This overall post is to give a counter to the desire to eliminate code edits. I honestly don't see the big win from doing that especially given you have a pretty good diff engine to deal with it already. In the end it's your software and you can do what you want with it though.