Trying to set up a Progressive web app with phoenix and having trouble with the manifest json file in production. All other static asset files work in production. I have added the manifest json file to the endpoint.ex in the static plug
plug Plug.Static, at: "/", from: :jroo, gzip: true, only: ~w(css fonts images js favicon.ico robots.txt manifest.json)
my manifest json file is in assets > static > manifest.json and it all works locally. I deploy all mix commands with MIX_ENV=production. if I do https://my_host/manifest.json on production. the file is served and I can see its contents. However, when I link to static_path(@conn, “/manifest.json”) in the HTML the network tab in the browser shows 404 for /manifest-16d6ca669c7546ffe8f0fa910c7b3f6d.json?vsn=d. Not sure where I am going wrong.
mix phx.digest right before starting production or releasing?
Yea. I use the elixir deploy for google app engine so all that is handled
Hm…seems that I have the same problem in 2020. Exactly the same. The manifest file is GETable in dev env, but when run in production the file is missing (from web browser perspective. It is in filesystem, in priv/static directory).
I’m running my instance with:
npm run deploy --prefix ./assets; mix phx.digest; MIX_ENV=prod iex -S mix phx.server
and the file is missing on GET. The endpoint has been modified by me to include the file (in my case “manifest.webmanifest”):
From git grep:
lib/XYZ_web/endpoint.ex: only: ~w(css fonts images js favicon.ico robots.txt manifest.webmanifest)
All other files (in / or in subdirs of / are working correctly in dev and in production).
In addition, I’m loading the file using:
<link rel="manifest" href="<%= Routes.static_path(@conn, "/manifest.webmanifest") %>"/>
and I’m behind nginx.
What I’m missing?
Hello and welcome,
MIX_ENV=prod mix phx.digest
Tried that. No change. Tried also “only_matching” - no change.
This is working, when the manifest is in subdirectory…but that isn’t the best option I think (especially when you need to put the url to the icon).
OK, solved: I’ve found out that using files without this hash in name works, so I’ve used “only_matching” (correctly this time) and that worked!