Customization Issues [You can't really apply overrides for UI]

After some playing around with latest V7 and following all recommendations, I felt like is not really engineered in a way that lets you apply overrides and customizations at your heart’s content.

Sure you can do some things, but not everything you like, and the best you can do is add modules on top of it, but retain everything else as is, and you work with what you’ve got and only around it. Even the simple things are very difficult to achieve. Provided you do not touch Frappe and ERPNext, and apply your customizations on a new app which is conveniently stacked at the end of the pile (meaning you have Frappe first, then ERPNext, then finally your apps loaded):

1- you cannot easily manipulate the dom with jQuery (well you can’t do that at all, the dom is frozen actually, just nobody tells you);
2- CSS rules have to be set to !important anyway, or they won’t come through and this is such a bad habit;
3- changes in assets do not result in overriding, but double loading. Say you change sounds for example… It will sure load your sounds && the original sounds as well… so wasteful;
4- even simple hooks like setting “default_mail_footer” will end up stacking a new footer in addition to the one provided with ERPNext, which is obviously not desireable. One would expect the new rule to just override the old one, not add up.

Finally, all these issues make it very inconvenient to follow the suggested approach. It’s much easier to fork ERPNext, branch your customizations and merge in master. Whenever you then update you just reapply your changes.

All in all this sounds like a dirty workflow to me, and I really hope someone just steps in and proves me wrong, so I can learn something.

All in all though… it’s a great product. I shake this tree because I like its peaches :blush:


@imapirate Best to share specific use cases and submit patches so that the customization works well for your issues.

ERPNext is a culmination of hundreds of such use cases!

1 Like

I know @rmehta you are right, I did that, hit a wall and I just wanted to make the point collaboratively, and see if it was just me unable to work out the system.

Although I think the first use cases are specific enough. Say you want to apply UI changes, something really simple:

$('a.module-section-link').css("color", "red")

You can’t do that, this won’t work. It’s been made a deliberate effort not make it work, which I think it’s worse (and there’s not error or anything helping figure things out. Why you did that?). Please don’t suggest to change CSS styles :joy: This is the simplest example I could think of to manipulate the dom and the point is that you can’t do that, can you @rmehta? And if so where can one find documentation?

What makes me pensive about your answer is the UI is possibly the single most discussed topic in this forum and so far I couldn’t find a way to do it in a systematic way in none of the topics across all versions. My hope is that you show me how simple solution is instead :slight_smile:

@imapirate That is the state of the project today. Lot more people wanting things from devs and fewer volunteers to fix these things. So hop in! :slight_smile:

Regarding UI, our own philosophy is not to customize the UI (other than the website views). We regard this as a common system that should not be tampered with. But end of the day its just HTML/CSS + bootstrap!

1 Like

I will. And I’m talking because I’m trying to learn so I can contribute. But there’s not enough documentation around so I ask here. I understand your point, although is really really questionable :sweat_smile: You make a framework that you suppose you can’t really use as such.

If so, then my original title for this topic: “Let’s get it straight, you can’t really apply overrides” is correct and clear enough. Why did you change it to a shallow generic “Customization Issues” which is really not, and according to what you say you cannot and don’t even want to allow? That’s not clear and doesn’t help I think. I think it’s shady but maybe that’s too harsh and I want to be nice :slight_smile:

Again it’s HTML + CSS && Javascript. Even the version included of bootstrap is frozen, so you cannot really say change a variable and there you go… Do you want me to provide an additional Bootstrap on top of it to do that? And that’s only for the web views? Well, then that’s in contrast with my phylosophy.

I think you shouldn’t predecide what you have to temper with or not. The system is there and is modular enough to make it possible today without other contributions, it’s just locked down on purpose. You know what I mean? Right now your statement is simply false. It’s not about making contributions, but making sure nobody can do that. You paid extra efforts to lock it down! The reality is that you deliberately freeze the dom, where making simple changes according to preference would otherwise be a chinch and wouldn’t harm anybody.

I think this part of your phylosophy is questionable and should be revised. You want to revise it @rmehta? Or at least making really clear and simple statements so people can read clear labels on the tin and decide to work with it or not. I think you should.

1 Like

There will be pros and cons for any frameworks. You have to make a decision on what you want to live with, and what you want to accomplish. This is why so many frameworks (with requisite flame wars) exist!

Dependency management is critical. If you allow a user to select whatever version of a library, you have to have all that excess baggage to deal with that option. That slows down improvements across the board. So yes - I wholeheartedly agree with this decision. If you want to do you own things for your own purposes, you’ll have to load your own library - there’s no need to put that baggage on others.

I’ve found that the main philosophy is that Frappe is a framework FOR ERPNext. I dare say that if you want to use Frappe to build apps without ERPNext, you’re making a poor decision - there are other frameworks that would serve that use case 100x better.

If you feel strongly, you can send a pull request for the community to decide, or fork!

1 Like

Alright @felix let’s put it straight as I always like: ERPNext is a fantastic product and is Frappe. I want to be part of the community and contribute to it actively. To do that I need more documentation though, which is lacking (so if you can point me to specific stuff I can learn in order to develop on this framework you are welcome and I’ll pay back in PR :blush: please). That said…

There will be pros and cons for any frameworks.

Your quote is incomplete and misleading (that’s not nice @felix). If you read it in context you realize I’m referring to the bad habit of duplicating assets which is not only against mine but in general against good development philosophy and practice. It was a way to say that, the way it is makes little if no sense at all for good develoment. I can still do it no problem, but so annoying… and can’t understand why. I didn’t mean to be a Frappe guy instead of a RoR or Laravel or anything… Sorry if that was not clear to you.

Dependency management is critical.

@felix you must be kidding. You seriously want me buy that? That is false altogether (that is not a nice thing to do). You can use whatever version of bootstrap you like and I’ll be totally fine with it. But you deliberately hardcode all your customizations in it and then freeze it to CSS, so any further customization down the line will sure be possible, but such a burden. Additionally, I can tell you did that to raise a wall and make it deliberately difficult for anybody to make changes down the road because you do provide other less files and variables and mixins for other things… but you wanted and did spend a lot of efforts to make it very difficult if not impossible to make simple changes if not by hacking the core… Which adds a considerable overhead to maintenance and can discourage lots of people doing that. Mhhh I can see a pattern now. ERPNext is designed not to be customizable. That has nothing to do with dependency management at all and stating that is not honest (that is not a nice thing to do), which makes me sad. The contrary is true: if you include a vanilla bootstrap with all less sources anybody can play with it without putting any baggage on anyone. Go figure…

I’ve found that the main philosophy is that Frappe is a framework FOR ERPNext.

I do agree with it but can’t see why you raise so many walls around. You know what? I landed here because a client really wants to use it, and that’s fine I can help them. But then he doesn’t like all that purple (in some european cultures it’s such an unfortunate color and they don’t like it for their business).

Moreover they don’t want to welcome their employees to ERPNext but to their company and I think it’s fine. After all ERPNext is just the tool, it’s the company content and business that should rule the scene. So I don’t see why I am not able to help them by customizing that welcome page with information that is relevant to them. You talk about putting baggages and that is you doing that. You claim to be heavily inspired by WordPress and WordPress does indeed come with a WordPress welcome page, but they also wholeheartedly push you to customize it to your specific needs and give you the tools to do that. You raise walls around that instead. You should get more inspiration from them.

They don’t even like the help system. They don’t think information provided is engaging or clear enough and they would like to build their own and get rid of that. Additionally, they don’t want employees to contact you directly but want them to contact the IT department instead, which will eventually contact you. That makes so much sense to me. I can’t see why they shouldn’t be able to do that. After all it’s very generic videos, information so basic that is largely unhelpful… and is not even localized. Why shouldn’t they be able to customize with an help system they find more helpful? It’s not difficult for you to do that, it’s the opposite: you pay lot’s of effort so that people is not able to do that easily and I just don’t understand why that. I can sure do it anyway, but it feels so dirty to do and makes me ask why you put so much effort making sure people can’t do that (because that’s what you do) instead of using that time and effort developing something useful for all. People should be free doing what they want, it’s just you do not want them do be free. It’s not about contributing, but you making sure nobody can contribute that way.

If you feel strongly, you can send a pull request for the community to decide, or fork!

I do want! Just please point me to more documentation as I said. Please :slight_smile:

1 Like

Making something generic takes time, its not malintent. That is the simple answer.

1 Like

I see @rmehta. Thanks for your clear answer :blush: This is really appreciated and much more satisfying than all dodging that’s written here and there. At least many other people will read this, understand and decide which direction they’re going to take, with no hair pulling and frustration. I tell you pal, there’s a lot of frustration going on running the simplest scripts: $('a.module-section-link').css("color", "red") see they are not running and having nobody tell you: “Hey man, if you plan to change the UI, then forget it… this is not gonna work. You gotta hack it”.

I found a way through it, although it’s totally not recommended, but at least I’m learning a lot and I hope I can contribute with some PR back to you :slight_smile: As I said, any further documentation or reference material to speed up learning is very welcome. I hope you can point me to something @rmehta :slight_smile:


Why join the navy when you can be a pirate!

I really like this discussion because I have been developing with flask and had to customize each small thing for my apps. That said, for the past week or so I have been diving into Frappe trying to understand how to develop with it before moving to erpnext.

I haven’t so far found a clear path of understanding. And in many aspects I share the frustration that @imapirate presents.

From the video series and the tutorial in the docs I got some understanding of the Doctypes and how to make simple implementations but I did not get an insight of the framework. It seems to me that understanding the framework is a key aspect for being able to contribute in any way but so far no documentation on that was found.

Can someone perhaps help with the understanding of Frappe and how does it work?

  1. How is the javascript integrated?
  2. What is the process for customizing the UI for a client? (I guess most people have to do that)
  3. How secure is the system? What implementations are there to avoid XSS, SQL atacks, or others? If I write my own queries using frappe.sql does the framework assures that it is valid data, for example?
  4. If I would like to contribute, say, with a PR that adds the possibility to customize the docs or the static assets (as mentioned earlier in this thread) would this kind of feature the accepted or where/how could I ask?

I’m quite excited with erpnext and frappe but also afraid/cautious as many design patterns are unusual to me.

And I have so many questions that I don’t know how or where to ask them. =]

