Need help solving weird Plone 6 Volto frontend problem

Plone Support Deployment & hosting
1

I’ve installed the docker containers per Containers – Install — Plone Documentation v6.0-dev (on the Plone 6 dev-docs site install/containers/index.html) on Ubuntu 22.04 and 20.04 (and 16.04) and get the same behavior on each.

  • When I visit the site using a browser running on the same host as the containers, I'm able to access the site at localhost:3000, login, add pages, and so on.
    • (I needed to open localhost access to ports 3000 and 8080, the latter so the frontend can talk to the backend.)
  • When I visit the site using a browser running on a remote host, I can see the current version of the page being visited for a second, and then the content area is replaced by the message "The backend is not responding, due to a server timeout or a connection problem of your device. Please check our connection and try again. Thank you."
    • This happens when the browser is a current version of Chrome and Edge on a PC, and Chrome on an Android phone.
  • This same situation occurs when I have nginx proxying access to the Volto frontend. So you can visit the site at http://do.myriadicity.net to see for yourself. Give it a second for the content to change.
    • See http://do.myriadicity.net/workarounds-so-this-works for a page that I edited using the local browser session, to verify that we're actually seeing the real content in the second before the page shifts.

What the heck is going on? I would like to begin implementing a proper site, but need to resolve this before I can feel confident about building on it.

2

A further weird thing about this: a remote browser pointed at an ssh tunnel to the host (ssh do.myriadicity.net -L 3000:localhost:3000, with the browser visiting localhost:3000) has the problem also. I would expect the browser to behave like a browser running on the host local, but it behaves like the remote browser above - the content gets replaced by the "backend is not responding" message after a second or two.

Unfortunately, I can't provide a way for you investigate this access path, but it certainly seems significant, hence worth mentioning.

3

There was a recent report of what I think is a similar issue. This issue was resolved, but maybe not well enough?

Please let us know. Thank you!

4

image
image1061×67 22 KB

It seems that Volto has http://localhost:8080/Plone as apiPath.

I notice that the documentation contains this command:

docker run --name plone6-frontend --link plone6-backend:backend -e RAZZLE_API_PATH=http://localhost:8080/Plone -e RAZZLE_INTERNAL_API_PATH=http://backend:8080/Plone -d -p 3000:3000 plone/plone-frontend:latest

The RAZZLE_API_PATH env var should point to the publicly-available Plone backend domain. It will be used by the end-user browser to connect to Plone using the ++api++ traversers and special rules. So it needs to be properly adjusted to your custom case.

This would fix your "production deployment" issue.

When I visit the site using a browser running on a remote host, I can see the current version of the page being visited for a second, and then the content area is replaced by the message "The backend is not responding, due to a server timeout or a connection problem of your device. Please check our connection and try again. Thank you."

This is because there's two things happening. I assume that Volto (frontend) and Plone (backend) run on the same remote machine and you're trying to connect to them from your development machine.

Volto, when generating the HTML that gets loaded in the browser, will use the default http://localhost:8080/Plone address to connect to Plone. This will work fine. After your browser loads the HTML and the JS, Volto will start running in your browser. It will immediately try to "rehydrate" and attach React components to the loaded DOM elements. It will trigger network fetches, etc, and that's why you see the initial content (based on HTML loaded) and then an error, because the network fetch failed. It will try to connect to http://localhost:8080/Plone from your development machine. This may not work, depending on your tunneling setup.

I do my development remote all the time, it works. I tunnel ports 3000, 3001 and 8080.

5

Thanks, @tiberiuichim! I think you’ve identified the core problems. I have further to go in resolving my setup, but what you suggested led me to understand the instruction parameters better (docker run, nginx configuration, etc.) and focus my attention on what needs resolving.

I realized I can use the browser dev tools Network tracing facilities to compare what happens in working interactions, say on 6.demo.plone.org, with the non-working interactions with my install, and work backwards from there. I’m going to work on that, hopefully later today, and report back here what was needed, both in settling my problems and maybe in the instructions I was following (like the Containers section both you and I referenced). Ultimately I’ll be heading towards making a full project for my site, and experience with all this should give me a good foundation for getting that right.

Thanks for your suggestions, I think they put me on the right path, plus it’s very reassuring to know there’s helpful guidance nearby when I’m struggling to unravel something!

6

Thanks, @stevepiercy, for your attention to my question! The issue you mentioned seems more concerned with the confusion people have with two coexisting frontends, Classic and Volto, and some interoperability incongruities. (I noticed some of those incongruities, also, but don't have any concerns with them.) My issue is with configuring my servers so I can use the Volto frontend with browsers not running on the same host where the frontend and backend containers are running. There are definitely some complexities there, and the instructions could probably use some refinement. I think @tiberiuichim's response has me back on track.

7

I believe I've got my containers install working so I can fully access it via the Volto frontend from browsers not on the same host where the containers are working. It required the change @tiberiuichim mentioned and also an obscure provision for my UFW firewall configuration on the containers host, worth describing in detail.

As @tiberiuichim mentioned:

One way to indicate this would be to use RAZZLE_API_PATH=http://$HOSTNAME:8080/Plone instead of RAZZLE_API_PATH=http://localhost:8080/Plone, but this would fail mysteriously in cases where $HOSTNAME is not the fully qualified domain name. It seems like the instructions are going to require some elaboration on this point.

  1. Arranging for port 8080 on the container host to be accessible remotely requires a more complicated UFW allow command than I expected. The simple UFW command I thought would work, sudo UFW allow 8080 is not sufficient. Here's what does work: sudo ufw route allow proto tcp from any to any port 8080.
    This is derived from a suggestion in a well-informed resource for reconciling operation of UFW with containers, https://github.com/chaifeng/ufw-docker. (Sorry, I can't yet post proper links.)

As a bonus point, I found it quite helpful to use the browser developer toolkit's network call tracing facility, to see what's going on behind the scenes. I have a lot to learn about debugging container-based apps, so that provided some insight that I would normally get by watching the server log files.

I intend to file a few bug reports, including one concerning the containers documentation. I consider my problem solved, and am grateful for the help!

2 Likes