Frappe Docker 2023 Production setup: Password reset email link added with port 8000

All these days we were using frappe docker 2022 single server setup. My existing 2022 instance all work fine till date. Thanks to the frappe docker community.

I noticed 2023 upgrade in frappe docker which sounded to me more flexible in terms of upgrades in future especially the assets.

We setup a new production instance based on the new changes outlined in Single server Example

Everything works like a charm except for the two issues.

  1. All the links in emails such as password reset, unsubscribe email link, document link are added with port 8000 like
  2. Issuing pdf print is keeps spinning without any output. Also when Attach document print is enabled in the email, the email send ends with timeout error.
    And again port 8000 is added in the stylesheet

get_response_content = <function get_response_content at 0x7f35b1bb76d0>
href="" rel="stylesheet" type="text/css"/>\n\t\n\t\t<style>\n\t\t@media screen {\n\t.print-format-gutter {\n\t\tbackground-color: #d1d8dd;\n\t\tpadding: 30px 0px;\n\t}\n\t.print-format {\n\t\tbackground-color: white;\n\t\tborder-radius: 8px;\n\t\tmax-width: 8.3in;\n\t\tmin-height: 11.69in;\n\t\tpadding: 0.75in;\n\t\tmargin: auto;\n\t\tcolor: var(--gray-900);\n\t}\n\n\t.print-format.landscape {\n\t\tmax-width: 11.69in;\n\t\tpadding: 0.2in;\n\t}\n\n\ {\n\t\t/* padding: 15px 0px; */\n\t\tborder-bottom: 1px dashed #888;\n\t}\n\n\t/* .page-break:first-child {\n\t\tpadding-top: 0px;\n\t} */\n\n\ {\n\t\tborder-bot...

Not sure if this has something to do with treafik and related network configurations that were recently changed as part of 2023 upgrades

Help me how to get rid of the port 8000 addition in site url

Kind Regards,

can you try adding host_name key with value as base url for your site including the http or https and no trailing slash in site_config.json

I tried that with options like


Both did not work

I will try again and share the outcome

@revant_one no luck after adding host_name to site_config.json

the site config now looks like this.

This is the logic behind generating the link

1 Like

Thanks @revant_one
Are the following lines responsible for this?

if (
		not (frappe.conf.restart_supervisor_on_update or frappe.conf.restart_systemd_on_update)
		and host_name
		and not url_contains_port(host_name)
		and port
		host_name = host_name + ":" + str(port)

below are the common_site_config.json values

 "background_workers": 1,
 "db_host": "mariadb-database",
 "db_port": 3306,
 "file_watcher_port": 6787,
 "frappe_user": "frappe",
 "gunicorn_workers": 5,
 "live_reload": true,
 "rebase_on_pull": false,
 "redis_cache": "redis://redis-cache:6379",
 "redis_queue": "redis://redis-queue:6379",
 "redis_socketio": "redis://redis-socketio:6379",
 "restart_supervisor_on_update": false,
 "restart_systemd_on_update": false,
 "serve_default_site": true,
 "shallow_clone": true,
 "socketio_port": 9000,
 "use_redis_auth": false,
 "webserver_port": 8000

2022 common_site_config.json is looking like below

	"db_host": "mariadb-database",
	"db_port": 3306,
	"redis_cache": "redis://redis:6379/0",
	"redis_queue": "redis://redis:6379/1",
	"redis_socketio": "redis://redis:6379/2",
	"socketio_port": 9000

will removing the two params from the config file solve the problem ?
“restart_supervisor_on_update”: false,
“restart_systemd_on_update”: false,

Kind Regards,

you can copy your old configs and they should work.

the difference is because now sites directory is specified as VOLUME during image build. It has the default generated common_site_config.json whereas in old setup the volumes were blank and these files were generated from no base config.

check the difference in PWD config and your setup to debug further.

I think copying old configs over should work.

1 Like

Thanks @revant_one,
Finally it worked,
I updated these two params to true and left others as it is.
“restart_supervisor_on_update”: true,
“restart_systemd_on_update”: true,

However I will refer to pwd as well.
But is this a global issue or only happened to me

What is the impact on making these two params true?. Can we root cause?

Anyways, all the time as usual, @revant_one is coming for rescue :slight_smile: . Most important thing is the direction you give. Commendable.

Kind Regards,

1 Like

These keys won’t be used in containers. bench update is not used in containers. We just do bench --site all migrate after the new app code is replaced by updated image/containers.

1 Like

Then in that case we can remove these two fields as part of standard single sever setup, isn’t it?. Can we expect this as part of next update? or if you let me know where to make the change i can send a PR.

for kubernetes it mounts blank volume, it only creates whatever is executed during configuration.

I really don’t know why setting those values solved pdf rendering problem!

at this point just echo {} into common_site_config.json

change Containerfile for production and custom and send PR

Sure, I will do.

Thanks @revant_one for fixing it. I missed your last line

at this point just echo {} into common_site_config.json

I was under impression to make the two field defaulted to true. Looking into your change, now i understood.

Anyways thanks for doing it yourself and sorry for not sending a PR :frowning: