As we found out, the editor loads correctly after clearing the cache, it is likely that the browser is caching "outdated" or "faulty resources" (JS/CSS files of the editor).
Since I have this issue accessing the rei3 portal directly (by ip address; as well as via the nginx reverse proxy manager, I did not relate this to a possible prtoblem with the reverse proxy. But I wanted to look deeper into potential caching issues, The proxy could encourage this if it does not allow cache control headers to be passed on cleanly. I added the following to the proxy settings: (timeout was set before already)
proxy_send_timeout 12h;
proxy_read_timeout 12h;
proxy_hide_header Cache-Control;
proxy_hide_header ETag;
add_header Cache-Control no-store;
This makes the portal noticebly slower, but so far, I haven't been able to forcefully cause any loading issue.
I'll keep testing, but maybe that is something worth to investigate?
Edit:
Now added the following to the reverse proxy
location ~* \.(?:css|js|jpg|jpeg|gif|png|woff2?|eot|ttf|otf|svg)$ {
expires 12h;
add_header Cache-Control "public";
access_log off;
}
etag on;
add_header Last-Modified $date_gmt;
add_header Cache-Control "must-revalidate, public";
# HTML
location ~* \.html$ {
add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate";
add_header Pragma "no-cache";
expires off;
}
# API-Routen
location /api/ {
add_header Cache-Control "no-store";
add_header Pragma "no-cache";
}
The html part is probably unnecessary?
