afaik http2 is ssl/https only… so try https://localhost:4001 - though obviously http(1) should work, but that depends on your config perhaps…
derp: Didn’t even notice the protocol. So if I put just plain localhost:4001 why is it defaulting to http not https? Is there a force https?
Isn’t localhost excluded from the “works only over https” limitation? At least that’s what I though would be the case.
1.4.0-rc.2 is out with updated plug dependencies, new Ecto 3.0 usec datetime support in our generators, as well as a few bug fixes.
To jump on the latest RC, first replace your :cowboy dependency with :plug_cowboy:
{:plug_cowboy, "~> 2.0"}
To upgrade to Cowboy 2 for HTTP2 support (which is the new default), use ~> 2.0 as above. To stay on cowboy 1, pass "~> 1.0".
Also, be sure to grab the latest rc.2 project generator:
$ mix archive.install hex phx_new 1.4.0-rc.2
Changlog below. Cheers,
–Chris
1.4.0-rc.2 (2018-10-20)
Enhancements
- [phx.new] Use Ecto 3.0RC, with
ecto_sqlin new project deps - [phx.new] Use Plug 1.7 with new
:plug_cowboydependency for cowboy adapter - [phx.gen.html|json|schema|context] Support new Ecto 3.0 usec datetime types
Bug Fixes
- [Routes] Fix regression in router compilation failing to escape plug options
- [phx.gen.json|html] Fix generator tests incorrectly encoding datetimes
- [phx.gen.cert] Fix generation of cert inside umbrella projects
21 Likes
Just for the record, I had to do mix deps.update phoenix after applying the steps for jumping to RC2. (In case you tried upgrading after taking a nap like I did 
) Afterwards, mix do deps.get, compile succeeded.
I could not get RC2 to work without plug_cowboy, and running “mix archive.install hex phx_new 1.4.0-rc.2”
returns this for me: https://gist.github.com/oldpond/ac050b79ea8590826f558c005d00c388
I am working through B5 of the phoenix book, and the book is behind this change.
The archive install error is a bug in elixir that will be fixed in the next release. The workaround is to mix archive.uninstall phx_new before running the archive.install command. As you found, B5 lags the rc.2 release, so the plug_cowboy step is needed. Thanks for bearing with us, their shouldn’t be much left to need to deal with before final release.
6 Likes
After changing {:cowboy, "~>; 1.0"} to {:plug_cowboy, "~> 2.0"}, I did mix deps.update --all and compile. This bumped cowboy to 2.5.0, cowlib to 2.6.0 and ranch to 1.6.2.
1 Like
If you are using cowboy 1, please use {:plug_cowboy, "~> 1.0"}.
3 Likes
This change is present in 1.4-rc.2 when using the generator “mix phx.new <project_name>” but still missing when using “mix phx.new.web <project_name>”.
Thanks for checking that.
I was upgrading Phoenix in an umbrella project which was originally generated with mix phx.new.web when I found that.
Was the {:jason, "~> 1.0"} dependency added to mix.exs by mix phx.new.web? If so, it could be a bug in the 1.4-rc.* phx.new.web mix task.
I’m wondering why the new onSync() callback for the presence API does not supply the updated presence object to the callback. Wouldn’t it be better to not have the callback need to depend on the object from outside the callback?
presence.onSync(() => do_something_with_presences(presence))
# vs.
presence.onSync(updated_presences => do_something_with_presences(updated_presences))
It probably makes not much difference as one needs to have the presence object at hand to attach the callback anyways, but I still prefer the latter to not need a closure and even though there is a object globally updating behind the scenes this feels like a more pure approach.
2 Likes
RC3 is out with a few deps changes now that Ecto 3.0.0 is out. To update existing RC apps, simply remove an explicit :ecto dep from your mix.exs, and update your :phoenix_ecto and :ecto_sql deps to the following:
...,
{:ecto_sql, “~> 3.0-rc”},
{:phoenix_ecto, “~> 4.0”},
Also be sure to grab the latest project generator:
$ mix archive.uninstall phx_new
$ mix archive.install hex phx_new 1.4.0-rc.3
7 Likes
To list presences, you still need the stateful object, ie presence.list(callback), so it doesn’t make since to mix and match the pure functional and instanced based APIs.
To be clear, a closure is always required in either old or new APIs because you must decide how to list your present users, given all their unique tabs/devices.
I’m aware the stateful object is needed here and I’m not trying to argue against it. What I don’t like by the current way of not passing the presence object to the callback is that the presence object needs to be in scope at the place the callback is created. When the callback is created elsewhere one currently needs to wrap it in another closure just to get access to the presences object, which could simply be given to the callback.
// Somewhere in the code
let myPresenceUsageCallback = presence => {
console.log(presence.list())
}
// Pass myPresenceUsageCallback around to wherever the following is executed
let presence = new Presence(channel)
presence.onSync(myPresenceUsageCallback) // won't work as of now
// will work, but seems unnecessary complication of the api
presence.onSync(() => myPresenceUsageCallback(presence))
Oh I see. the updated_presences plural through me off. I see how this would be convenient, but I find the current usage clearer. Passing itself in as an argument that you call off itself may confuse callers that the provided argument is different from the instance, so the extra 12 keystrokes is a small price to pay 
Phoenix 1.4.0 final just went out!
https://phoenixframework.org/blog/phoenix-1-4-0-released
47 Likes
I’ve been checking the phoenix releases page almost every day for over a month, and just saw that the new release was published 2 hours ago. Super excited that Phoenix 1.4.0 stable is finally out!
5 Likes
Great 
btw, the upgrade guide at https://gist.github.com/chrismccord/bb1f8b136f5a9e4abc0bfc07b832257e still mentions
{:phoenix, "~> 1.4.0-rc", override: true}
2 Likes
