I can confirm the issue of missing links to CSS when accessed from a different IP. The issue can be solved on the server side not only using yarn (older approach) as well by latest yarn less approach using it during the make command to start the frontend (or as persistent env variable setting):
The shell command in the solution and other comments is not obvious for newbies when offered inline: I rewrote this a bit more explicitly with the command in seperate lines and added an explicit example as well. Nice: Setting the env variable HOST works also with the make command approach. This is important since yarn is going away. Lookup the actual commands in the Makefile if you want to avoid make.
Start frontend
HOST=[[exposed Server-IP or qualified domain name]] make frontend-start
example:
HOST=192.168.168.123 make frontend-start
This IP is listed at the end of the startup output of the frontend:
...
✅ Server-side HMR Enabled!
API server (API_PATH) is set to: http://192.168.168.123:3000
Proxying API requests from http://192.168.168.123:3000/++api++ to http://localhost:8080/Plone
🎭 Volto started at 0.0.0.0:3000 🚀
Then use this host address to open the Plone frontend on another machine in your local network:
If in Development Mode make sure you open port 3001 in the firewall on the server as well, as it is needed for some Javascript code.
Update the Plone 6 Documentation
@stevepiercy @csanahuja let's add something to the Cookieplone setup docs after Install Plone with Cookieplone — Plone Documentation v6 as #troubleshooting-developer-access-from-other-ip this could extremely useful during initial installs.
Until then I start here:
We need to add this to the Cookieplone generated docs in the project as well:
We should add this to the top level README.md generated by Cookieplone in the project folder, still mentioning just the basic start.
One more thing: In the Cookieplone generated projects ./frontend/README.md there is a section mentioning the development setup, but there using a make frontend-docker-start command.
No idea if this runs into the same issue and/or needs some further detail.
IMPORTANT: Create and add a canonical link from both the README.md pointing or redirecting to the latest hints in the docs troubleshooting section, then allowing to mention workarounds like this on a nightly update(able) basis.
A redirect offers the option to redesign the troubleshooting experience later