Reaction Commerce Forums

Changing Site Domain Without DB Reset

Hi All,

I’ve done my best to change the default domain (localhost:3000) without much luck–I’ve exported shell-level variables, edited settings.json, you name it.

The goal is making sure that all communications with users and customers point to the correct url/email domain, i.e. emails sent with links ought to have and not http://localhost:3000/my/link.

I see that resetting the domain is possible but requires a database reset. Is there a way to reset Reaction’s domain without blowing away the entire database?

Short of that, is it possible (and practical) to import the database from backup after resetting Reaction?



Have you tried setting the ROOT_URL environment variable? Most things that reference the site URL are getting it from there - usually via Meteor.absoluteUrl()

I did–I added ‘export ROOT_URL’ both the the user’s ~/.bashrc (and ~/.bash_profile just for fun), I exported the variable prior to running the upstart script, ala:

export ROOT_URL=“"
export MAIL_URL=”"
chdir /var/www/html/market
echo $$ > /var/run/
exec sudo -u market /usr/local/bin/reaction >> /var/log/market.sys.log 2>&1
end script

I pushed forward and modified the ROOT_URL variable in settings/settings.json.

I verified that the environment variables were present in the user’s profile by logging in and executing the ‘env’ command.

Sounds like something isn’t right somewhere. How are you deploying this?

Linux box w/ apache proxy if that helps…

I get this error:

ERROR Reaction: Cannot read property ‘split’ of null

“A Linux box” isn’t really enough info for me to give you any useful recommendations. Did you use the officially supported setup/deployment methods from the docs? If you’re not using Docker (the recommended deployment method), did you manually go through all of the dependency installs and build steps? If so, what specifically did you do?

Generally, we recommend you use the preconfigured Docker tools provided with the app because there are a lot of variables to consider when rolling your own deployment and I unfortunately won’t be able to offer you too much help with a custom setup.

Hi Jeremy,

I’m running Ubuntu 14.04.5 LTS. I followed the instructions found on Reaction’s site here:

That is,

install CLI

npm install -g reaction-cli

clone Reaction, install NPM dependencies

reaction init

move into the new app directory

cd reaction

start Reaction



reaction run

Those are the directions for setting up a local development environment. That’s not meant for a production deployment.

If you’re trying to deploy on a server on the public internet, you want to do something like this:

And for a slightly more simplified copy/paste version of that…

Just note that Reaction now runs on port 3000 in the container (the docs in the first link still say 80:80, but it should be 80:3000 now)

Hi Jeremy,

We’re almost there!

Under a docker-compose environment using Reaction behind an nginx proxy with lets-encrypt, the site comes up as a white screen. After what seems to be about three minutes or so the products will populate.

The nearest thing to error messages is this from Chromium and Firefox:

---- Begin Chrome Message ----
WebSocket connection to ‘wss://market.[mydomain].com/sockjs/119/246mex5f/websocket’ failed: Error during WebSocket handshake: Unexpected response code: 301
WrappedWebSocket @ VM221:35
C.websocket @ e78a72c….js?meteor_js_resource=true:113
C._try_next_protocol @ e78a72c….js?meteor_js_resource=true:113
C._didClose @ e78a72c….js?meteor_js_resource=true:113
C.o._ir.onfinish @ e78a72c….js?meteor_js_resource=true:113
i.emit @ e78a72c….js?meteor_js_resource=true:113
i.onfinish @ e78a72c….js?meteor_js_resource=true:113
i.emit @ e78a72c….js?meteor_js_resource=true:113
s.xhr.onreadystatechange @ e78a72c….js?meteor_js_resource=true:113
---- End Chrome Message —

And this from Firefox:

---- Begin Firefox Message ----
The connection to wss://market.[my-domain].com/sockjs/397/43rb21w0/websocket was interrupted while the page was loading.

---- End Firefox Message

Here is my lets-encrypt config:

---- Begin lets-encrypt ----
image: jrcs/letsencrypt-nginx-proxy-companion:latest
container_name: lets-encrypt
- nginx-proxy
- /etc/letsencrypt/live/market.[]:/opt/certs:rw
- /var/run/docker.sock:/var/run/docker.sock:ro
---- End lets-encrypt ----

I’m of course investigating this on my own but if you’ve any clues I’m all ears.



Hi Jeremy,

I finally solved this. It is critical that nginx does not forward web sockets. jwilder/nginx-proxy has the following environment variable:

HTTPS_METHOD: “noredirect”

For those coming after me with a “wss handshake error,” the final docker-compose configuration for the nginx-proxy service is as follows:

---- Begin Confiuration ----
image: jwilder/nginx-proxy:latest
container_name: nginx-proxy
- /etc/letsencrypt/live/
- /etc/nginx/vhost.d
- /usr/share/nginx/html
- /var/run/docker.sock:/tmp/docker.sock:ro
- /etc/nginx/conf.d/my_proxy.conf:/etc/nginx/conf.d/my_proxy.conf:ro
- “80:80”
- "443:443"
HTTPS_METHOD: “noredirect”
----End Configuration ----

Hmm. I’ve been using that exact setup for a couple years now and haven’t ever gotten that error. Thanks for the update though!

Oh, you’re welcome, thank you!

In some alternate universe this may be caused by the idea that I’m on a Linode instance though, as I eluded to, I don’t put much stock in that idea.

So if it’s useful for your docs (and ultimately for others) there you go.



Maybe Linode is running you through some kind of router or load balancer that alters the request headers or something. Either way, keep us posted if you ever identify what it is. I do know I’ve never had the issue on AWS, Digital Ocean, Rackspace, or Azure when using the same Docker images, so I’m curious why that happened.

Glad you figured it out though. Thanks Cooper!