I have tried the following, let’s try a silly example:
However, this is just seems to have effect on the public sites such as the login page:
but nothing is affecting the coloring of the desk (after login):
I have also tried to change the app from “frappe” to “erpnext” in the custom website theme setting:
no ball
That’s working as intended. The website theme affects public-facing webpages but not the desk. To change the desk, you need to have a custom app with css defined in hooks.py.
Is there an example for that (v13)?
The documentation explains how to set up hooks for including js/css in desk pages:
https://frappeframework.com/docs/v13/user/en/python-api/hooks#javascript-css-assets
Not working…
I did create a custom app, I did install it to site.
I did change the hooks.py to this (of the custom app):
I did uncomment those, not sure if they’re needed:
Added the following
I did bench clear-cache and the other one for website clear cache.
I did bench restart…
Nothing, nothing changed in Desk.
And oh, the watcher is detecting change in the hooks every time I change a line there.
I had to do bench build… very slow to see changes, is there a faster way like an auto hot reload mode for css? :-/
Hmm…on a development server, you shouldn’t need to run a build. Could it be your browser that’s caching?
I am not sure if I am on a development server honestly, It was a production vm at first, but then I added developer_mode: 1 to site config and killed all ports and run bench start.
I thought this is enough to make it run as “Dev mode”. Did I miss something?
It’s a good question, and the terminology is a bit confusing here. In casual use, “Dev Mode” can refer to two different things:
the setting in your site_config.json file (developer_mode). When developer_mode is false, your customizations are limited to your instances database. Setting it to true will change the behavior of frappe, allowing you to make certain kinds of changes that are reflected in the source itself. The main example of this is doctype definition .json files. You can always edit these files from the command line, of course, but setting development_mode true allows you to edit these json files from the web interface.
“development servers” versus “production servers”, which aren’t different in terms of frappe’s internal behavior at all but instead describe two external layers: process automation (via supervisor) and reverse proxy (via nginix). If you ran bench start and are accessing your site via a port (8000), I suspect you’re effectively on a development server even if nginx and supervisor are running in the background. You could try turning off both those services to see if it makes a difference, but I doubt it would.
To check what the issue is, you could always try clearing your browser cache or loading from a different browser. If it’s still not updating, it’s possible that supervisor is interfering.
I am using 8000 port, but it’s not acting as “development server” per se.
For example, I always have to run sudo supervisorctl stop all because I can do bench start. Hotreloading rarely works.
I don’t think it’s a browser cache issue because it works after I do build.
That’s odd. I don’t completely understand how werkzeug (bench start) handles routing differently than supervisor+webpack, but I wonder if your site is serving raw or “built” css/js assets. It might be worth checking in your browser’s network info. In either case, I’m surprised it makes a difference since your custom css file here presumably isn’t getting built anyway, since it hasn’t been added to any webpack manifest.
It’s not surprising to me that you need to stop supervisor’s services to run bench start, since both programs would be otherwise competing for the same http ports. I’m more surprised that you’re having problems with hotloading, especially for python files. The watcher should be picking those up. For css/js, it shouldn’t make a difference, as I would have thought that no compilation is being done, but perhaps there’s something else going on.
I know some people had problems with hot reloading on Windows machines, related somehow to filesystem events not triggering in the same way they do on linux, but I’ve not run into the problem before on linux.
I am running it on virtualbox, ubuntu.
I just booted up my development instance to test out what we were discussing. A few takeaways:
bench build command to see the changes reflected in your site.bench build command. Sometimes this took a little bit of extra effort, convincing the browser to ignore its own cached files.This worked on both v13 and v14 for me with my setup (Ubuntu through WSL, Opera), but results may differ on other filesystems/browsers.
Another nice observation: I’m playing with v14, and the new build system is very slickly integrated. Changes to bundled js/css are immediately noticed, the files are automatically rebuilt, and the page is reloaded.