-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to override Decidim core logic #93
Comments
As @sinaeftekhar is doing this right now, I think he can also write some docs about this after he finishes with the task. |
We have a few lines here: https://docs.decidim.org/en/customize/code/ - but of course we should improve it much more! Specially now that we have lots of real world examples.
Sometime ago I found this spec for tackling this same problem. |
I use this kind of approach to keep track of changes. I'd recommend to document that as well as a recomendation if you want to override things. I'd gladly contribute to this piece of documentation once started i you want. |
This has been already implemented by @sinaeftekhar through decidim/decidim#9325. The page is live at: This was what we needed for our own use, so I'll close this issue. If anyone wants to add to that or make some further guidance, feel free to contribute to that page! |
Many times we need to do some small changes to Decidim logic within the instances. E.g. removing the steps from proposal creation, adding new fields to admin forms, making some required field optional, etc.
Decidim core logic can be overridden in few different ways within an instance:
Both are valid and fine ways but they have their own benefits and disadvantages.
For the first one, the advantage is that it's rather easy to do this and you can get it done quickly what you need to accomplish. The disadvantage is that after you upgrade Decidim, you need to keep all these files in sync with the core updates.
For the second one, the advantage is that it is easier to keep these changes in sync with core updates than in the first approach. The disadvantage is that you need to learn about monkey patching, concerns (and
include
blocks), initializers, initialization order, etc.Our suggestion would be to document both of these methods and start with the first approach. Once accomplised what needs to be accomplished using the first approach, convert it to the "better" way, i.e. the second approach.
The text was updated successfully, but these errors were encountered: