ChiliProject is not maintained anymore.
Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and
we urge all existing users to migrate their data to a maintained
system, e.g. Redmine. We will
provide a migration script later. In the meantime, you can use the
instructions by
Christian Daehn.
Forums » Discuss »
Implementing ChiliProject with lots of customizations
Added by Ryan Briones at 2011-06-13 02:41 pm
I've got a highly customized implementation of ChiliProject. We're getting to the point where it's hard to only extend using plugins. I wonder how seasoned ChiliProject/Redmine users do large implementations? Do you stick to 100% plugins or resort to changing core code in app/ lib/ etc?
My biggest concern so far has been overriding views. I've hobbled along by creating "overriding" views in vendor/plugins/*/app/views, but this becomes unmaintainable as updates in app/views don't get overridden and not seen.
Thoughts?
If you override views in plugins, you indeed have to make sure they are still uptodate when updating, that's why there are view hooks provided, which work well if you only have to add things. If the hooks work for you but you'd need more, please open tickets for them :-)
Anyway, regarding core vs. plugins, I personally do have a few things I have modified in core that I keep for my installations (for various reasons), what I do for those is a git repository where I have a branch with my modifications and I pull the "official" ChiliProject code in every so often. Works well for now, it's a little more work on each update though, as you might need to verify everything still works as expected and there are no merge conflicts.
It depends. If the customization is more of an added feature(s), then I try to do it in a plugin. If it is mostly about a Model, then I do it in a plugin using a patch (Ruby/module patch).
If the customization is more of a change how something works, a view change, or a controller change; then I'll typically modify the core code in a separate branch. Over the long term, I intend to take the useful customizations and add them to ChiliProject itself so that everyone can use them (you might see me mention that I have to "extract a feature", this is why).
One change I'm trying to do little by little is to split up methods and views into smaller ones (e.g. 1 large vs 5 small methods). This will make it easier to a plugin to hook into the core and modify just that one part.
Let us know if you have any other questions or thoughts. I've been customizing ChiliProject and Redmine for almost 4 years now and am happy with the process.
Eric Davis