1 Like

Ya, precisely what I thought @rmehta see that? I’m totally new to python, but if you or anybody will give me some tips to get my feet wet in a way that’s useful to get up and running quickly with frappe I’ll be glad… Would be very slow to just start learning from somewhere and then realize lots of stuff doesn’t even apply to frappe if not incidentally.

@fmorato right now I can just help with your second point. Provided I understood it correctly, there are plenty of freeze methods applied to objects which lock down the UI, so you just cannot apply modifications other than simple CSS overrides.

So you have to hack erpnext and here how to do it in a way that sucks a little less. Basically the bench works much like a git client, so you just have to use the same git workflow of the core development team to avoid nasty issues. You can start from their installation script, but beware they provide you with a shallow repo, so if you want to clone it you have to unshallow it before. After that you push to a new remote, you can call it origin, and then you make a new branch where you apply your customizations. Then you merge to master and pull back in to your erpnext installation, making sure you then reset your upstream remote to the original ones to allow seamless updates. Then you have a system which you can white label completely and adjust the way you want while still being able to receive all updates. Whenever an update touches your customizations you just reapply your changes from the custom branch you are maintaining.

About security… well I wouldn’t mind if I could dockerize the app conveniently. I figured out how make it almost work flawlessly, but there’s one thing I couldn’t yet solve, which is communication across containers (the app won’t communicate with redis instances… it’s a python issue). I’ll share what I have when I make it work (well it does for the most part but the caching), but basically docker will be a good protection layer by itself.

Please go ahead, if you have the knowledge already to make those PR I’d love to check it out and I’m sure many more, included @rmehta :slight_smile:


I think you should run bench build after making changes the UI - that might be the missing piece you are looking for (got lost in all the other comments!)

You can also add bench watch to the Procfile (in the frappe-bench) folder

Hi, did you find a way around applying the UI changes?